[Vm-dev] Using MACROS from standard headers in slang [was VM Maker: VMMaker.oscog-eem.790.mcz]

[Nicolas Cellier]

2014-07-02 13:42 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:

>
> On Wed, Jul 02, 2014 at 08:01:35AM +0200, Nicolas Cellier wrote:
> >
> > 2014-07-02 7:44 GMT+02:00 Nicolas Cellier <
> > nicolas.cellier.aka.nice at gmail.com>:
> >
> > >
> > >
> > >
> > > 2014-07-02 0:28 GMT+02:00 David T. Lewis <lewis at mail.msen.com>:
> > >
> > >
> > >> On Tue, Jul 01, 2014 at 09:21:00PM +0200, Nicolas Cellier wrote:
> > >> >
> > >> > 2014-07-01 4:22 GMT+02:00 <commits at source.squeak.org>:
> > >> >
> > >> > >
> > >> > > Item was changed:
> > >> > >   ----- Method: LargeIntegersPlugin>>cDigitSub:len:with:len:into:
> (in
> > >> > > category 'C core') -----
> > >> > > + cDigitSub: pByteSmall len: smallLen with: pByteLarge len:
> largeLen
> > >> into:
> > >> > > pByteRes
> > >> > > +       | z |
> > >> > > - cDigitSub: pByteSmall
> > >> > > -               len: smallLen
> > >> > > -               with: pByteLarge
> > >> > > -               len: largeLen
> > >> > > -               into: pByteRes
> > >> > > -       | z limit |
> > >> > >         <var: #pByteSmall type: 'unsigned char * '>
> > >> > >         <var: #pByteLarge type: 'unsigned char * '>
> > >> > >         <var: #pByteRes type: 'unsigned char * '>
> > >> > >
> > >> > > +       z := 0. "Loop invariant is -1<=z<=1"
> > >> > > +       0 to: smallLen - 1 do:
> > >> > > -       z := 0.
> > >> > > -       "Loop invariant is -1<=z<=1"
> > >> > > -       limit := smallLen - 1.
> > >> > > -       0 to: limit do:
> > >> > >                 [:i |
> > >> > >                 z := z + (pByteLarge at: i) - (pByteSmall at: i).
> > >> > > +               pByteRes at: i put: z - (z // 256 * 256).
> > >> "sign-tolerant
> > >> > > form of (z bitAnd: 255)"
> > >> > >
> > >> >
> > >> > Frankly, having z declared unsigned int and just doing  pByteRes
> at: i
> > >> put:
> > >> > (z bitAnd: 16rFF) as I suggested would be way way simpler and will
> > >> ALWAYS
> > >> > work.
> > >> > Why the hell invoke the complications of signed arithmetic when the
> > >> content
> > >> > pByteRes is unsigned???
> > >>
> > >> Nicolas,
> > >>
> > >> This sounds right to me.
> > >>
> > >> Do you have a final version of #cDigitSub:len:with:len:into: that you
> can
> > >> recommend? The version in VMMaker-nice.342 produces failures in the
> > >> KernelTests-Numbers tests when compiled in 64-bit mode, but I think
> that
> > >> you have since suggested some other improvements in this email thread.
> > >>
> > >> Dave
> > >>
> > >>
> > > Hi David,
> > > that's interesting. VMMaker-nice.342 contains all the 32bits
> LargeInteger
> > > modifications, not just the #cDigitSub:len:with:len:into:.
> > > I tried to declare everything as <unsigned int> rather than <usqInt>
> with
> > > the assumption that sizeof(unsigned int)*2==sizeof(unsigned long long).
> > > But I never tried to compile a 64 bits VM, I think I lost the recipe
> for
> > > brewing such a flavour.
> > > I'm on MacOSX, could you provide a link to the shortest way to do it?
> > > Once I can check it, I'll publish a corrected version.
> > > Thanks
> > >
> > > Nicolas
> > >
> >
> > One thing I remember is that my modifications are full of hardcoded
> > constants like 16rFFFFFFFF that are making the code hardly future proof.
> > Normally, I would never code like that in C, but use standard macros like
> > UINT_MAX.
> > It's just that I don't know how to do it in SLANG...
> > Any hint?
> >
> > As for our own constants, like SmallInteger minVal and maxVal, we should
> > really have our own MACRO for this, there are way too many repetitions of
> > these constants spreaded in the code.
>
> In VMM trunk, see CCodeGenerator>>emitDefineBytesPerWordOn: as well as the
> methods in category 'constants' in ObjectMemory. The constants defined in
> this
> manner form the basis for generating code that can be compiled for either
> 32-bit or 64-bit images.
>
> BTW, this is what makes it is easy to test your
> #cDigitSub:len:with:len:into:
> change on various VM and image word sizes. The combination of 64-bit VM
> with
> 32-bit image is by far the best for finding bugs, but a 64-bit image
> sometimes
> produces interesting results too.
>
> Dave
>
>
Thanks both,
I had forgotten that we MUST have a way to simulate the VM, so C-Header
only is a no go.
I'll inquire as soon as I find time.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140702/809a5d85/attachment-0001.htm