headerTypeBytes oddity
Locked
 
|
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. |
|
|
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. |
|
|
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 |
Re: Re: headerTypeBytes oddity
|
|
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 |
|
|
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. |
|
|
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. > 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. |
|
|
In reply to this post by Igor Stasenko
On Wed, Feb 18, 2009 at 5:09 AM, Igor Stasenko <[hidden email]> wrote:
Make this declareC: 'static const sqInt headerTypeBytes[4] = { blablabla}' ^^^^^
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |