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

David T. Lewis lewis at mail.msen.com
Wed Jul 2 11:42:32 UTC 2014


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



More information about the Vm-dev mailing list