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

[Ryan Macnak]

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.

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/bec83826/attachment-0001.htm