On Wed, Dec 19, 2012 at 10:27 AM, Eliot Miranda eliot.miranda@gmail.comwrote:

Hi Igor,

On Wed, Dec 19, 2012 at 4:59 AM, Igor Stasenko siguctua@gmail.com wrote:

...

Hello,

i am lost (again) what , where, and how things should be initialized, and in what order in order to generate code for Cog.

After Esteban merged VMMaker with latest , i ran into issue with 'isPushNilFunction' == nil.

The problem is that it is class instance variable..

...

Since i made own subclass of

StackToRegisterMappingCogit

and doing

'myclass initializeWithOptions: ... '

it initializes isPushNilFunction variable properly there.

Now at early stages of code generation a run into error, because CCodeGenerator walks over superclasses and doing #addClass: for each..

it breaks in StackToRegisterMappingCogit class>>declareCVarsIn: aCodeGen

            >>      declareC: 'sqInt (*isPushNilFunction)(struct

_BytecodeDescriptor *,sqInt,sqInt,sqInt) = ', (aCodeGen cFunctionNameFor: isPushNilFunction);

because, of course isPushNilFunction variable has separate value for this class than in my subclass.

OK, I'll make an accessor. Ah, the accessors already exist. All that needs to happen is to send the accessors instead of access the inst vars in StackToRegisterMappingCogit class>>declareCVarsIn: aCodeGen

-- best, Eliot

On 19 December 2012 19:32, Eliot Miranda eliot.miranda@gmail.com wrote:

On Wed, Dec 19, 2012 at 10:31 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

On Wed, Dec 19, 2012 at 10:27 AM, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Hi Igor,

On Wed, Dec 19, 2012 at 4:59 AM, Igor Stasenko siguctua@gmail.com wrote:

...

Hello,

i am lost (again) what , where, and how things should be initialized, and in what order in order to generate code for Cog.

After Esteban merged VMMaker with latest , i ran into issue with 'isPushNilFunction' == nil.

The problem is that it is class instance variable..

Since i made own subclass of

StackToRegisterMappingCogit

and doing

'myclass initializeWithOptions: ... '

it initializes isPushNilFunction variable properly there.

Now at early stages of code generation a run into error, because CCodeGenerator walks over superclasses and doing #addClass: for each..

it breaks in StackToRegisterMappingCogit class>>declareCVarsIn: aCodeGen

            >>      declareC: 'sqInt (*isPushNilFunction)(struct _BytecodeDescriptor

*,sqInt,sqInt,sqInt) = ', (aCodeGen cFunctionNameFor: isPushNilFunction);

because, of course isPushNilFunction variable has separate value for this class than in my subclass.

OK, I'll make an accessor. Ah, the accessors already exist. All that needs to happen is to send the accessors instead of access the inst vars in StackToRegisterMappingCogit class>>declareCVarsIn: aCodeGen

and in StackToRegisterMappingCogit class>>requiredMethiodNames

I fear that it won't change anything.

Because code generator is too clever: first it manually goes over all superclasses of my class (in buildCodeGeneratorForInterpreter:) and then it sends #declareCVarsIn: directly to all those classes. So there is no way, how initialized value of class inst var in my subclass, can magically appear in StackToRegisterMappingCogit, where it was never initialized.

i wonder why we cannot put this logic at right place: into classes themselves, and make code generator to be a simple-minded client which listening for instructions.

then you won't need hacks like:

(aClass inheritsFrom: VMStructType) ifFalse: [variables addAll: aClass instVarNames].

or:

self class == thisContext methodClass ifFalse: [^self]. "Don't duplicate decls in subclasses"

-- best, Eliot

Igor,

quite so. Perhaps I'll have time to change this soon. SHouldn't be hard. The test is straight-forward. if after the change the system spits out unchanged source it is working :)

On Wed, Dec 19, 2012 at 7:12 PM, Igor Stasenko siguctua@gmail.com wrote:

yeah.. just looked again at #buildCodeGeneratorForCogit: getAPIMethods

    cogitClasses := OrderedCollection new.
    [cogitClasses addFirst: cogitClass.
     cogitClass ~~ Cogit
     and: [cogitClass inheritsFrom: Cogit]] whileTrue:
            [cogitClass := cogitClass superclass].
    cogitClasses addFirst: VMClass.
    cogitClasses addAllLast: self cogitClass ancilliaryClasses.
    cogitClasses do: [:cgc| cg addClass: cgc].
    (cg structClassesForTranslationClasses: cogitClasses) do:
            [:structClass| cg addStructClass: structClass].

see what wrong there?

it letting vmmaker to decide for a class what to do, instead letting class to decide for itself. This logic is clearly do not belongs to right place.

On Fri, Dec 21, 2012 at 4:24 PM, Igor Stasenko siguctua@gmail.com wrote:

On 21 December 2012 22:09, Eliot Miranda eliot.miranda@gmail.com wrote:

...

Igor,

quite so.  Perhaps I'll have time to change this soon.  SHouldn't be

hard. The test is straight-forward. if after the change the system spits out unchanged source it is working :)

...

I can do it. Because i have a lot of pressure from Pharo team to fix VM... i don't want to rollback last commit which broken our builds but instead fix that stuff.

I will create a separate .cs so that you can easily merge it with your branch.

thanks!! Happy Holidays...

...

On Wed, Dec 19, 2012 at 7:12 PM, Igor Stasenko siguctua@gmail.com

wrote:

...

...

yeah.. just looked again at #buildCodeGeneratorForCogit: getAPIMethods

    cogitClasses := OrderedCollection new.
    [cogitClasses addFirst: cogitClass.
     cogitClass ~~ Cogit
     and: [cogitClass inheritsFrom: Cogit]] whileTrue:
            [cogitClass := cogitClass superclass].
    cogitClasses addFirst: VMClass.
    cogitClasses addAllLast: self cogitClass ancilliaryClasses.
    cogitClasses do: [:cgc| cg addClass: cgc].
    (cg structClassesForTranslationClasses: cogitClasses) do:
            [:structClass| cg addStructClass: structClass].

see what wrong there?

it letting vmmaker to decide for a class what to do, instead letting class to decide for itself. This logic is clearly do not belongs to right place.

-- best, Eliot

-- Best regards, Igor Stasenko.