Dave Lewis uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker-dtl.194.mcz ==================== Summary ==================== Name: VMMaker-dtl.194 Author: dtl Time: 19 October 2010, 11:52:12 am UUID: 9dd94fba-0da6-49f7-820c-9af777558bb7 Ancestors: VMMaker-dtl.193 VMMaker 4.3.8 Adopt CCodeGenerator improvements from oscog, notably including proper C code generation for ifTrue:ifFalse: constructs as expressions, as well as methods used in Cog code generation. Produces equivalent C code for the traditional interpreter, modulo some cosmetic differences in the output (line breaks, spaces, etc). Notes: Added #asExpression to TSendNode>>emitCCodeAsArgumentOn:level:generator: needed for cpp code generation for expressions. Methods #generateInlineCPreprocessorDirective:on:indent: and #generateCppDirective:on:indent: are redundant, get rid of one (or both) of them. Consider using #isDefined:inSmalltalk:comment:ifTrue:ifFalse: instead in Cog. |
On Tue, Oct 19, 2010 at 10:55 PM, <[hidden email]> wrote:
Ooh! I like it. Why didn't I think of this? Make it so. The cPreprocessorDirective: was my most egregious hack. But I would just use #ifDefined: aPreprocessorMacroName ifTrue: [] ifFalse: []
and then use cCode:inSmalltalk: within each arm as appropriate rather than conflating the two. best Eliot |
On Wed, Oct 20, 2010 at 10:02:31AM -0700, Eliot Miranda wrote: > On Tue, Oct 19, 2010 at 10:55 PM, < > [hidden email]> wrote: > > > > Added #asExpression to TSendNode>>emitCCodeAsArgumentOn:level:generator: > > needed for cpp code generation for expressions. > > > > Methods #generateInlineCPreprocessorDirective:on:indent: and > > #generateCppDirective:on:indent: are redundant, get rid of one (or both) of > > them. Consider using #isDefined:inSmalltalk:comment:ifTrue:ifFalse: instead > > in Cog. > > > > Ooh! I like it. Why didn't I think of this? Make it so. The > cPreprocessorDirective: was my most egregious hack. But I would just use > #ifDefined: aPreprocessorMacroName ifTrue: [] ifFalse: [] > and then use cCode:inSmalltalk: within each arm as appropriate rather than > conflating the two. Hi Eliot, The cCode:inSmalltalk: part actually works pretty well and translates nicely to C, see #isIntegerObject: for the most important example. The following are already implemented in VMMaker "trunk". The first two are important, the third is unreferenced, and the fourth is both unreferenced and redundant with the oscog implementation. #isDefinedTrueExpression:inSmalltalk:comment:ifTrue:ifFalse: #isDefined:inSmalltalk:comment:ifTrue:ifFalse: #isDefined:inSmalltalk:comment:ifTrue: #preprocessorExpression: The #cPreprocessorDirective: implementation is important for Cog, and is now implemented in both VMMaker branches (but could be replaced as noted above). So my suggestion would be to add these into oscog: #isDefinedTrueExpression:inSmalltalk:comment:ifTrue:ifFalse: #isDefined:inSmalltalk:comment:ifTrue:ifFalse: #isDefined:inSmalltalk:comment:ifTrue: And then get rid of #preprocessorExpression: in favor of your #cPreprocessorDirective: As a practical matter, I'm not sure the best way to include this in the oscog branch. I can send a change set if that is helpful, or you can pick updates from Montecello. Unless you advise otherwise, I don't think that I should make any commits to the oscog branch, as that is likely to lead to confusion. Dave |
---------- Forwarded message ---------- From: Eliot Miranda <[hidden email]> Date: Wed, Oct 20, 2010 at 5:01 PM Subject: Re: [Vm-dev] VM Maker: VMMaker-dtl.194.mcz To: "David T. Lewis" <[hidden email]> On Wed, Oct 20, 2010 at 4:43 PM, David T. Lewis <[hidden email]> wrote:
A change set ifs fine. But I still don't quite understand why you need the inSmalltalk: argument. I'm assuming self ifDefined: aConstantName
inSmalltalk: [smalltalk statements] comment: aComment ifTrue: [true statements] ifFalse: [false statements] then surely that's equivalent to
self ifDefined: aConstantName comment: aComment ifTrue: [self cCode: [true statements] inSmalltalk: [smalltalk statements]] ifFalse: [self cCode: [false statements] inSmalltalk: [smalltalk statements]]
which is much nicer IMO because it is orthogonal. But am I not understanding and instead the argument to inSmalltalk: is deciding whether isDefined: is true at execution time? If so, I get it, it makes sense, but I find the reuse of inSmalltalk: confusing (doh!).
best Eliot
|
On 10/20/2010 5:01 PM, Eliot Miranda wrote: > A change set ifs fine. But I still don't quite understand why you need > the inSmalltalk: argument. I'm assuming > > self ifDefined: aConstantName > inSmalltalk: [smalltalk statements] > comment: aComment > ifTrue: [true statements] > ifFalse: [false statements] > > then surely that's equivalent to > > self ifDefined: aConstantName > comment: aComment > ifTrue: [self cCode: [true statements] inSmalltalk: [smalltalk > statements]] > ifFalse: [self cCode: [false statements] inSmalltalk: [smalltalk > statements]] > > which is much nicer IMO because it is orthogonal. My understanding is that the 'inSmalltalk' is the block producing the value of the ifdef, e.g., self isDefined: 'WIN32' inSmalltalk:[Smalltalk platformName = 'Win32'] ... Thus it would not be equivalent at all. Cheers, - Andreas |
On Wed, Oct 20, 2010 at 05:06:49PM -0700, Andreas Raab wrote: > > On 10/20/2010 5:01 PM, Eliot Miranda wrote: > >A change set ifs fine. But I still don't quite understand why you need > >the inSmalltalk: argument. I'm assuming > > > >self ifDefined: aConstantName > > inSmalltalk: [smalltalk statements] > > comment: aComment > > ifTrue: [true statements] > > ifFalse: [false statements] > > > >then surely that's equivalent to > > > >self ifDefined: aConstantName > > comment: aComment > > ifTrue: [self cCode: [true statements] inSmalltalk: [smalltalk > >statements]] > > ifFalse: [self cCode: [false statements] inSmalltalk: [smalltalk > >statements]] > > > >which is much nicer IMO because it is orthogonal. > > My understanding is that the 'inSmalltalk' is the block producing the > value of the ifdef, e.g., > > self isDefined: 'WIN32' inSmalltalk:[Smalltalk platformName = > 'Win32'] > ... > > Thus it would not be equivalent at all. > > Cheers, > - Andreas It's patterned after the #cCode:inSmalltalk: idiom. If you write this: ObjectMemory>>isIntegerValue: intValue ^ self isDefined: 'SQ_HOST32' inSmalltalk: [true] comment: 'cast to int for 64 bit image on 32 bit host' ifTrue: ((self cCoerce: intValue to: 'int') bitXor: ((self cCoerce: intValue to: 'int') << 1)) >= 0 ifFalse: (intValue >= 16r-40000000 and: [intValue <= 16r3FFFFFFF]) It will evaluate in Smalltalk to true, and is translated to C as follows: sqInt isIntegerValue(sqInt intValue) { return # ifdef SQ_HOST32 // cast to int for 64 bit image on 32 bit host (((((int) intValue)) ^ ((((int) intValue)) << 1)) >= 0) # else ((intValue >= -1073741824) && (intValue <= 1073741823)) # endif // SQ_HOST32 ; } The inSmalltalk: block is evaluated when running in the simulator, and the comment: adds a comment to the generated C source. Not perfect but it gets the job done. Dave |
Free forum by Nabble | Edit this page |