On Tue, Nov 18, 2014 at 10:03 PM, Ryan Macnak <rmacnak@gmail.com> wrote:
Ah, that's true if images have a fixed word size. I had imagined that the VM would convert an image to the host word size at startup, just as Cog converts Floats to the host representation. The Float change is transparent to Smalltalk, but a word size change would be visible through the identities of objects that are either immediate or heap depending on the word size. And for mixed format objects like CompiledMethods, the offset for basicAt: for the beginning of the byte data would change.
Right. And for this reason I find it better to make the change a one-off bootstrap, even if it rewrites a 32-nit image to a 64-bit image, rather thna builds a fresh system from startup (an approach others are pursuing). It doesn't make sense burdening the VM with conversion code that is rarely used. The one-off conversion results in a more performant, reliable solution IMO, much like the V3 to Spur bootstrap itself. On Tue, Nov 18, 2014 at 9:07 PM, David T. Lewis <lewis@mail.msen.com> wrote:
On Tue, Nov 18, 2014 at 07:59:30PM -0800, Ryan Macnak wrote:
What about bytecode pc's? These are indexed based on the physical size of the literals. I don't like the idea of debugging pc -> source mappings,
pc
coverage data, etc needing invalidation after starting an image on a platform with a different word size.
I may be misunderstanding your question, but I do not think that this will be an issue. All byte addressible objects need to work properly in any image, including 32 and 64 bit images. If that part does not work, then the image will not run, so no problem ;-)
With respect to platform word size (e.g. 64 bit OS versus 32 bit OS), the images should all run bit-identically regardless of platform word size. A 64-bit image can (and does) run on a 32-bit host platform, given a suitably compiled VM. And a 32-bit image will run on a 64-bit host platform, given a suitably compiled VM (or more commonly, a 32-bit VM with 32-bit compatibility libraries installed on the platform).
Dave
On Tue, Nov 18, 2014 at 7:12 PM, Eliot Miranda <eliot.miranda@gmail.com> 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. -- best, Eliot
-- best, Eliot