[Vm-dev] Re: Spur 64-bits. Ugh, this could be a slog...

[Ryan Macnak]

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.

On Tue, Nov 18, 2014 at 9:07 PM, David T. Lewis <lewis at 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 at 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
> > >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20141118/35eb2611/attachment.htm