InterpreterSimulator

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
47 messages Options
123
Reply | Threaded
Open this post in threaded view
|

InterpreterSimulator

Florin Mateoc-4
 
Hi,

Does anybody know the current status of the various simulators?
Even the classes are a bit confusing, since their class comments are just copied and pasted from their
siblings/ancestors, so I cannot figure out what is current and what is used for what.
Could some kind soul please summarize which images are supposed to be run by which simulator? E.g. is
InterpreterSimulator (and subclasses) still being used/working?

More concretely, I tried to run StackInterpreterSimulator on a 4.5 image, since it does not support the current image
format, but I keep hitting various errors. A particularly confusing kind is that NewObjectMemory refers sometimes to its
interpreter instvar, sometimes to its coInterpreter instvar (sometimes to both in the same method), even though only the
coInterpreter instvar is initialized. Does it need both instvars, and if so, what are their roles and how should they be
initialized?

Thank you,
Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2
 
Hi Florin,

On Tue, Mar 8, 2016 at 12:46 PM, Florin Mateoc <[hidden email]> wrote:

Hi,

Does anybody know the current status of the various simulators?

I can vouch for the simulators in VMMaker.oscog.   StackInterpreterSimulator and CogVMSimulator work.  InterpreterSimulator is extremely unlikely to any more.

Even the classes are a bit confusing, since their class comments are just copied and pasted from their
siblings/ancestors, so I cannot figure out what is current and what is used for what.

They're not in VMMaker.oscog (which is on http://source.squeak.org/VMMaker).  CogVMSimulator's comment is quite different from StackInterpreterSimulator.  In fact, they could do with being made a little more similar ;-)


Could some kind soul please summarize which images are supposed to be run by which simulator? E.g. is
InterpreterSimulator (and subclasses) still being used/working?

Not in VMMaker.oscog.  The Interpreter there-in hasn't been touched for many years.  We have a task when time allows to merge Interpreter[Simulator] from VMMaker with Interpreter[Simulator] from VMMaker.oscog, so that for example we can have a Spur context interpreter.

More concretely, I tried to run StackInterpreterSimulator on a 4.5 image, since it does not support the current image
format, but I keep hitting various errors. A particularly confusing kind is that NewObjectMemory refers sometimes to its
interpreter instvar, sometimes to its coInterpreter instvar (sometimes to both in the same method), even though only the
coInterpreter instvar is initialized. Does it need both instvars, and if so, what are their roles and how should they be
initialized?

In VMMaker.oscog that's not the case.


StackInterpreterSimulator allInstVarNames select: [:v| '*terpreter*' match: v] #('interpreterProxy')

If what you want is to work with the current Squeak, Pharo or Newspeak VMs then you need to be using VMMaker.oscog.  The latest version is 

Name: VMMaker.oscog-nice.1713
Author: nice
Time: 5 March 2016, 3:15:22.817 am
UUID: ac270981-d3ba-4c42-a2b1-3a83693776be
Ancestors: VMMaker.oscog-nice.1712

The size of [unsigned] long long was not infered...

VM fool proofing:

Fix a missing guard in SmartSyntaxPlugin like explained at

Fix two missing guards in VM profiling primitives: one should not use the result of stackObjectValue: before checking for success, otherwise a null pointer exception will occur in case of failure.

Thank you,
Florin

HTH
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
Hi Eliot,

Thank you, VMMaker.oscog works better, indeed.
I still got an error while executing:

(StackInterpreterSimulator new openOn:
'F:\Smalltalk\squeak\Squeak-4.5-All-in-One.app\Contents\Resources\Squeak4.5-decompiler.image') test

Do I need any additional settings?


Here is the erorr report:

'From: 8 March 2016 5:35:01.126 pm

