About Freetype plugin and BYTES_PER_WORD

> Hi, Dave,
> your changes are not working well with Cog builds, since this macro is
> not defined anywhere.
> Do you know, what/where it should be defined?
>
>
> Name: Freetype-Plugin-dtl.62
> Author: dtl
> Time: 21 August 2011, 12:03:54.438 pm
> UUID: 0bae20f0-a128-4120-9276-252374a8a5ae
> Ancestors: Freetype-Plugin-IgorStasenko.61
>
> Update bytesPerWord for compatibility with VMMaker trunk.
>
> Background: VMM trunk generates code for 32/64 bit object memories as
> compile time option. The code generator emits required macros, and
> many class variables (e.g. BYTES_PER_WORD) no longer exist in the
> image. The trunk ObjectMemory>>bytesPerWord will work for both oscog
> and trunk, so copy this method into FT2Plugin.
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

>  
> I think using
> ^self
> cCode: 'BYTES_PER_WORD'
> inSmalltalk: [self subclassResponsibility "InterpreterSimulator"]
>
> instead of
>
>
> ^BytesPerWord
>
> is a mistake.

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

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

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

>
> On 6 September 2011 07:18, David T. Lewis <[hidden email]> 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?

> On Tue, Sep 06, 2011 at 11:00:07AM +0300, Igor Stasenko wrote:
> >
> > 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.

>
> On Tue, Sep 06, 2011 at 07:13:12AM -0400, David T. Lewis wrote:
>> On Tue, Sep 06, 2011 at 11:00:07AM +0300, Igor Stasenko wrote:
>> >
>> > 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.
>
> I did a before and after comparison of generated code on oscog, and
> verified that the patch produces no change to generated code for the
> VM except for the now correct translation of 'self bytesPerWord' in
> the FreetypePlugin.
>
> I committed the VMMaker patch as VMMaker-oscog-dtl.124 and reverted
> the added #bytesPerWord from FreetypePlugin in Freetype-Plugin-dtl.63.
>
> If you update to the latest FreetypePlugin, and merge the changes from
> VMMaker-oscog-dtl.124, we should now have a FreetypePlugin that compiles
> correctly with both trunk and oscog VMMaker.
>
> I think this will also make it possible to merge the oscog branch
> of OSProcessPlugin. I'll take a look at this weekend when I get some
> free time.
>
> Dave
>
>