[self-interest] Blocks: Summary
Jecel Assumpcao Jr
jecel at merlintec.com
Mon Jun 5 19:38:27 UTC 2000
I'll take a look in a week or two into the UI differences between 4.0
and 4.1.2 and will send you any bug fixes that I come up with. The
hardest part will probably be telling the difference between bugs and
I am sure most people subscribed to this list will be interested in
hearing about Self-like languages too. I don't know of any better place
to discuss them. Besides, it is hard to tell when things like
Ultimardrev and JSelf cease to be Self and become Self-like.
One thing you should keep in mind when studying Self 4's implementation
is that there is no interpreter - the bytecodes were designed
specifically as the input to a compiler. Note how there is no "pop"
bytecode, for example. This means that every result that isn't used
(every time you have a "." separating expressions in the code) it just
sits on the stack taking up space until the method finally returns. Or
it would do that in an interpreter (like tinySelf 1), but the compiler
must do data flow analysis in any case and it will generate optimized
Sparc (or PPC) code that doesn't uselessly store unused results.
Smalltalks normally have interpreters and so does implement "pop".
Same thing with blocks. Smalltalk uses a very different bytecode to
push a block on the stack from the one that pushes literals (actually,
blocks don't exist as objects in Smalltalk so the must be created by
this bytecode instead of simply cloned - this saves some memory but is
very ugly). A Self interpreter would suffer from a performance loss
testing each literal to see if it is a block or not, but in Self 4 this
test is done only when compiling the code to native machine language
and in this case the overhead is essentially zero.
More information about the Self-interest