VM: Win32 - Smalltalk
Image: Squeak5.0 [latest update: #15117]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir F:\Smalltalk\squeak\Squeak-5.0-All-in-One\Squeak-5.0-All-in-One.app\Contents\Resources
Trusted Dir F:\Smalltalk\squeak\Squeak-5.0-All-in-One\Squeak-5.0-All-in-One.app\Contents\Resources\fmateoc
Untrusted Dir C:\Users\fmateoc\Documents\My Squeak

NewObjectMemorySimulatorLSB(Object)>>error:
    Receiver: a NewObjectMemorySimulatorLSB
    Arguments and temporary variables:
        aString:     ''unaligned access''
    Receiver''s instance variables:
        memory:     a LittleEndianBitmap of length 7421053
        youngStart:     25087060
        endOfMemory:     29212852
        memoryLimit:     29684212
        nilObj:     4
        falseObj:     12
        trueObj:     20
        specialObjectsOop:     4339092
        rootTable:     #(2837948 4339092 219644 231688 231700 3830388 10956 22224904 5356 1...etc...
        rootTableCount:     88
        rootTableOverflowed:     false
        extraRoots:     nil
        extraRootCount:     0
        weakRoots:     #(2572452 nil nil nil nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        weakRootCount:     1
        child:     1501724940
        field:     345348
        parentField:     3
        freeBlock:     nil
        lastHash:     17871637
        allocationCount:     nil
        lowSpaceThreshold:     200000
        signalLowSpace:     false
        compStart:     26763028
        compEnd:     26867736
        fwdTableNext:     26868032
        fwdTableLast:     29684204
        remapBuffer:     #(26772976 26772968 nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        remapBufferCount:     0
        allocationsBetweenGCs:     nil
        tenuringThreshold:     2000
        gcBiasToGrow:     0
        gcBiasToGrowGCLimit:     0
        gcBiasToGrowThreshold:     nil
        statFullGCs:     0
        statIncrGCs:     18
        statFullGCUsecs:     0
        statIncrGCUsecs:     0
        statGCEndTime:     nil
        statIGCDeltaUsecs:     0
        statTenures:     0
        statRootTableOverflows:     0
        freeContexts:     nil
        freeLargeContexts:     nil
        interruptCheckCounter:     nil
        totalObjectCount:     471363
        shrinkThreshold:     8388608
        growHeadroom:     4194304
        headerTypeBytes:     a CArrayAccessor on: #(8 4 0 0)
        youngStartLocal:     25087060
        statMarkCount:     4111
        statMarkCountLocal:     4111
        statSweepCount:     2961
        statMkFwdCount:     45
        statCompMoveCount:     45
        statGrowMemory:     0
        statShrinkMemory:     0
        statRootTableCount:     88
        statAllocationCount:     nil
        statSurvivorCount:     931
        statSpecialMarkCount:     1616
        forceTenureFlag:     0
        gcStartUsecs:     3634910906984935
        coInterpreter:     a StackInterpreterSimulatorLSB
        freeStart:     26773052
        reserveStart:     27070132
        scavengeThreshold:     27070132
        needGCFlag:     false
        fullGCLock:     0
        edenBytes:     2097152
        checkForLeaks:     0
        statGCEndUsecs:     3634910906984935
        heapMap:     a CogCheck32BitHeapMap
        parent:     nil

NewObjectMemorySimulatorLSB(VMClass)>>unalignedAccessError
    Receiver: a NewObjectMemorySimulatorLSB
    Arguments and temporary variables:

    Receiver''s instance variables:
        memory:     a LittleEndianBitmap of length 7421053
        youngStart:     25087060
        endOfMemory:     29212852
        memoryLimit:     29684212
        nilObj:     4
        falseObj:     12
        trueObj:     20
        specialObjectsOop:     4339092
        rootTable:     #(2837948 4339092 219644 231688 231700 3830388 10956 22224904 5356 1...etc...
        rootTableCount:     88
        rootTableOverflowed:     false
        extraRoots:     nil
        extraRootCount:     0
        weakRoots:     #(2572452 nil nil nil nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        weakRootCount:     1
        child:     1501724940
        field:     345348
        parentField:     3
        freeBlock:     nil
        lastHash:     17871637
        allocationCount:     nil
        lowSpaceThreshold:     200000
        signalLowSpace:     false
        compStart:     26763028
        compEnd:     26867736
        fwdTableNext:     26868032
        fwdTableLast:     29684204
        remapBuffer:     #(26772976 26772968 nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        remapBufferCount:     0
        allocationsBetweenGCs:     nil
        tenuringThreshold:     2000
        gcBiasToGrow:     0
        gcBiasToGrowGCLimit:     0
        gcBiasToGrowThreshold:     nil
        statFullGCs:     0
        statIncrGCs:     18
        statFullGCUsecs:     0
        statIncrGCUsecs:     0
        statGCEndTime:     nil
        statIGCDeltaUsecs:     0
        statTenures:     0
        statRootTableOverflows:     0
        freeContexts:     nil
        freeLargeContexts:     nil
        interruptCheckCounter:     nil
        totalObjectCount:     471363
        shrinkThreshold:     8388608
        growHeadroom:     4194304
        headerTypeBytes:     a CArrayAccessor on: #(8 4 0 0)
        youngStartLocal:     25087060
        statMarkCount:     4111
        statMarkCountLocal:     4111
        statSweepCount:     2961
        statMkFwdCount:     45
        statCompMoveCount:     45
        statGrowMemory:     0
        statShrinkMemory:     0
        statRootTableCount:     88
        statAllocationCount:     nil
        statSurvivorCount:     931
        statSpecialMarkCount:     1616
        forceTenureFlag:     0
        gcStartUsecs:     3634910906984935
        coInterpreter:     a StackInterpreterSimulatorLSB
        freeStart:     26773052
        reserveStart:     27070132
        scavengeThreshold:     27070132
        needGCFlag:     false
        fullGCLock:     0
        edenBytes:     2097152
        checkForLeaks:     0
        statGCEndUsecs:     3634910906984935
        heapMap:     a CogCheck32BitHeapMap
        parent:     nil

NewObjectMemorySimulatorLSB>>long64At:
    Receiver: a NewObjectMemorySimulatorLSB
    Arguments and tempo...etc...
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2
 
Hi Florin,

On Tue, Mar 8, 2016 at 2:42 PM, Florin Mateoc <[hidden email]> wrote:

Hi Eliot,

Thank you, VMMaker.oscog works better, indeed.
I still got an error while executing:

(StackInterpreterSimulator new openOn:
'F:\Smalltalk\squeak\Squeak-4.5-All-in-One.app\Contents\Resources\Squeak4.5-decompiler.image') test

Do I need any additional settings?

You shouldn't, but there may be an initialization bug.  Can you post just the stack, without all those simulator inst vars? The stack trace gets interesting at "NewObjectMemorySimulatorLSB>>long64At:" just when the post gets truncated.  I don't know why long64At: would be sent in a V3 simulation so it piques my interest.
 


Here is the erorr report:

'From: 8 March 2016 5:35:01.126 pm

VM: Win32 - Smalltalk
Image: Squeak5.0 [latest update: #15117]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir F:\Smalltalk\squeak\Squeak-5.0-All-in-One\Squeak-5.0-All-in-One.app\Contents\Resources
Trusted Dir F:\Smalltalk\squeak\Squeak-5.0-All-in-One\Squeak-5.0-All-in-One.app\Contents\Resources\fmateoc
Untrusted Dir C:\Users\fmateoc\Documents\My Squeak

NewObjectMemorySimulatorLSB(Object)>>error:
    Receiver: a NewObjectMemorySimulatorLSB
    Arguments and temporary variables:
        aString:     ''unaligned access''
    Receiver''s instance variables:
        memory:     a LittleEndianBitmap of length 7421053
        youngStart:     25087060
        endOfMemory:     29212852
        memoryLimit:     29684212
        nilObj:     4
        falseObj:     12
        trueObj:     20
        specialObjectsOop:     4339092
        rootTable:     #(2837948 4339092 219644 231688 231700 3830388 10956 22224904 5356 1...etc...
        rootTableCount:     88
        rootTableOverflowed:     false
        extraRoots:     nil
        extraRootCount:     0
        weakRoots:     #(2572452 nil nil nil nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        weakRootCount:     1
        child:     1501724940
        field:     345348
        parentField:     3
        freeBlock:     nil
        lastHash:     17871637
        allocationCount:     nil
        lowSpaceThreshold:     200000
        signalLowSpace:     false
        compStart:     26763028
        compEnd:     26867736
        fwdTableNext:     26868032
        fwdTableLast:     29684204
        remapBuffer:     #(26772976 26772968 nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        remapBufferCount:     0
        allocationsBetweenGCs:     nil
        tenuringThreshold:     2000
        gcBiasToGrow:     0
        gcBiasToGrowGCLimit:     0
        gcBiasToGrowThreshold:     nil
        statFullGCs:     0
        statIncrGCs:     18
        statFullGCUsecs:     0
        statIncrGCUsecs:     0
        statGCEndTime:     nil
        statIGCDeltaUsecs:     0
        statTenures:     0
        statRootTableOverflows:     0
        freeContexts:     nil
        freeLargeContexts:     nil
        interruptCheckCounter:     nil
        totalObjectCount:     471363
        shrinkThreshold:     8388608
        growHeadroom:     4194304
        headerTypeBytes:     a CArrayAccessor on: #(8 4 0 0)
        youngStartLocal:     25087060
        statMarkCount:     4111
        statMarkCountLocal:     4111
        statSweepCount:     2961
        statMkFwdCount:     45
        statCompMoveCount:     45
        statGrowMemory:     0
        statShrinkMemory:     0
        statRootTableCount:     88
        statAllocationCount:     nil
        statSurvivorCount:     931
        statSpecialMarkCount:     1616
        forceTenureFlag:     0
        gcStartUsecs:     3634910906984935
        coInterpreter:     a StackInterpreterSimulatorLSB
        freeStart:     26773052
        reserveStart:     27070132
        scavengeThreshold:     27070132
        needGCFlag:     false
        fullGCLock:     0
        edenBytes:     2097152
        checkForLeaks:     0
        statGCEndUsecs:     3634910906984935
        heapMap:     a CogCheck32BitHeapMap
        parent:     nil

NewObjectMemorySimulatorLSB(VMClass)>>unalignedAccessError
    Receiver: a NewObjectMemorySimulatorLSB
    Arguments and temporary variables:

    Receiver''s instance variables:
        memory:     a LittleEndianBitmap of length 7421053
        youngStart:     25087060
        endOfMemory:     29212852
        memoryLimit:     29684212
        nilObj:     4
        falseObj:     12
        trueObj:     20
        specialObjectsOop:     4339092
        rootTable:     #(2837948 4339092 219644 231688 231700 3830388 10956 22224904 5356 1...etc...
        rootTableCount:     88
        rootTableOverflowed:     false
        extraRoots:     nil
        extraRootCount:     0
        weakRoots:     #(2572452 nil nil nil nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        weakRootCount:     1
        child:     1501724940
        field:     345348
        parentField:     3
        freeBlock:     nil
        lastHash:     17871637
        allocationCount:     nil
        lowSpaceThreshold:     200000
        signalLowSpace:     false
        compStart:     26763028
        compEnd:     26867736
        fwdTableNext:     26868032
        fwdTableLast:     29684204
        remapBuffer:     #(26772976 26772968 nil nil nil nil nil nil nil nil nil nil nil ni...etc...
        remapBufferCount:     0
        allocationsBetweenGCs:     nil
        tenuringThreshold:     2000
        gcBiasToGrow:     0
        gcBiasToGrowGCLimit:     0
        gcBiasToGrowThreshold:     nil
        statFullGCs:     0
        statIncrGCs:     18
        statFullGCUsecs:     0
        statIncrGCUsecs:     0
        statGCEndTime:     nil
        statIGCDeltaUsecs:     0
        statTenures:     0
        statRootTableOverflows:     0
        freeContexts:     nil
        freeLargeContexts:     nil
        interruptCheckCounter:     nil
        totalObjectCount:     471363
        shrinkThreshold:     8388608
        growHeadroom:     4194304
        headerTypeBytes:     a CArrayAccessor on: #(8 4 0 0)
        youngStartLocal:     25087060
        statMarkCount:     4111
        statMarkCountLocal:     4111
        statSweepCount:     2961
        statMkFwdCount:     45
        statCompMoveCount:     45
        statGrowMemory:     0
        statShrinkMemory:     0
        statRootTableCount:     88
        statAllocationCount:     nil
        statSurvivorCount:     931
        statSpecialMarkCount:     1616
        forceTenureFlag:     0
        gcStartUsecs:     3634910906984935
        coInterpreter:     a StackInterpreterSimulatorLSB
        freeStart:     26773052
        reserveStart:     27070132
        scavengeThreshold:     27070132
        needGCFlag:     false
        fullGCLock:     0
        edenBytes:     2097152
        checkForLeaks:     0
        statGCEndUsecs:     3634910906984935
        heapMap:     a CogCheck32BitHeapMap
        parent:     nil

NewObjectMemorySimulatorLSB>>long64At:
    Receiver: a NewObjectMemorySimulatorLSB
    Arguments and tempo...etc...



--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/8/2016 7:20 PM, Eliot Miranda wrote:
 


Hi Florin,

On Tue, Mar 8, 2016 at 2:42 PM, Florin Mateoc <[hidden email]> wrote:

Hi Eliot,

Thank you, VMMaker.oscog works better, indeed.
I still got an error while executing:

(StackInterpreterSimulator new openOn:
'F:\Smalltalk\squeak\Squeak-4.5-All-in-One.app\Contents\Resources\Squeak4.5-decompiler.image') test

Do I need any additional settings?

You shouldn't, but there may be an initialization bug.  Can you post just the stack, without all those simulator inst vars? The stack trace gets interesting at "NewObjectMemorySimulatorLSB>>long64At:" just when the post gets truncated.  I don't know why long64At: would be sent in a V3 simulation so it piques my interest.
 


Sure, here it is:

NewObjectMemorySimulatorLSB(Object)>>error:
NewObjectMemorySimulatorLSB(VMClass)>>unalignedAccessError
NewObjectMemorySimulatorLSB>>long64At:
NewObjectMemorySimulatorLSB(ObjectMemory)>>fetchLong64:ofObject:
[] in StackInterpreterSimulatorLSB(InterpreterPrimitives)>>signed64BitValueOf:
False>>ifTrue:ifFalse:
StackInterpreterSimulatorLSB(VMClass)>>cppIf:ifTrue:ifFalse:
StackInterpreterSimulatorLSB(InterpreterPrimitives)>>signed64BitValueOf:
StackInterpreterSimulatorLSB(InterpreterPrimitives)>>primitiveLessThanLargeIntegers
StackInterpreterSimulatorLSB(StackInterpreter)>>dispatchFunctionPointer:
StackInterpreterSimulatorLSB(StackInterpreter)>>slowPrimitiveResponse
StackInterpreterSimulatorLSB(StackInterpreter)>>internalExecuteNewMethod
StackInterpreterSimulatorLSB(StackInterpreter)>>commonSendOrdinary
StackInterpreterSimulatorLSB(StackInterpreter)>>normalSend
StackInterpreterSimulatorLSB(StackInterpreter)>>bytecodePrimLessThan
StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>dispatchOn:in:
StackInterpreterSimulatorLSB(StackInterpreterSimulator)>>test
UndefinedObject>>DoIt


Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
In reply to this post by Eliot Miranda-2
 
Hi again,

I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even
mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes.
In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption
come from, because it does not seem limited to this method.
Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail.

Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied
and pasted.
For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte
LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to
64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits.

Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and
#positive64BitValueOf: do not take care of the BigEndian case.

Cheers,
Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/9/2016 3:17 PM, Florin Mateoc wrote:

> Hi again,
>
> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even
> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes.
> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption
> come from, because it does not seem limited to this method.
> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail.
>
> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied
> and pasted.
> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte
> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to
> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits.
>
> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and
> #positive64BitValueOf: do not take care of the BigEndian case.
>
> Cheers,
> Florin


For what it's worth, I did try the obvious (if what I suspect is correct) fix in #signed64BitValueOf: and it seemed to work:


    ...
    self cppIf: VMBIGENDIAN
        ifTrue:
            [value := objectMemory fetchByte: sz - 1 ofObject: oop.
             sz - 2 to: 0 by: -1 do: [:i |
                value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]]
        ifFalse:
            [value := (objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger.
             4 to: sz - 1 do: [:i |
                value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]].


instead of the original:


    ...
    self cppIf: VMBIGENDIAN
        ifTrue:
            [value := objectMemory fetchByte: sz - 1 ofObject: oop.
             sz - 2 to: 0 by: -1 do: [:i |
                value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]]
        ifFalse: [value := sz > 4
                        ifTrue: [objectMemory fetchLong64: 0 ofObject: oop]
                        ifFalse: [(objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger]].

Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2

Hi Florin,

   I believe the correct fix is for  ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8.  I'll commit asap (which is once I have 64-bit small float tagging converted).  But your fix should  keep you going until then.

_,,,^..^,,,_ (phone)

> On Mar 9, 2016, at 1:53 PM, Florin Mateoc <[hidden email]> wrote:
>
>
>> On 3/9/2016 3:17 PM, Florin Mateoc wrote:
>> Hi again,
>>
>> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even
>> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes.
>> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption
>> come from, because it does not seem limited to this method.
>> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail.
>>
>> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied
>> and pasted.
>> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte
>> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to
>> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits.
>>
>> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and
>> #positive64BitValueOf: do not take care of the BigEndian case.
>>
>> Cheers,
>> Florin
>
>
> For what it's worth, I did try the obvious (if what I suspect is correct) fix in #signed64BitValueOf: and it seemed to work:
>
>
>    ...
>    self cppIf: VMBIGENDIAN
>        ifTrue:
>            [value := objectMemory fetchByte: sz - 1 ofObject: oop.
>             sz - 2 to: 0 by: -1 do: [:i |
>                value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]]
>        ifFalse:
>            [value := (objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger.
>             4 to: sz - 1 do: [:i |
>                value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]].
>
>
> instead of the original:
>
>
>    ...
>    self cppIf: VMBIGENDIAN
>        ifTrue:
>            [value := objectMemory fetchByte: sz - 1 ofObject: oop.
>             sz - 2 to: 0 by: -1 do: [:i |
>                value := value << 8 + (objectMemory fetchByte: i ofObject: oop)]]
>        ifFalse: [value := sz > 4
>                        ifTrue: [objectMemory fetchLong64: 0 ofObject: oop]
>                        ifFalse: [(objectMemory fetchLong32: 0 ofObject: oop) asUnsignedInteger]].
>
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/9/2016 8:23 PM, Eliot Miranda wrote:
>  
> Hi Florin,
>
>    I believe the correct fix is for  ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8.  I'll commit asap (which is once I have 64-bit small float tagging converted).  But your fix should  keep you going until then.
>
> _,,,^..^,,,_ (phone)



Hi Eliot,

I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))

Florin


>> On Mar 9, 2016, at 1:53 PM, Florin Mateoc <[hidden email]> wrote:
>>
>>
>>> On 3/9/2016 3:17 PM, Florin Mateoc wrote:
>>> Hi again,
>>>
>>> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even
>>> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes.
>>> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption
>>> come from, because it does not seem limited to this method.
>>> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail.
>>>
>>> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied
>>> and pasted.
>>> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte
>>> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to
>>> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits.
>>>
>>> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and
>>> #positive64BitValueOf: do not take care of the BigEndian case.
>>>
>>> Cheers,
>>> Florin
>>

Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2
 


On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <[hidden email]> wrote:

On 3/9/2016 8:23 PM, Eliot Miranda wrote:
>
> Hi Florin,
>
>    I believe the correct fix is for  ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8.  I'll commit asap (which is once I have 64-bit small float tagging converted).  But your fix should  keep you going until then.
>
> _,,,^..^,,,_ (phone)



Hi Eliot,

I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))

Because in V3 any object occupies some number of 32-bit words, zero padded.  So a 5 byte large integer is actually a 4 byte header followed by an 8 byte unit whose most significant 3 bytes are always zero.  In Spur, any object occupies some number of 8-byte words, so a 5 byte integer has an 8 byte header followed by an 8 byte unit, but a 9 byte integer occupies 24 bytes (8 byte header, 16 bytes data).

So in V3, fetching 64-bits from a 5 to 8 byte large integer must be done in two reads because objects are only aligned to a 4 byte boundary, but in Spur it can be done in a single 64-bit read because all objects are aligned on an 8 byte boundary.


Florin


>> On Mar 9, 2016, at 1:53 PM, Florin Mateoc <[hidden email]> wrote:
>>
>>
>>> On 3/9/2016 3:17 PM, Florin Mateoc wrote:
>>> Hi again,
>>>
>>> I think I found the bug: in method InterpreterPrimitives>>signed64BitValueOf: there seems to be an assumption (even
>>> mentioned in the method comment) that (on 32bit machines) largeIntegers have to be either 4 or 8 bytes.
>>> In this case we get a 5byte largeInteger, so we get the error. What I don't understand is where does this assumption
>>> come from, because it does not seem limited to this method.
>>> Also note that on BigEndian machines the code does not act upon this assumption, so it would not fail.
>>>
>>> Actually, I suspect that the assumption comes from "generalizing" the 32-bit one, since the methods seem to be copied
>>> and pasted.
>>> For the 32bit variant, the comment stated that "The object may be either a positive SmallInteger or a four-byte
>>> LargeInteger". But in this case it was correct, anything less than 4 bytes would not be a LargeInteger. When moving to
>>> 64bit, the same does not hold true. We can have largeIntegers with 4,5,6,7 or 8 bytes fitting in 64 bits.
>>>
>>> Also, speaking of BigEndian, it seems that, in the same class, the methods #magnitude64BitValueOf: and
>>> #positive64BitValueOf: do not take care of the BigEndian case.
>>>
>>> Cheers,
>>> Florin
>>




--
_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/10/2016 12:02 PM, Eliot Miranda wrote:
 




On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <[hidden email]> wrote:

On 3/9/2016 8:23 PM, Eliot Miranda wrote:
>
> Hi Florin,
>
>    I believe the correct fix is for  ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8.  I'll commit asap (which is once I have 64-bit small float tagging converted).  But your fix should  keep you going until then.
>
> _,,,^..^,,,_ (phone)



Hi Eliot,

I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))

