[Vm-dev] Re: [Cog] Problems with generating code (initialization of options)

Eliot Miranda eliot.miranda at gmail.com
Thu Jun 30 17:03:10 UTC 2011


Hi Igor,

    which shared pool and which constant(s)?  I suspect the problem is in
initializing the shared pools constants, and should not be hacked around in
VMMaker.

On Thu, Jun 30, 2011 at 7:30 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> I found the problem.
> Its in #buildCodeGeneratorForInterpreter
>
> i put a halt in
> addPoolVarsFor: aClass
>        "Add the pool variables for the given class to the code base as
> constants."
>
>        (aClass sharedPools reject: [:pool| pools includes: pool]) do:
>                [:pool |
>                pools add: pool.
>                pool bindingsDo: [:assoc | | val node |
>                        self halt.
>                        val := assoc value.
>                        node := (useSymbolicConstants and:[self isCLiteral:
> val])
>                                                ifTrue:[TDefineNode new
> setName: assoc key asString value: assoc value]
>                                                ifFalse:[TConstantNode new
> setValue: assoc value].
>                        constants at: assoc key asString put: node]].
>
> and it triggered before the halt in:
>
> ObjectMemory>>initializeWithOptions: optionsDictionary
>        "ObjectMemory initializeWithOptions: Dictionary new"
> self halt.
>        self initBytesPerWord: (optionsDictionary at: #BytesPerWord
> ifAbsent: [4])..
>    ...
>
>
> The #initBytesPerWord: initializing VMBasicConstants pool vars.
> But they are already added to codegenerator (with nil values) before
> #initBytesPerWord: are sent.
>
> This is because in #buildCodeGeneratorForInterpreter the
> #addStructClass: adds given shared pool before it get initialized:
>
>  ....
>        (ChangeSet superclassOrder: structClasses asArray) do:
>                [:structClass|
>                structClass initialize.
> a)>>>>          cg addStructClass: structClass].
>
>        interpreterClasses do:
>                [:ic|
>                (ic respondsTo: #initializeWithOptions:)
> b)>>>>                  ifTrue: [ic initializeWithOptions:
> optionsDictionary]
>                        ifFalse: [ic initialize]].
>
>        interpreterClasses do: [:ic| cg addClass: ic].
>        ^cg
>
> apparently, for correct initialization (b) should precede (a) ,
> because once you adding class to code generator it automatically sucks
> all pools vars in, and converts them into TDefineNode before their
> values are properly initialized.
>
> Here the proposed fix (in attachment). I just split the #initialize
> from adding to code generator.
> So, initialization order will remain the same (first a struct classes
> are initialized , and then interpreterClasses),
> because i don't know if its important to initialize struct classes
> before initializing interpreter class(es).
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110630/fde8ba06/attachment.htm


More information about the Vm-dev mailing list