On Tue, Nov 18, 2014 at 07:12:12PM -0800, Eliot Miranda wrote:
Hi All,
I'm making good progress on 64-bit Spur in the Stack VM simulator. But I've just noticed an image-level issue which could be indicative of lots of 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems.
SmallInteger>>digitAt: n "Answer the value of an indexable field in the receiver. LargePositiveInteger uses bytes of base two number, and each is a 'digit' base 256. Fail if the argument (the index) is not an Integer or is out of bounds." n>4 ifTrue: [^ 0]. self < 0 ifTrue: [self = SmallInteger minVal ifTrue: ["Can't negate minVal -- treat specially" ^ #(0 0 0 64) at: n]. ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF] ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF]
This assumes that SmallInteger is only ever 4 bytes, which is unacceptably wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are 61-bit 2's complement.
I'm raising this example at this point to see if the community might find similar issues and bring them to my attention.
There will be quite a few issues like this scattered throughout the image. My suggestion would be to focus first on getting the 64-bit Spur image running with no changes to SmallInteger minVal and maxVal. Then, as a separate follow up step, expand the range of SmallInteger in the image and work out all the changes required to support it. Another possible way to attack the problem is to start with a Squeak trunk image in 68002 image format (64-bit image), and work out the issues associated with extending SmallInteger minVal and maxVal to take advantage of the larger immediate integers range. This could be independent of the work you are doing now, so if someone else wanted to work on the "expand range of SmallInteger" aspect of the project, I expect that this can be done in the existing 68002 image, such that the resulting changes would be directly applicable to the format 68019 (64-bit) Spur images. Dave