problem in porting from smalltalk

nicolas cellier ncellier at ifrance.com
Thu Feb 23 18:36:41 UTC 2006


Le Mercredi 22 Février 2006 23:36, Bryce Kampjes a écrit :
> nelson - writes:
>  > Dear Peter,
>  >    the problem is that i HAVE to impelement and: .... I have a fuzzyAnd:
>  > method, but i want to be able to mix crisp and fuzzy value, so
>  > redefining and: definition would be the best choice... can I disable
>  > this code inlining?
>
> You should definately be able to disable the and: inlining. I doubt
> that everyone would be happy with such a change in the mainstream
> image but it's definately reasonable for your personal images or for a
> project that needs and: to behave like a proper method.
>
> Poke around in the Compiler class, and save your image frequently.
> Try exploring how the "special" instance variable on MessageNode is
> used.
>
> Hmm, yet another argument for full message inlining. But for now,
> you'll loose performance, however the loss may not be noticable.
>
> Bryce

What about a little change in the #and: form ?

using blocks both sides of the #and: message would enable the compiler to 
choose its way of generating bytecodes:

When both receiver and argument are blocks, use bytecode optimization.
 [a < 0] and: [b > a]
When one of the two isn't a block, then use regular message send.
 a and: b

This is in the spirit of whileTrue: optimization in VW.
Of course, most senders of #and: would have to be rewritten with block 
receiver to profit by compiler optimization.

What do you think of this proposition ?

Another more radical solution is a kind of <pragma: #dontOptimizedCode>,
or maybe more selective <dontOptimize: #and:>...

Nicolas




More information about the Squeak-dev mailing list