[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