Because in V3 any object occupies some number of 32-bit words, zero padded.  So a 5 byte large integer is actually a 4 byte header followed by an 8 byte unit whose most significant 3 bytes are always zero.  In Spur, any object occupies some number of 8-byte words, so a 5 byte integer has an 8 byte header followed by an 8 byte unit, but a 9 byte integer occupies 24 bytes (8 byte header, 16 bytes data).

So in V3, fetching 64-bits from a 5 to 8 byte large integer must be done in two reads because objects are only aligned to a 4 byte boundary, but in Spur it can be done in a single 64-bit read because all objects are aligned on an 8 byte boundary.

Thank you, that makes perfect sense

Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
In reply to this post by Eliot Miranda-2
 
On 3/10/2016 12:02 PM, Eliot Miranda wrote:
 




On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <[hidden email]> wrote:

On 3/9/2016 8:23 PM, Eliot Miranda wrote:
>
> Hi Florin,
>
>    I believe the correct fix is for  ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8.  I'll commit asap (which is once I have 64-bit small float tagging converted).  But your fix should  keep you going until then.
>
> _,,,^..^,,,_ (phone)



Hi Eliot,

I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))

Because in V3 any object occupies some number of 32-bit words, zero padded.  So a 5 byte large integer is actually a 4 byte header followed by an 8 byte unit whose most significant 3 bytes are always zero.  In Spur, any object occupies some number of 8-byte words, so a 5 byte integer has an 8 byte header followed by an 8 byte unit, but a 9 byte integer occupies 24 bytes (8 byte header, 16 bytes data).

