[Vm-dev] Aarch64 number bug
Bruce O'Neel
bruce.oneel at pckswarms.ch
Mon Jun 21 10:15:59 UTC 2021
Hi,
I have now gone back and checked this carefully. The git repository
at the commit before this one produces the right answer for 2
raisedTo: 64 on Aarch64. It produces the wrong answer, 0, when this
commit is included.
So it's this commit. I'll look at the code to see if I can see why
the code is bad.
BTW, how would one find the two referenced packages?
cheers
bruce
On 2021-06-20T22:44:36.000+02:00, Bruce O'Neel
<bruce.oneel at pckswarms.ch> wrote:
> Playing with Git bisect gets us to the commit below as the first bad
> one.
>
> I started the git bisect with the two commits below. The first one
> is bad, the second is the good one.
>
> a783502b249c4a4fedc88b6e07837d405feab144 - zero9 - builds, zero
> error.
>
> 9f73148b8da4bc00278b83faa8da6b1c418fa54f - zero10 - builds works
>
> Now this is not 100% guaranteed because one of the commits that git
> bisect chose had a build error so I had to mark that one as bad.
> But the commit found does sound possible.
>
> f632ee2888014ee88330ee994e13c9c609b57b5f is the first bad commit
>
> commit f632ee2888014ee88330ee994e13c9c609b57b5f
>
> Author: Eliot Miranda <eliot.miranda at gmail.com>
>
> Date: Wed Sep 2 10:45:27 2020 -0700
>
> CogVM source as per
> VMMaker.oscog-eem.2799/ClosedVMMaker-eem.98
>
>
>
> Ha! I am *STUPID*.
>
> Integer overflow is not only determined by the upper 64-bits
> of a 64x64=>128 bit
>
> multiply being either all zero or all ones (0 or -1), but by
> the upper 64-bits
>
> being an extension of the most significant bit of the lower 64
> bits!!
>
> :040000 040000 ffb8fbcd8ab5e2ca1936429b2daaade62909c178
> a5ac89d8b1d4980c5329835cdd3d4a2387b1fac5 M nsspur64src
>
> :040000 040000 e606dac14ee1db4ac59b0949bb03cd8e657d7aa7
> be666051cd1d52d0055e319432b66a0fba61063e M spur64src
>
> :040000 040000 1dea4faf99821c60e2c2461076bfe8b99d4dea9b
> afbef904e8cbc7e4b80e1606420dd6293e12f3e9 M spurlowcode64src
>
> :040000 040000 f66c681004806d5880af7c0a3115038f4f2f3361
> 0e8d76bedcf22b6ad7497ea2e3dc44f3c36c2f3a M spursista64src
>
> On 2021-06-20T21:48:49.000+02:00, Craig Latta
> <craig at blackpagedigital.com> wrote:
>
>> Hi Ken--
>>
>> I brought up a development environment on a Raspberry Pi 4.
>>
>> > Unfortunately, my attempt to build a VM simulator on aarch64 fails due
>> > to a divide by zero bug.
>> >
>> > Perhaps because
>> > 16r8000000000000000 printStringHex. ==> '0'
>>
>> update-eem-463.mcm has a postload action which turns on Sista,
>> which recompiles the system, which tries to recompile
>> FloatArrayTest>>testFloatArrayPluginPrimitiveAtPut, which exercises this
>> very bug during scanning, when trying to create the float 1e-127.
>>
>> For now I've rewritten testFloatArrayPluginPrimitiveAtPut and
>> testFloatArrayPluginPrimitiveAt on my system to do nothing. When
>> building GdbARMv8Plugin, there's some other kind of
>> header-include-ordering mayhem, similar to the problem with Linux
>> features.h when building the VM. (At least two levels of it, between
>> bfd.h and the aarch64 simulator's config.h, and config.h and other
>> system headers.) I expect no one has successfully built GdbARMv8Plugin
>> on anything but a M1 macOS machine so far.
>>
>> -C
>>
>> --
>> Craig Latta :: research computer scientist
>> Black Page Digital :: Berkeley, California
>> 663137D7940BF5C0AFC :: 1349FB2ADA32C4D5314CE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210621/71f1f344/attachment.html>
More information about the Vm-dev
mailing list