[squeak-dev] Re: Compiling with macro inliner switch [was: Boolean over-optimization #ifTrue:/#ifFalse:]

Klaus D. Witzel klaus.witzel at cobss.com
Wed Mar 5 09:44:26 UTC 2008


On Wed, 05 Mar 2008 10:09:53 +0100, Igor Stasenko wrote:

> On 05/03/2008, Klaus D. Witzel wrote:
>> On Wed, 05 Mar 2008 07:39:33 +0100, Igor Stasenko wrote:
>>  > On 05/03/2008, Paolo Bonzini wrote:
>>  >> Igor Stasenko wrote:
>>  >>  > Hello,
>>  >>  >
>>  >>  > i currently tried to implement a proxy (subclass of ProtoObject)  
>>  >>  > with own IfTrue:/ifFalse: methods.
>>  >>  > What i can't understand, is why VM throws me with #mustBeBoolean
>>  >>  > message instead of doing real send if optimized pattern fails  
>>  >>  > (when receiver of #IfTrue: is a non-boolean)?
>>  >>
>>  >> Because you cannot distinguish #ifTrue:#ifFalse: sends from  
>> #whileTrue:
>>  >>  for example, and because there are no BlockC{ontext,losure}  
>> objects for
>>  >>  the argument blocks.
>>  >
>>  > So, the only way is to compile method without optimization of #ifTrue
>>  > #ifFalse:, to make sure they do real sends?
>>  >
>>  > If yes, i'd like to see optimizations optional,
>>
>>  For Rob Wither's project I've made a small patch
>>  NoMacroCompiler-kwl.1dot5.cs which allows to specify per method (in a
>>  pragma) or system-wide that macros are inlined or result in a full  
>> send.
>>  Could be adapted to select what kind of macro not/to optimize. I've  
>> also
>>  identified which Squeak .image methods *must* be compiled *with* macro
>>  inlineing so that the .image does not crash/get stuck. And out of
>>  meta-programming/memory reasons, the implementation of #whileTrue*,
>>  #whileFalse* must be compiled *with* inlineing ;-)
>>
>
> The only place, where whileTrue:/whileFalse: should be _always_
> compiled optimized its in
> BlockContext/BlockClosure whileTrue:/whileFalse: methods.
> In rest of the code there is nothing bad in using real sends.

Yes. And that's magically recognized by the attached.

>
>>  Let me know if that's interesting to you.
>
> Yes, let me take a look at it.

Attached. Beware of

CommandHistory class forgetAllGrabCommandsFrom:
ContextPart handleSignal:
ContextPart restart
ContextPart resume:
Exception outer
ImageSegment allObjectsDo:
ImageSegment comeFullyUpOnReload:
ImageSegment rehashSets
ImageSegment restoreEndianness
ImageSegment copyFromRoots:sizeHint:areUnique:
ImageSegment install
ImageSegment readFromFile
PointerFinder class pointersTo:except:
Process debug:title:full:
Process debugWithTitle:
Process terminate
ProjectLoading class openName:stream:fromDirectory:withProjectView:
SystemNavigation allObjectsDo:
SystemProgressMorph nextSlotFor:
Utilities class pointersTo:except:

you *have* been warned. Besides that list, I found that the Squeak .image  
can be run at the full message send level.

> i'm already using pragma <metacode> to switch between different
> simulation modes (but it's in my own domain, not related to optimized
> booleans).
>
> I'm currently doing some research, by implementing own object memory
> with a small set of classes. To make things done fast, i decided to
> not create parsers/bytecode interpreter, but instead, use squeak as
> backend for evaluating a code using proxies.

So I don't have to develop that? Great, send me a copy please.

/Klaus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: NoMacroCompiler-kwl.1dot5dot1.cs
Type: application/octet-stream
Size: 5144 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080305/2d3a5978/NoMacroCompiler-kwl.1dot5dot1.obj


More information about the Squeak-dev mailing list