So in V3, fetching 64-bits from a 5 to 8 byte large integer must be done in two reads because objects are only aligned to a 4 byte boundary, but in Spur it can be done in a single 64-bit read because all objects are aligned on an 8 byte boundary.


Since ObjectMemory (in its subclasses) actually already decomposes long64At: in two 32-bit reads, instead of duplicating the decomposition in fetchLong64:ofObject: (the caller or long64At:), shouldn't the fix just be to replace the alignment check within long64At:?
i.e. replacing the hardcoded 8 with BytesPerWord:

    byteAddress \\ 8 ~= 0 ifTrue: [self unalignedAccessError].

Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2
 
Hi Florin,

On Mar 10, 2016, at 10:54 AM, Florin Mateoc <[hidden email]> wrote:

On 3/10/2016 12:02 PM, Eliot Miranda wrote:
 




On Wed, Mar 9, 2016 at 5:27 PM, Florin Mateoc <[hidden email]> wrote:

On 3/9/2016 8:23 PM, Eliot Miranda wrote:
>
> Hi Florin,
>
>    I believe the correct fix is for  ObjectMemory needs to decompose fetchLong64:ofObject: into two 32-but reads unless BytesPerWord = 8.  I'll commit asap (which is once I have 64-bit small float tagging converted).  But your fix should  keep you going until then.
>
> _,,,^..^,,,_ (phone)



