Hi Ryan,

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

CompiledMethod>>initialPC

"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: method32

| value nLits |

value := heap64 fetchPointer: fieldIndex ofObject: obj64.

(heap64 isIntegerObject: value)

ifTrue:

[nLits := heap32 literalCountOf: method32.

heap64

storePointerUnchecked: fieldIndex

ofObject: obj64

withValue: (heap64 integerObjectOf: nLits + LiteralStart * 4 + (heap64 integerValueOf: value))]

ifFalse:

[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@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