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

Igor Stasenko siguctua at gmail.com
Wed Mar 5 10:19:58 UTC 2008


On 05/03/2008, Klaus D. Witzel <klaus.witzel at cobss.com> wrote:
> 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 never planned to use this outside the scope of my own
classes/methods, where i exactly know what should happen. So there is
no risk at all :)

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

>
>  /Klaus
>

-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list