Hi Eliot,

I don't understand how two 32-bit reads can take care of 5-byte long largeIntegers, but you know best (usually :))

Because in V3 any object occupies some number of 32-bit words, zero padded.  So a 5 byte large integer is actually a 4 byte header followed by an 8 byte unit whose most significant 3 bytes are always zero.  In Spur, any object occupies some number of 8-byte words, so a 5 byte integer has an 8 byte header followed by an 8 byte unit, but a 9 byte integer occupies 24 bytes (8 byte header, 16 bytes data).

So in V3, fetching 64-bits from a 5 to 8 byte large integer must be done in two reads because objects are only aligned to a 4 byte boundary, but in Spur it can be done in a single 64-bit read because all objects are aligned on an 8 byte boundary.


Since ObjectMemory (in its subclasses) actually already decomposes long64At: in two 32-bit reads, instead of duplicating the decomposition in fetchLong64:ofObject: (the caller or long64At:), shouldn't the fix just be to replace the alignment check within long64At:?
i.e. replacing the hardcoded 8 with BytesPerWord:

    byteAddress \\ 8 ~= 0 ifTrue: [self unalignedAccessError].

This is where it gets tricky.  The implementations of longAt:[put:] et al in the subclasses are only for simulation.  The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are.  The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware.  Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions. 


Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

