headerTypeBytes oddity

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

headerTypeBytes oddity

Igor Stasenko
 
A headerTypeBytes ivar used in Interpreter, but initialized only once
during its lifetime - in readImageFromFile: f HeapSize:
desiredHeapSize StartingAt: imageOffset),
and with same constants:

        headerTypeBytes at: 0 put: BytesPerWord * 2. "3-word header (type 0)"
        headerTypeBytes at: 1 put: BytesPerWord. "2-word header (type 1)"
        headerTypeBytes at: 2 put: 0. "free chunk (type 2)"
        headerTypeBytes at: 3 put: 0. "1-word header (type 3)"

I think this initialization could be put into static var declaration,
in #declareCVarsIn:
        aCCodeGenerator
                var: #headerTypeBytes
                declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'.
       
then we don't have to pollute already complex #readImageFromFile:...
method with odd stuff like this.

It maybe not worth much attention for Squeak VM, but for Hydra, i
found that this ivar placed into Interpreter struct (which means that
each instance of interpreter will having separate  headerTypeBytes).
There are tons of ivars in ObjectMemory and Interpreter and its hard
to track all, which worth keeping on a per-interpreter basis :)

--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: headerTypeBytes oddity

Igor Stasenko
 
sorry for ranting , but i tend to hate more and more VMMaker's code generator :)
It lacks a most critical feature, which is highly important for such
complex projects like VM: data encapsulation.
To write a quite simple method, i have spent 10 hours , rewriting it
again and again , splitting it to more shorter methods, just to keep
code readable (if 'readable' term can be applied to slang ;) .

I even started to write own C code generator, which would allow a
decomposition of a huge ObjectMemory+Interpreter to a set of smaller,
more isolated classes.
For instance, we can declare a special MemoryOop class to write:
 oop header   vs    self longAt: oop.
 oop isMarked  vs  ((self longAt: oop) bitAnd: MarkBit) ~= 0
 oop isIntegerObject vs  self isIntegerObject: oop
this list can be continued...


2009/2/18 Igor Stasenko <[hidden email]>:

> A headerTypeBytes ivar used in Interpreter, but initialized only once
> during its lifetime - in readImageFromFile: f HeapSize:
> desiredHeapSize StartingAt: imageOffset),
> and with same constants:
>
>        headerTypeBytes at: 0 put: BytesPerWord * 2.            "3-word header (type 0)"
>        headerTypeBytes at: 1 put: BytesPerWord.                "2-word header (type 1)"
>        headerTypeBytes at: 2 put: 0.                                   "free chunk (type 2)"
>        headerTypeBytes at: 3 put: 0.                                   "1-word header (type 3)"
>
> I think this initialization could be put into static var declaration,
> in #declareCVarsIn:
>        aCCodeGenerator
>                var: #headerTypeBytes
>                declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'.
>
> then we don't have to pollute already complex #readImageFromFile:...
> method with odd stuff like this.
>
> It maybe not worth much attention for Squeak VM, but for Hydra, i
> found that this ivar placed into Interpreter struct (which means that
> each instance of interpreter will having separate  headerTypeBytes).
> There are tons of ivars in ObjectMemory and Interpreter and its hard
> to track all, which worth keeping on a per-interpreter basis :)
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: headerTypeBytes oddity

David T. Lewis
In reply to this post by Igor Stasenko
 
On Wed, Feb 18, 2009 at 03:09:22PM +0200, Igor Stasenko wrote:

>  
> A headerTypeBytes ivar used in Interpreter, but initialized only once
> during its lifetime - in readImageFromFile: f HeapSize:
> desiredHeapSize StartingAt: imageOffset),
> and with same constants:
>
> headerTypeBytes at: 0 put: BytesPerWord * 2. "3-word header (type 0)"
> headerTypeBytes at: 1 put: BytesPerWord. "2-word header (type 1)"
> headerTypeBytes at: 2 put: 0. "free chunk (type 2)"
> headerTypeBytes at: 3 put: 0. "1-word header (type 3)"
>
> I think this initialization could be put into static var declaration,
> in #declareCVarsIn:
> aCCodeGenerator
> var: #headerTypeBytes
> declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'.
>
> then we don't have to pollute already complex #readImageFromFile:...
> method with odd stuff like this.

Igor,

Can you make a Mantis entry for this? It looks like an easy and harmless
change, but it would be good to have a record of it on Mantis so the
various VM projects can keep in sync.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Re: headerTypeBytes oddity

David T. Lewis
In reply to this post by Igor Stasenko
 
On Wed, Feb 18, 2009 at 03:32:36PM +0200, Igor Stasenko wrote:
>  
> sorry for ranting , but i tend to hate more and more VMMaker's code generator :)
> It lacks a most critical feature, which is highly important for such
> complex projects like VM: data encapsulation.
> To write a quite simple method, i have spent 10 hours , rewriting it
> again and again , splitting it to more shorter methods, just to keep
> code readable (if 'readable' term can be applied to slang ;) .

