[self-interest] Re: bytecode formats (was: Squeak and Self)

Stefan Matthias Aust sma at kiel.netsurf.de
Thu Jan 14 21:26:40 UTC 1999

>I wouldn't add the "i_" and "t_" prefixes, though. If you define a
>temporary variable with the same name as an instance variable in
>a method, you have no way to access the instance variable at all.
>Which Self does automatically.

Wait.  I'm comparing byte codes, disregarding any additonal constraints of
the Smalltalk language.  As instance variables and temporary variables are
typically references by indices, you _can_ distinuish them, even if they'd
have the same name.  You're however right that this distinction isn't
really needed.  You have however to distinguish the slot accessor methods
needed for SELF from normal methods.

>> Shared variables are acccessed using variable binding objects to which
>> #value and #value: are sent. I think, typical instruction sets have special
>> instructions here, but this is only an optimization.  The same is true for
>> "push constant" type instructions.
>No need for this - shared variables (pool dictionaries, global
>variables and so on) can be handled by making the class objects
>have parent slots pointing to simple objects with the right slot
>names. Then SELF SEND <global variable name> will do the trick.

Good point. Of course you're right. However, has this way really an
advantage over the "classical" Smalltalk way?  Actually, doesn't I have to
support the old way to support all kinds of meta class manipulation stuff
that people probably expect to work.

Let's say we implement "Smalltalk" as an unique object which has a named
slot for every global in the Smalltalk world.  The typical idiom "Smalltalk
at: aSymbol" must be supported.  The SELF Smalltalk object isn't
SystemDictionary so it must emulate that at: method, probably using some
(probably available) mirror primitives to access a slot by name.

BTW, I recently read that SELF handles Symbols (unique strings) inside the
VM. A Smalltalk VM does this typically in Smalltalk.  Would this be a problem?

>I think Mario's Smalltalk simply ignores cascades. They can emulated
>easily enough with hidden temporary variables:

As you might have seen, I suggested nearly the same transformation :-)

>No - this will give you the wrong results. You want this for messages
>to self in Smalltalk instead:

You're right.  But this makes the byte code transformation even simpler.

>About the control flow bytecodes, I was counting on removing this
>from the parser (Smalltalk compiler) and having Jitter put them
>back in. The total complexity would be roughly the same, though
>performancewise it is not interesting to move complexity to runtime
>like this.

I think, when we start to discuss variants of the instruction set and its
encoding, we first need to decide whether this set shall be optimized for
interpretation or compilation.  Squeak's Jitter can probably perform simply
macro expansions, but I don't know whether it can perform more complex
inlining and unrolling operations which would be probably needed to reach
an acceptable execution speed.

Therefore, it might be worth considering an instruction set tailored for
interpretation together with a parser/codegenerator which would even
flatten if, while and for statements.

You proposed a clever and compact encoding. But it's tailored towards
compiling. An interpreter would have to decode the instruction bit instead
of using a simple jump table.  You need to maintain a current literal
pointer. You need to extract the argument count from message arguments
(probably not that difficult. If the first character is a letter, just
count the ":". Otherwise the argument count is 1). And your parser needs to
macro-expand delegation into primitives. Finally, your interpreter must
interpret a non-local-return as the end of execution even for methods
because otherwise you cannot deal with instruction streams with sizes other
than n*16.

Stefan Matthias Aust  //  Are you ready to discover the twilight zone?

eGroup home: http://www.eGroups.com/list/self-interest
Free Web-based e-mail groups by eGroups.com

More information about the Self-interest mailing list