[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
|