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.
The generated interp.h in cog vms includes following:
#define SQ_VI_BYTES_PER_WORD 4
but not BYES_PER_WORD
On 1 September 2011 15:25, Igor Stasenko siguctua@gmail.com wrote:
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.
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'
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
but BytesPerWorld is the same (it generates a macro). Why is so different to BYTES_PER_WORD?
Esteban
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 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
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.
Dave
On 6 September 2011 07:18, David T. Lewis lewis@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?
Dave
On Tue, Sep 06, 2011 at 11:00:07AM +0300, Igor Stasenko wrote:
On 6 September 2011 07:18, David T. Lewis lewis@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
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
On 7 September 2011 14:04, David T. Lewis lewis@mail.msen.com wrote:
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
Thanks, Dave. My main concern about this to not add to much mess on top of what we already have (define stuff at right place and just once). Because i seen that Esteban modified config to explicitly add -DBYTES_PER_WORD=4 , which of course smells :)
So, now we can solve this in right way :)
vm-dev@lists.squeakfoundation.org
-
David T. Lewis -
Esteban Lorenzano -
Igor Stasenko