David T. Lewis
 
On Fri, Mar 11, 2016 at 12:04:22AM -0800, Eliot Miranda wrote:
>
> This is where it gets tricky.  The implementations of longAt:[put:] et al in the subclasses are only for simulation.  The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are.  The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware.  Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions.
>

You may want to look at package MemoryAccess in the VMMaker repository. I
have not integrated into the oscog branch, but that could probably be done
without too much work.

This is an implementation of the sqMemoryAccess.h macros written entirely
in slang. That means that there is no hidden CPP magic. It is written entirely
in Smalltalk, and the "simulated" macros are what actually gets translated
to C. With full inlining, performance is about the same as the CPP macros
(or at least it was the last time I checked it).

I wrote the package when was working out the 32/64 bit image and host
combinations for VMM trunk. I was finding the CPP macros rather confusing,
so it helped be able to work with them in Smalltalk rather than try to
guess what the macros were going to do.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/11/2016 8:28 AM, David T. Lewis wrote:

>  
> On Fri, Mar 11, 2016 at 12:04:22AM -0800, Eliot Miranda wrote:
>> This is where it gets tricky.  The implementations of longAt:[put:] et al in the subclasses are only for simulation.  The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are.  The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware.  Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions.
>>
> You may want to look at package MemoryAccess in the VMMaker repository. I
> have not integrated into the oscog branch, but that could probably be done
> without too much work.
>
> This is an implementation of the sqMemoryAccess.h macros written entirely
> in slang. That means that there is no hidden CPP magic. It is written entirely
> in Smalltalk, and the "simulated" macros are what actually gets translated
> to C. With full inlining, performance is about the same as the CPP macros
> (or at least it was the last time I checked it).
>
> I wrote the package when was working out the 32/64 bit image and host
> combinations for VMM trunk. I was finding the CPP macros rather confusing,
> so it helped be able to work with them in Smalltalk rather than try to
> guess what the macros were going to do.
>
> Dave
>
>

Thanks guys, this gets closer and closer to what I am trying to understand: how good is the match between the simulation
and the translated version and where does it possibly break down?

