<div dir="ltr">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.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 9:07 PM, David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
On Tue, Nov 18, 2014 at 07:59:30PM -0800, Ryan Macnak wrote:<br>
><br>
> What about bytecode pc's? These are indexed based on the physical size of<br>
> the literals. I don't like the idea of debugging pc -> source mappings, pc<br>
> coverage data, etc needing invalidation after starting an image on a<br>
> platform with a different word size.<br>
<br>
</span>I may be misunderstanding your question, but I do not think that this will<br>
be an issue. All byte addressible objects need to work properly in any image,<br>
including 32 and 64 bit images. If that part does not work, then the image<br>
will not run, so no problem ;-)<br>
<br>
With respect to platform word size (e.g. 64 bit OS versus 32 bit OS), the<br>
images should all run bit-identically regardless of platform word size. A<br>
64-bit image can (and does) run on a 32-bit host platform, given a suitably<br>
compiled VM. And a 32-bit image will run on a 64-bit host platform, given a<br>
suitably compiled VM (or more commonly, a 32-bit VM with 32-bit compatibility<br>
libraries installed on the platform).<br>
<br>
Dave<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
> On Tue, Nov 18, 2014 at 7:12 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
> wrote:<br>
><br>
> > Hi All,<br>
> ><br>
> > I'm making good progress on 64-bit Spur in the Stack VM simulator.<br>
> > But I've just noticed an image-level issue which could be indicative of<br>
> > lots of 32-bit assumptions baked into the Squeal/Pharo/Newspeak systems.<br>
> ><br>
> > SmallInteger>>digitAt: n<br>
> > "Answer the value of an indexable field in the receiver.<br>
> > LargePositiveInteger uses bytes of base two number, and each is a 'digit'<br>
> > base 256. Fail if the argument (the index) is not an Integer or is out of<br>
> > bounds."<br>
> > n>4 ifTrue: [^ 0].<br>
> > self < 0<br>
> > ifTrue:<br>
> > [self = SmallInteger minVal ifTrue:<br>
> > ["Can't negate minVal -- treat specially"<br>
> > ^ #(0 0 0 64) at: n].<br>
> > ^ ((0-self) bitShift: (1-n)*8) bitAnd: 16rFF]<br>
> > ifFalse: [^ (self bitShift: (1-n)*8) bitAnd: 16rFF]<br>
> ><br>
> > This assumes that SmallInteger is only ever 4 bytes, which is unacceptably<br>
> > wasteful for my approach to 64-bits. In 64-bit Spur, SmallIntegers are<br>
> > 61-bit 2's complement.<br>
> ><br>
> > I'm raising this example at this point to see if the community might find<br>
> > similar issues and bring them to my attention.<br>
> > --<br>
> > best,<br>
> > Eliot<br>
> ><br>
<br>
</div></div></blockquote></div><br></div></div>