On Tue, Nov 18, 2014 at 10:03 PM, Ryan Macnak <rmacnak at 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 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
> > >
>
>



-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20141119/578c8f5b/attachment.htm