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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Jul 2 06:01:35 UTC 2014


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.

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


More information about the Vm-dev mailing list