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

[David T. Lewis]

On Tue, Sep 06, 2011 at 11:00:07AM +0300, Igor Stasenko wrote:
> 
> On 6 September 2011 07:18, David T. Lewis <lewis at mail.msen.com> wrote:
> >
> > On Thu, Sep 01, 2011 at 10:32:54AM -0400, David T. Lewis wrote:
> >> 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.
> >
> > Oops, I meant to say "32/64 bit object memory", not "32/64 bit platform".
> >
> >>
> >> I am away until Monday and I can't offer any better suggestion
> >> right now, but I'll look at it when I return.
> >
> > I believe that the attached changes will do the right thing when
> > loaded into oscog.
> >
> > Explanation: In VMMaker trunk, bytesPerWord and baseHeaderSize
> > are handled in the C translation dictionary, which translates
> > them to BYTES_PER_WORD and BASE_HEADER_SIZE. In oscog, these
> > translations can be changed to generate BytesPerWord and
> > BaseHeaderSize, which produces the intended source code for
> > oscog in the case of a plugin that uses the "self bytesPerWord"
> > idiom.
> >
> > Note that the oscog branch could be updated with the changes
> > for 32/64 bit object memory common code generation, but this
> > is quite a but of work and has no immediate benefit for Cog,
> > so I am not inclined to worry about it right now.
> >
> > FreetypePlugin should not implement #bytesPerWord. I think
> > it's better to handle it in the code generator.
> >
> 
> so, as i understood your changes allow one to use
> 'self bytesPerWord' idiom?

Yes, that's right. I did not fully test this because I was having
trouble building a working FreetypePlugin with my oscog setup yesterday
and I just ran out of time. But the generated code looks right and
I think that it will address the problem. Excuse the change set, but
I did not want to check anything in to the repositories without
someone looking at it.

Dave