I had this idea that, since translation necessarily works with a frozen and closed-world assumption, plus there is no
real compile-time pressure, this could be used to translate almost normal Smalltalk instead of Slang and thus
potentially bring even the static VM development to the masses, as a complement to Sista. But of course, if the
simulation is only a best-efforts approximation, this may not work very well.

In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely
based on reading this relatively obscure code, can you please elucidate a couple of mysteries for me?

1. Was this fetchLong64: bug a V3 VM bug as well or just a simulation bug?
2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian?
3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with
separate calls for sign, instead of just using the signed version (see primitiveAddLargeIntegers)?

Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2
 


On Fri, Mar 11, 2016 at 6:40 AM, Florin Mateoc <[hidden email]> wrote:

On 3/11/2016 8:28 AM, David T. Lewis wrote:
>
> On Fri, Mar 11, 2016 at 12:04:22AM -0800, Eliot Miranda wrote:
>> This is where it gets tricky.  The implementations of longAt:[put:] et al in the subclasses are only for simulation.  The real ones are in platforms/Cross/vm/sqMemoryAccess.h and depend on, or rather are chosen to deal with, the semantics of the actual underlying machine, what its word size, endianness and alignment restrictions are.  The check for alignment above therefore serves to enforce the constraints that the real versions obey on actual hardware.  Hence removing that alignment check would only be valid on 32-bit machines that allowed unaligned 64-but access, a shrinking set these days that doesn't even include x86 in its sse instructions.
>>
> You may want to look at package MemoryAccess in the VMMaker repository. I
> have not integrated into the oscog branch, but that could probably be done
> without too much work.
>
> This is an implementation of the sqMemoryAccess.h macros written entirely
> in slang. That means that there is no hidden CPP magic. It is written entirely
> in Smalltalk, and the "simulated" macros are what actually gets translated
> to C. With full inlining, performance is about the same as the CPP macros
> (or at least it was the last time I checked it).
>
> I wrote the package when was working out the 32/64 bit image and host
> combinations for VMM trunk. I was finding the CPP macros rather confusing,
> so it helped be able to work with them in Smalltalk rather than try to
> guess what the macros were going to do.
>
> Dave
>
>

Thanks guys, this gets closer and closer to what I am trying to understand: how good is the match between the simulation
and the translated version and where does it possibly break down?

I had this idea that, since translation necessarily works with a frozen and closed-world assumption, plus there is no
real compile-time pressure, this could be used to translate almost normal Smalltalk instead of Slang and thus
potentially bring even the static VM development to the masses, as a complement to Sista. But of course, if the
simulation is only a best-efforts approximation, this may not work very well.

The simulation is pretty close.  The JIT's simulation closer.  This is simply history, plus the fact that debugging a JIT is more difficult and therefore more accurate simulation helps.
 
But if you're interested in closed world translations you might contact Gerardo Richarte and Xavier Burroni and ask them about their JIT work.

In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely
based on reading this relatively obscure code, can you please elucidate a couple of mysteries for me?

1. Was this fetchLong64: bug a V3 VM bug as well or just a simulation bug?

Just a simulation bug.  The code generated for the real VM is correct.
  
2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian?

They don't have to.  Large Integers in Smalltalk are always little endian.  Nicolas Cellier has a prototype that would organize then as a sequence of 32-bit words, in which case they would be endian-dependent, but this is problematic because in 32-bit systems SmallInteger is only 31 bits, and so accessing the one and only 32-bit word of the large integer 16rFFFFFFFF answers that large integer itself.  Further, organizing it as a sequence of 16-bit words doesn't help either because 16rFFFF * 16rFFFF overflows 31-bit SmallIntegers. so if one wants to be able to implement large integer arithmetic non-primitively in the image using SmallIntegers, 8 bits is the largest convenient unit.
 
3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with
separate calls for sign, instead of just using the signed version (see primitiveAddLargeIntegers)?

Some large integer primitives want to interpret the bit patterns in large integers as bit patterns and use magnitude64BitValueOf:.  So,e primitives want to interpret the bit patterns in large integers as arithmetic values, failing for LargeNegativeInteger, and use positive64BitValueOf:.  Perhaps positive64BitValueOf: is surplus to requirements, but it fits with the  existing set. BTW, they are /not/ primitives.  They are run-time support functions.  Let's not get confused.

Florin

_,,,^..^,,,_
best, Eliot
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/11/2016 5:47 PM, Eliot Miranda wrote:


<snip>

The simulation is pretty close.  The JIT's simulation closer.  This is simply history, plus the fact that debugging a JIT is more difficult and therefore more accurate simulation helps.
 
But if you're interested in closed world translations you might contact Gerardo Richarte and Xavier Burroni and ask them about their JIT work.

In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely
based on reading this relatively obscure code, can you please elucidate a couple of mysteries for me?

1. Was this fetchLong64: bug a V3 VM bug as well or just a simulation bug?

Just a simulation bug.  The code generated for the real VM is correct.
  
2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian?

They don't have to.  Large Integers in Smalltalk are always little endian.  Nicolas Cellier has a prototype that would organize then as a sequence of 32-bit words, in which case they would be endian-dependent, but this is problematic because in 32-bit systems SmallInteger is only 31 bits, and so accessing the one and only 32-bit word of the large integer 16rFFFFFFFF answers that large integer itself.  Further, organizing it as a sequence of 16-bit words doesn't help either because 16rFFFF * 16rFFFF overflows 31-bit SmallIntegers. so if one wants to be able to implement large integer arithmetic non-primitively in the image using SmallIntegers, 8 bits is the largest convenient unit.
 
3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with
separate calls for sign, instead of just using the signed version (see primitiveAddLargeIntegers)?

Some large integer primitives want to interpret the bit patterns in large integers as bit patterns and use magnitude64BitValueOf:.  So,e primitives want to interpret the bit patterns in large integers as arithmetic values, failing for LargeNegativeInteger, and use positive64BitValueOf:.  Perhaps positive64BitValueOf: is surplus to requirements, but it fits with the  existing set. BTW, they are /not/ primitives.  They are run-time support functions.  Let's not get confused.

Florin

_,,,^..^,,,_
best, Eliot

Thank you for the explanations, especially since I know you are very busy.

As for my interest in closed world translations, I am indeed interested and I know it can be done (the type inferencing and inlining parts), but if I don't have "customers", meaning especially you as Squeak's main vm developer, I won't spend time on it. It is not a trivial project.

Cheers,
Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2
 

On Mar 11, 2016, at 5:09 PM, Florin Mateoc <[hidden email]> wrote:

On 3/11/2016 5:47 PM, Eliot Miranda wrote:


<snip>

The simulation is pretty close.  The JIT's simulation closer.  This is simply history, plus the fact that debugging a JIT is more difficult and therefore more accurate simulation helps.
 
But if you're interested in closed world translations you might contact Gerardo Richarte and Xavier Burroni and ask them about their JIT work.

In addition to the general question above, to help me correct some of my misunderstandings/intuitions, which are solely
based on reading this relatively obscure code, can you please elucidate a couple of mysteries for me?

1. Was this fetchLong64: bug a V3 VM bug as well or just a simulation bug?

Just a simulation bug.  The code generated for the real VM is correct.
  
2. Why do magnitude64BitValueOf: and positive64BitValueOf: not differentiate between BigEndian and LittleEndian?

They don't have to.  Large Integers in Smalltalk are always little endian.  Nicolas Cellier has a prototype that would organize then as a sequence of 32-bit words, in which case they would be endian-dependent, but this is problematic because in 32-bit systems SmallInteger is only 31 bits, and so accessing the one and only 32-bit word of the large integer 16rFFFFFFFF answers that large integer itself.  Further, organizing it as a sequence of 16-bit words doesn't help either because 16rFFFF * 16rFFFF overflows 31-bit SmallIntegers. so if one wants to be able to implement large integer arithmetic non-primitively in the image using SmallIntegers, 8 bits is the largest convenient unit.
 
3. Why do we have both primitives above? They both seem used, but why do some primitives use the first one, coupled with
separate calls for sign, instead of just using the signed version (see primitiveAddLargeIntegers)?

Some large integer primitives want to interpret the bit patterns in large integers as bit patterns and use magnitude64BitValueOf:.  So,e primitives want to interpret the bit patterns in large integers as arithmetic values, failing for LargeNegativeInteger, and use positive64BitValueOf:.  Perhaps positive64BitValueOf: is surplus to requirements, but it fits with the  existing set. BTW, they are /not/ primitives.  They are run-time support functions.  Let's not get confused.

Florin

_,,,^..^,,,_
best, Eliot

Thank you for the explanations, especially since I know you are very busy.

As for my interest in closed world translations, I am indeed interested and I know it can be done (the type inferencing and inlining parts), but if I don't have "customers", meaning especially you as Squeak's main vm developer, I won't spend time on it. It is not a trivial project.

Then maybe we can pull you into some Sista work.  Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code.  But that may be quite an effort and be something we can collaborate on.  But right now the focus is on making what else have now fast and complete.  The "perfect" solution can wait until we can afford the opportunity cost.


Cheers,
Florin
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Florin Mateoc-4
 
On 3/11/2016 9:31 PM, Eliot Miranda wrote:
>  Then maybe we can pull you into some Sista work.  Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code.  But that may be quite an effort and be something we can collaborate on.  But right now the focus is on making what else have now fast and complete.  The "perfect" solution can wait until we can afford the opportunity cost.
>

Well, if there is Sista work that does not involve C, I am interested in that as well
Reply | Threaded
Open this post in threaded view
|

Re: InterpreterSimulator

Eliot Miranda-2

Hi Florin,

> On Mar 11, 2016, at 7:37 PM, Florin Mateoc <[hidden email]> wrote:
>
>
>> On 3/11/2016 9:31 PM, Eliot Miranda wrote:
>> Then maybe we can pull you into some Sista work.  Eventually it will make sense to work in closed world translations, especially if, as Gerardo and Xavier did, one wants to write the VM in pure Smalltalk and have it translate itself (bootstrap itself) to external code.  But that may be quite an effort and be something we can collaborate on.  But right now the focus is on making what else have now fast and complete.  The "perfect" solution can wait until we can afford the opportunity cost.
>
> Well, if there is Sista work that does not involve C, I am interested in that as well

None of Sista involves C.  First, the vast majority of Sista is image level.  It is an SSA based analyser that rewrites bytecode methods to bytecode methods that include unsafe bytecodes.  Second, the JIT fir tgose bytecode methods is all Smalltalk and targets machine code via an abstract assembler-like intermediate language augmented with a model of the stack that also functions as a register allocator.

Sista is developed directly in Smalltalk with no limitations from Slang, or having to generate a VM.  It exists in the image just like the bytecode compiler.

The JIT is developed in the context of the VM simulator.  It does have to obey Slang's restrictions.  But machine code execution etc is via safe simulators such as Bochs so again the development experience is dynamic and safe.

C only enters the picture when generating and compiling a production VM and us a very small part of the overall experience.
123