On Thu, Sep 01, 2011 at 12:05:46PM -0300, Esteban Lorenzano wrote:
but BytesPerWorld is the same (it generates a macro). Why is so different to BYTES_PER_WORD?
Esteban
There is a single SQ_VI_BYTES_PER_WORD that is set at compile time (passed as a parameter to the cmake configure script). Macros that depend on this (including BYTES_PER_WORD) are in a header generated by VMMaker. Class vars that depend in bytes per word are gone, replaced by method calls that do the right thing in Smalltalk and generate references to the appropriate C macro when translated. I used unut tests to make sure it was right, and some of these are in VMMaker package for reference.
The end result is that there is no longer a need for VMMaker to generate a separate ./src64 and ./src32 source tree.
(Writing from memory, using my android cell phone with vi editor over ssh - phew!)
Dave
pd: yep, I'm back... Hi to all :)
El 01/09/2011, a las 11:32a.m., David T. Lewis escribi?:
On Thu, Sep 01, 2011 at 04:00:41PM +0200, Igor Stasenko wrote:
I think using ^self cCode: 'BYTES_PER_WORD' inSmalltalk: [self subclassResponsibility "InterpreterSimulator"]
instead of
^BytesPerWord
is a mistake.
It's not a mistake. See the trunk VMMaker, this is part of the fundamental mechanism by which common sources can be generated for 32/64 bit target platforms.
Because i just look at uses of BytesPerWord pool var in sources, and there are 482 references to it. And in generated code it produces just 'BytesPerWord' for it, but not 'BYTES_PER_WORD'
The oscog branch does not contain the support for generating common sources for 32/64 bit platforms. Possibly some minimal support could be added to cover the BytesPerWord issue.
I am away until Monday and I can't offer any better suggestion right now, but I'll look at it when I return.
Dave