Smalltalk › Squeak › Squeak VM

[commit][2831] Fix redef of BaseHeaderSize in platforms/Cross/plugins/ IA32ABI/ia32abicc.c.

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

18 messages Options

commits-3

[commit][2831] Fix redef of BaseHeaderSize in platforms/Cross/plugins/ IA32ABI/ia32abicc.c.

Revision: 2831
Author: eliot
Date: 2013-12-11 16:38:39 -0800 (Wed, 11 Dec 2013)
Log Message:
-----------
Fix redef of BaseHeaderSize in platforms/Cross/plugins/IA32ABI/ia32abicc.c.

Modified Paths:
--------------
trunk/platforms/Cross/plugins/IA32ABI/ia32abicc.c

Modified: trunk/platforms/Cross/plugins/IA32ABI/ia32abicc.c
===================================================================
--- trunk/platforms/Cross/plugins/IA32ABI/ia32abicc.c 2013-12-12 00:37:38 UTC (rev 2830)
+++ trunk/platforms/Cross/plugins/IA32ABI/ia32abicc.c 2013-12-12 00:38:39 UTC (rev 2831)
@@ -52,7 +52,9 @@
# error cannot determine image word size/object header size
#endif

-#define BaseHeaderSize BytesPerOop
+#if !defined(BaseHeaderSize)
+# define BaseHeaderSize BytesPerOop
+#endif

#ifdef _MSC_VER
# define alloca _alloca

tty

Re: [commit][2831] Fix redef of BaseHeaderSize in platforms/Cross/plugins/ IA32ABI/ia32abicc.c.

For VM Development,

Is it best to (attempt) a build of CogVM using the VMMaker in the development image whenever the C code changes underneath?

thx,

tty

tty

CogVMSimulator->>ensureMultiThreadingOverridesAreUpToDate Parser method missing

FYI

Launching CogVMSimualtor on latest Trunk for Squeak4.5 using:

