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

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 19 18:19:34 UTC 2014

Hi Ryan,

On Tue, Nov 18, 2014 at 7:59 PM, Ryan Macnak <rmacnak at gmail.com> 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 think this is taken care of.  For example, CompiledMethod>>initialPC
already consults wordSize.

"Answer the program counter for the receiver's first bytecode."

^ (self numLiterals + 1) * Smalltalk wordSize + 1

and of course the image bootstrap maps pcs already.  i.e.

Spur32to64BitBootstrap>>fillInPointerObjectWithPC: obj64 from: obj32
| method |
self fillInPointerObject: obj64 from: obj32.
(heap64 classIndexOf: obj64) = ClassBlockClosureCompactIndex ifTrue:
[method := heap32
fetchPointer: MethodIndex
ofObject: (heap32
fetchPointer: ClosureOuterContextIndex
ofObject: obj32).
self incrementPCField: ClosureStartPCIndex ofObject: obj64 for: method].
(heap64 classIndexOf: obj64) = ClassMethodContextCompactIndex ifTrue:
[method := heap32
fetchPointer: MethodIndex
ofObject: obj32.
 self incrementPCField: InstructionPointerIndex ofObject: obj64 for: method]

Spur32to64BitBootstrap>>incrementPCField: fieldIndex ofObject: obj64 for:
| value nLits |
value := heap64 fetchPointer: fieldIndex ofObject: obj64.
(heap64 isIntegerObject: value)
[nLits := heap32 literalCountOf: method32.
storePointerUnchecked: fieldIndex
ofObject: obj64
withValue: (heap64 integerObjectOf: nLits + LiteralStart * 4 + (heap64
integerValueOf: value))]
[self assert: (reverseMap at: value) = heap32 nilObject]

So I'm more looking for issues where the code implicitly assumes 32-bit
pointers, such as digitAt: below.

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/squeak-dev/attachments/20141119/27aac733/attachment.htm

More information about the Squeak-dev mailing list