2014-07-02 0:28 GMT+02:00 David T. Lewis lewis@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@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