[squeak-dev] Compiling with macro inliner switch [was: Boolean
over-optimization #ifTrue:/#ifFalse:]
Igor Stasenko
siguctua at gmail.com
Wed Mar 5 09:09:53 UTC 2008
On 05/03/2008, Klaus D. Witzel <klaus.witzel at cobss.com> 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.
> Let me know if that's interesting to you.
>
Yes, let me take a look at it.
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.
My intent is to create a kind of self-hosted VM, which after some
bootstrap can start working without the need of implementing things
externally, like primitives/bytecode interpreter.
A 'primitives' in this system will be replaced by a special methods,
marked with <metacode> pragma, which should follow special rules and
handled differently by compiler.
But what is good, that these methods are 'live' - you can change their
implementation at any time, in same way as any other method in
smalltalk.
As a first 'showcase' i like to make complete implementation of
classes which can create objects and do smallint math without the need
of primitives (means, all behavior implementation resides in object
memory).
To complete a full circle, the VM should be capable to compile methods
to bare metal (CPU instructions) and can execute them without any
external help.
> /Klaus
--
Best regards,
Igor Stasenko AKA sig.
More information about the Squeak-dev
mailing list
|