(CogVMSimulator newWithOptions: #(Cogit StackToRegisterMappingCogit))
    desiredNumStackPages: 8;
    openOn: '/home/wm/usr/src/smalltalk/buildCogDevelopmentImageCog.app/Contents/Resources/Squeak4.5.image';
    openAsMorph;
    run

Debugger entered in:ensureMultiThreadingOverridesAreUpToDate
at a message send to Parser

        argNames := Parser new
                            initPattern: (mtInterpreterClass sourceCodeAt: sel)
                            notifying: nil
                            return: [:pattern| pattern second].

Which does not exist in latest Trunk of Squeak4.5

An older trunk version (Squeak4.5 latest update: #12641) does have that message

Latest trunk does have:

Parser >> initPattern: aString return: aBlock

Commenting out the "notifiying: nil" in the message send enables the simulator to run.

cordially

tty

Eliot Miranda-2

Re: [commit][2831] Fix redef of BaseHeaderSize in platforms/Cross/plugins/ IA32ABI/ia32abicc.c.

In reply to this post by tty

On Dec 12, 2013, at 5:03 AM, gettimothy <[hidden email]> wrote:

For VM Development,

Is it best to (attempt) a build of CogVM using the VMMaker in the development image whenever the C code changes underneath?

IMO no. The two sides should change only when needed.

thx,

tty

Eliot (phone)

tty

Re: [commit][2831] Fix redef of BaseHeaderSize in platforms/Cross/plugins/ IA32ABI/ia32abicc.c.

thx.

tty

---- On Thu, 12 Dec 2013 07:42:30 -0800 Eliot Miranda<[hidden email]> wrote ----

On Dec 12, 2013, at 5:03 AM, gettimothy <[hidden email]> wrote:

For VM Development,

Is it best to (attempt) a build of CogVM using the VMMaker in the development image whenever the C code changes underneath?

IMO no. The two sides should change only when needed.

thx,

tty

Eliot (phone)

tty

CompiledMethod display interpretation

In reply to this post by Eliot Miranda-2

I am working throught Eliot's Contexts/Closures posts and have a question about what I am seeing in two different displays of the same CompiledMethod.
My question is about the different ways CompiledMethod is displayed and specifically how to interpret them in the explorer given in his example.

I have attached a screenshot of Squeak4.0 studying the "Error: Attempt to evaluate a block that is already being evaluated" error is discussion is presented.

On the left is the explorer view from Eliot's post (this one has a different home, other than that, its identical to his example)
To the right of that is a Browser on the compiled method of the class I wrapped the factorial example in. (MethodWithFactorialBlockContext methodDict at:#factorialExampleFromMethod) so I could examine it in detail.
What am I looking at on the left?

Am I looking at the CompiledMethod structure? Are these the raw bytecodes?

     + Object Header
    + Method Header
       + 2 bits upper primitive index
       + 4 bits number of arguments
       + 6 bits number of temporaries
       + 1 bit Large Context flag
       + 8 bits number of literals
       + 9 bits lower primitive index
    + Literal Frame
    + Bytcodes
    + Source pointer
       + 4 bits of encoded source pointer

Thx for your time

tty

CompiledMethodViews.png (113K) Download Attachment

Bob Arning-2

Re: CompiledMethod display interpretation

Tim,

Newer squeaks have the same printing on both explorer and inspector. See CompiledMethod>>explorerContents in a newer image.

Cheers,
Bob

On 12/14/13 10:37 AM, gettimothy wrote:

My question is about the different ways CompiledMethod is displayed and specifically how to interpret them in the explorer given in his example.

tty

Re: CompiledMethod display interpretation

Thanks Bob.

I figured out what I was lookiing at. I was operating under 3 mis-conceptions when I posted that question.

1. In the same way a browser and regular explorer have different ways of looking at a thing. I thought the explorer in a BlockClosure displayed a "special top-secret VM Coder's Only view" of a CompiledMethod in its >root>home>method area.
2. Misconception 1 happened because I wrongly thought the 'CompiledMethod I had highlighted was the SAME compiled method for the method, just displayed differentyl. .They are not--its obvious now that I know where to look. CompiledMethod(210) in the BlockContext vs CompiledMethod(3931) in the methodDict of the test class I was using. CompiledMethod(210) contains a subset of the bytecodes in CompiledMethod(3931), but its header and number of literals are different.
3. I was using my notes from study of Squeak Object Engine to try to clean the structure. The information I needed is in the class comment of CompiledMethod.

Sorry for the noise.

tty

---- On Sat, 14 Dec 2013 08:10:25 -0800 Bob Arning<[hidden email]> wrote ----

Tim,

Newer squeaks have the same printing on both explorer and inspector. See CompiledMethod>>explorerContents in a newer image.

Cheers,
Bob

On 12/14/13 10:37 AM, gettimothy wrote:

368683296.-3227807675484921300@..." type="cite">My question is about the different ways CompiledMethod is displayed and specifically how to interpret them in the explorer given in his example.

CompiledMethodViewsTheSequel.png (129K) Download Attachment

Bob Arning-2

Re: CompiledMethod display interpretation

Just so you are not heading astray, CM210 has *fewer* bytecodes than CM3931 and *many* of CM210's bytecodes are also in CM3931, but the former is not a subset of the latter, either by happenstance or some sort of magic sharing of bytecodes. They are just similar because they are compiled from similar source code.

Cheers,
Bob

On 12/14/13 4:29 PM, gettimothy wrote:

2. Misconception 1 happened because I wrongly thought the 'CompiledMethod I had highlighted was the SAME compiled method for the method, just displayed differentyl. .They are not--its obvious now that I know where to look. CompiledMethod(210) in the BlockContext vs CompiledMethod(3931) in the methodDict of the test class I was using. CompiledMethod(210) contains a subset of the bytecodes in CompiledMethod(3931), but its header and number of literals are different.

tty

Re: CompiledMethod display interpretation

Thanks, but its worse than that--call it initial flailing as I learn the system level stuff.

My misconception 2 was not the misconception I thought it was. It is the difference between a BlockContext created in a MethodContext vs that created in a DoIt.

Object subclass: #MethodWithFactorialBlockContext >>factorialExampleFromMethod
    | factorial |
    factorial := [:n | n = 1 ifTrue: [1] ifFalse:[(factorial value: n-1) * n]].
    (1 to: 10) collect: factorial.
    ^factorial

If I explore the block to the right of factorial, I get an explorer titled: "[ ] in MethodWithFacorialBlockCo..etc..." which, I assumed was the BlockContext "associated" with that method. Its not. It is the same thing you get when you put the block in a Workspace and explore that.

However, if you execute that method

| m |
m := MethodWithFactorialBlockContext new.
m factorialExampleFromMethod.

it throws an error; then, exploring the BlockContext from the debugger does show the CompiledMethod and lo-and-behold it is the same CompiledMethod as that in the class methodDict. Just like it says in the BlueBook.

So, the lesson learned is, "when evaluating contexts, be sure of the context you are evaluating otherwise, you may spend a day looking at the wrong stuff and posting dumb posts to squeak-vm-dev".

Cordially,

tty

---- On Sat, 14 Dec 2013 14:38:15 -0800 Bob Arning<[hidden email]> wrote ----

Just so you are not heading astray, CM210 has *fewer* bytecodes than CM3931 and *many* of CM210's bytecodes are also in CM3931, but the former is not a subset of the latter, either by happenstance or some sort of magic sharing of bytecodes. They are just similar because they are compiled from similar source code.

Cheers,
Bob

On 12/14/13 4:29 PM, gettimothy wrote:

[hidden email]" type="cite">2. Misconception 1 happened because I wrongly thought the 'CompiledMethod I had highlighted was the SAME compiled method for the method, just displayed differentyl. .They are not--its obvious now that I know where to look. CompiledMethod(210) in the BlockContext vs CompiledMethod(3931) in the methodDict of the test class I was using. CompiledMethod(210) contains a subset of the bytecodes in CompiledMethod(3931), but its header and number of literals are different.

Ben Coman

Re: CompiledMethod display interpretation

gettimothy wrote:

 
Thanks, but its worse than that--call it initial flailing as I learn the system level stuff.

My misconception 2 was not the misconception I thought it was. It is the difference between a BlockContext created in a MethodContext vs that created in a DoIt.

Object subclass: #MethodWithFactorialBlockContext >>factorialExampleFromMethod
    | factorial |
    factorial := [:n | n = 1 ifTrue: [1] ifFalse:[(factorial value: n-1) * n]].
    (1 to: 10) collect: factorial.
    ^factorial

If I explore the block to the right of factorial, I get an explorer titled: "[ ] in MethodWithFacorialBlockCo..etc..." which, I assumed was the BlockContext "associated" with that method. Its not. It is the same thing you get when you put the block in a Workspace and explore that.

However, if you execute that method

| m |
m := MethodWithFactorialBlockContext new.
m factorialExampleFromMethod.

it throws an error; then, exploring the BlockContext from the debugger does show the CompiledMethod and lo-and-behold it is the same CompiledMethod as that in the class methodDict. Just like it says in the BlueBook.

So, the lesson learned is, "when evaluating contexts, be sure of the context you are evaluating otherwise, you may spend a day looking at the wrong stuff and posting dumb posts to squeak-vm-dev".

Cordially,

tty

When things appear to be working, it could just be reinforcing your misconceptions! Its when things fail that you learn the most.
cheers -ben

---- On Sat, 14 Dec 2013 14:38:15 -0800 Bob Arning[hidden email] wrote ----

Just so you are not heading astray, CM210 has *fewer* bytecodes than CM3931 and *many* of CM210's bytecodes are also in CM3931, but the former is not a subset of the latter, either by happenstance or some sort of magic sharing of bytecodes. They are just similar because they are compiled from similar source code.

Cheers,
Bob

On 12/14/13 4:29 PM, gettimothy wrote:

[hidden email]" type="cite">2. Misconception 1 happened because I wrongly thought the 'CompiledMethod I had highlighted was the SAME compiled method for the method, just displayed differentyl. .They are not--its obvious now that I know where to look. CompiledMethod(210) in the BlockContext vs CompiledMethod(3931) in the methodDict of the test class I was using. CompiledMethod(210) contains a subset of the bytecodes in CompiledMethod(3931), but its header and number of literals are different.

tty

defensive error checking in a BlockContext environment for [:n | n = 1 ifTrue: [1] ifFalse:[(factorial value: n-1) * n]]

Please shoot this down, if it is incorrect. (no details necessary, just a yes,no is sufficient)

In the discussion on the re-entrant problem for BlockContexts regarding this code:

        | factorial |
        factorial := [:n| n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n]].
        (1 to: 10) collect: factorial

This statement: "The block can’t be reentered without overwriting the sender field, preventing return to the first caller. "

Does not mean that the bock is reentered, the sender field is over-written and when we get to n=10 stage things go kablooie.
What happens is the coders detect this condition and the primitive code will not allow a sender to be over-written.
The error that is thrown is purposeful and defensive

I don't know what I am looking at yet, but I think that error check happens here:

Interpreter >> primitiveValueWithArgs
    | argumentArray blockContext blockArgumentCount arrayArgumentCount initialIP |
    argumentArray _ self popStack.
    blockContext _ self popStack.
    blockArgumentCount _ self argumentCountOfBlock: blockContext.
    "If the argArray isnt actually an Array we ahve to unpop the above two"
    (self isArray: argumentArray) ifFalse: [self unPop:2. ^self primitiveFail].
.....

Sound about right?

thx.

tty

Bob Arning-2

Re: defensive error checking in a BlockContext environment for [:n | n = 1 ifTrue: [1] ifFalse:[(factorial value: n-1) * n]]

Not sure which version VM you are looking at, but long ago, it was:

primitiveValueWithArgs

    | argumentArray blockContext blockArgumentCount arrayArgumentCount initialIP |
    argumentArray _ self popStack.
    blockContext _ self popStack.
    blockArgumentCount _ self argumentCountOfBlock: blockContext.
    self assertClassOf: argumentArray is: (self splObj: ClassArray).
    successFlag ifTrue: [
        arrayArgumentCount _ self fetchWordLengthOf: argumentArray.
        self success: (arrayArgumentCount = blockArgumentCount
            and: [(self fetchPointer: CallerIndex ofObject: blockContext) = nilObj])]. <<<re-entrant detection
...

So, your snippet looks close, but not quite there.

Cheers,
Bob

On 12/15/13 11:25 AM, gettimothy wrote:

 
Please shoot this down, if it is incorrect. (no details necessary, just a yes,no is sufficient)

In the discussion on the re-entrant problem for BlockContexts regarding this code:

        | factorial |
        factorial := [:n| n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n]].
        (1 to: 10) collect: factorial

This statement: "The block can’t be reentered without overwriting the sender field, preventing return to the first caller. "

Does not mean that the bock is reentered, the sender field is over-written and when we get to n=10 stage things go kablooie.
What happens is the coders detect this condition and the primitive code will not allow a sender to be over-written.
The error that is thrown is purposeful and defensive

I don't know what I am looking at yet, but I think that error check happens here:

Interpreter >> primitiveValueWithArgs
    | argumentArray blockContext blockArgumentCount arrayArgumentCount initialIP |
    argumentArray _ self popStack.
    blockContext _ self popStack.
    blockArgumentCount _ self argumentCountOfBlock: blockContext.
    "If the argArray isnt actually an Array we ahve to unpop the above two"
    (self isArray: argumentArray) ifFalse: [self unPop:2. ^self primitiveFail].
.....

Sound about right?

thx.

tty

tty

Re: defensive error checking in a BlockContext environment for [:n | n = 1 ifTrue: [1] ifFalse:[(factorial value: n-1) * n]]

Very interesting, thanks.

I am running Squeak 4.0 and just loaded an early VMMaker that would load cleanly (VMMaker-tpr.10) so I could have access to the bytecode table and primitive source in Interpreter.

---- On Sun, 15 Dec 2013 11:43:28 -0800 Bob Arning<[hidden email]> wrote ----

Not sure which version VM you are looking at, but long ago, it was:

primitiveValueWithArgs

    | argumentArray blockContext blockArgumentCount arrayArgumentCount initialIP |
    argumentArray _ self popStack.
    blockContext _ self popStack.
    blockArgumentCount _ self argumentCountOfBlock: blockContext.
    self assertClassOf: argumentArray is: (self splObj: ClassArray).
    successFlag ifTrue: [
        arrayArgumentCount _ self fetchWordLengthOf: argumentArray.
        self success: (arrayArgumentCount = blockArgumentCount
            and: [(self fetchPointer: CallerIndex ofObject: blockContext) = nilObj])]. <<<re-entrant detection
...

So, your snippet looks close, but not quite there.

Cheers,
Bob

On 12/15/13 11:25 AM, gettimothy wrote:

[hidden email]" type="cite">
 
Please shoot this down, if it is incorrect. (no details necessary, just a yes,no is sufficient)

In the discussionon the re-entrant problem for BlockContexts regarding this code:

        | factorial |
        factorial := [:n| n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n]].
        (1 to: 10) collect: factorial

