[Vm-dev] Re: About Freetype plugin and BYTES_PER_WORD

David T. Lewis lewis at mail.msen.com
Fri Sep 2 17:10:09 UTC 2011


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
> > 
> > 


More information about the Vm-dev mailing list