FWIW, there are a number of fixes for slang code generation and inlining
on Mantis and included in the SqueakSource VMMaker project. I have
tried to keep pointers to the Mantis entries in the MCZ headers so
you can find the relevant change sets on Mantis. If you are writing
methods with embedded C code or declarations and you want the inliner
to work, you will probably want to have these.

Dave

Reply | Threaded
Open this post in threaded view
|

Re: Re: headerTypeBytes oddity

Igor Stasenko
 
2009/2/19 David T. Lewis <[hidden email]>:

>
> On Wed, Feb 18, 2009 at 03:32:36PM +0200, Igor Stasenko wrote:
>>
>> sorry for ranting , but i tend to hate more and more VMMaker's code generator :)
>> It lacks a most critical feature, which is highly important for such
>> complex projects like VM: data encapsulation.
>> To write a quite simple method, i have spent 10 hours , rewriting it
>> again and again , splitting it to more shorter methods, just to keep
>> code readable (if 'readable' term can be applied to slang ;) .
>
> FWIW, there are a number of fixes for slang code generation and inlining
> on Mantis and included in the SqueakSource VMMaker project. I have
> tried to keep pointers to the Mantis entries in the MCZ headers so
> you can find the relevant change sets on Mantis. If you are writing
> methods with embedded C code or declarations and you want the inliner
> to work, you will probably want to have these.
>

Yes, i'm aware of that. Thanks for reminder.
I trying to avoid embedding C code at all. In all cases where it
possible, i replacing them with semantically equivalent slang code.


> Dave
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: headerTypeBytes oddity

Igor Stasenko
In reply to this post by David T. Lewis
 
2009/2/19 David T. Lewis <[hidden email]>:

>
> On Wed, Feb 18, 2009 at 03:09:22PM +0200, Igor Stasenko wrote:
>>
>> A headerTypeBytes ivar used in Interpreter, but initialized only once
>> during its lifetime - in readImageFromFile: f HeapSize:
>> desiredHeapSize StartingAt: imageOffset),
>> and with same constants:
>>
>>       headerTypeBytes at: 0 put: BytesPerWord * 2.            "3-word header (type 0)"
>>       headerTypeBytes at: 1 put: BytesPerWord.                "2-word header (type 1)"
>>       headerTypeBytes at: 2 put: 0.                                   "free chunk (type 2)"
>>       headerTypeBytes at: 3 put: 0.                                   "1-word header (type 3)"
>>
>> I think this initialization could be put into static var declaration,
>> in #declareCVarsIn:
>>       aCCodeGenerator
>>               var: #headerTypeBytes
>>               declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'.
>>
>> then we don't have to pollute already complex #readImageFromFile:...
>> method with odd stuff like this.
>
> Igor,
>
> Can you make a Mantis entry for this? It looks like an easy and harmless
> change, but it would be good to have a record of it on Mantis so the
> various VM projects can keep in sync.
>
i found one reason why it initialized there - because of simulation.
If you remove that code and try to run VM simulated, this ivar will
not be properly initialized.
Anyway, i think it would be better to place this code somewhere else
that in #readImageFromFile:
In Hydra, i having #initializeVM method where i can place it and
forget about it.
In Squeak VM, this could be difficult - the main issue is to get it
properly initialized in simulation.

> Dave
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: headerTypeBytes oddity

Eliot Miranda-2
In reply to this post by Igor Stasenko
 


On Wed, Feb 18, 2009 at 5:09 AM, Igor Stasenko <[hidden email]> wrote:

A headerTypeBytes ivar used in Interpreter, but initialized only once
during its lifetime - in readImageFromFile: f HeapSize:
desiredHeapSize StartingAt: imageOffset),
and with same constants:

       headerTypeBytes at: 0 put: BytesPerWord * 2.            "3-word header (type 0)"
       headerTypeBytes at: 1 put: BytesPerWord.                "2-word header (type 1)"
       headerTypeBytes at: 2 put: 0.                                   "free chunk (type 2)"
       headerTypeBytes at: 3 put: 0.                                   "1-word header (type 3)"

I think this initialization could be put into static var declaration,
in #declareCVarsIn:
       aCCodeGenerator
               var: #headerTypeBytes
               declareC: 'static sqInt headerTypeBytes[4] = { blablabla}'.

Make this  declareC: 'static const sqInt headerTypeBytes[4] = { blablabla}'
                                         ^^^^^


then we don't have to pollute already complex #readImageFromFile:...
method with odd stuff like this.

It maybe not worth much attention for Squeak VM, but for Hydra, i
found that this ivar placed into Interpreter struct (which means that
each instance of interpreter will having separate  headerTypeBytes).
There are tons of ivars in ObjectMemory and Interpreter and its hard
to track all, which worth keeping on a per-interpreter basis :)

--
Best regards,
Igor Stasenko AKA sig.