This statement: "The block can’t be reentered without overwriting the sender field, preventing return to the first caller. "

Does not mean that the bock is reentered, the sender field is over-written and when we get to n=10 stage things go kablooie.
What happens is the coders detect this condition and the primitive code will not allow a sender to be over-written.
The error that is thrown is purposeful and defensive

I don't know what I am looking at yet, but I think that error check happens here:

Interpreter >> primitiveValueWithArgs
    | argumentArray blockContext blockArgumentCount arrayArgumentCount initialIP |
    argumentArray _ self popStack.
    blockContext _ self popStack.
    blockArgumentCount _ self argumentCountOfBlock: blockContext.
    "If the argArray isnt actually an Array we ahve to unpop the above two"
    (self isArray: argumentArray) ifFalse: [self unPop:2. ^self primitiveFail].
.....

Sound about right?

thx.

tty

tty

Does anybody have a valid link to The Hitchhiker's Guide to the Smalltalk Compiler?

In reply to this post by Bob Arning-2

The link at Eliot's blog bums out as do the links at the varous squeak/smalltalk sites/wiki's.

The author is at 3 + 4 blog, but contact information is through linkedin (which I don't use)

thx,

tty

Eliot Miranda-2

Re: defensive error checking in a BlockContext environment for [:n | n = 1 ifTrue: [1] ifFalse:[(factorial value: n-1) * n]]

In reply to this post by tty

On Sun, Dec 15, 2013 at 8:25 AM, gettimothy <[hidden email]> wrote:

Please shoot this down, if it is incorrect. (no details necessary, just a yes,no is sufficient)

In the discussion on the re-entrant problem for BlockContexts regarding this code:

        | factorial |
        factorial := [:n| n = 1 ifTrue: [1] ifFalse: [(factorial value: n - 1) * n]].
        (1 to: 10) collect: factorial

This statement: "The block can’t be reentered without overwriting the sender field, preventing return to the first caller. "

Does not mean that the bock is reentered, the sender field is over-written and when we get to n=10 stage things go kablooie.
What happens is the coders detect this condition and the primitive code will not allow a sender to be over-written.
The error that is thrown is purposeful and defensive

I don't know what I am looking at yet, but I think that error check happens here:

Interpreter >> primitiveValueWithArgs
    | argumentArray blockContext blockArgumentCount arrayArgumentCount initialIP |
    argumentArray _ self popStack.
    blockContext _ self popStack.
    blockArgumentCount _ self argumentCountOfBlock: blockContext.
    "If the argArray isnt actually an Array we ahve to unpop the above two"
    (self isArray: argumentArray) ifFalse: [self unPop:2. ^self primitiveFail].
.....

Sound about right?

Well, in the BlueBook the primitive didn't detect this and one could recurse and things *would* go kablooie when n got to 1 (its when the block returns that things go kablooie and that happens the first time "ifTrue: [1]" is executed).

--
best,

Eliot

dcorking

Re: Does anybody have a valid link to The Hitchhiker's Guide to the Smalltalk Compiler?

In reply to this post by tty

tty:

another visit to the Wayback Machine uncovered a good copy (not yet
blocked by the domain squatters):

http://web.archive.org/web/20010419215257/http://www.smalltalkchronicles.net/edition2-1/st_compiler.htm

Have fun! David

tty

Re: Does anybody have a valid link to The Hitchhiker's Guide to the Smalltalk Compiler?

Awesome.

Thank you.

tty.

---- On Thu, 19 Dec 2013 13:23:19 -0800 David Corking<[hidden email]> wrote ----

tty:

another visit to the Wayback Machine uncovered a good copy (not yet
blocked by the domain squatters):

http://web.archive.org/web/20010419215257/http://www.smalltalkchronicles.net/edition2-1/st_compiler.htm

Have fun! David