[self-interest] Re: Squeak and Self (was: more syntax madness and Ultimardrev)

[Stefan Matthias Aust]

Jecel Assumpcao Jr wrote:

>>[different classes of map objects?]
>Actually, one of the first words in a map is the C++ VTable - its
>runtime type (class)!

I see! Pretty obvious actually. Probably that "i didn't see the forest
because of all that trees" problem.

>Squeak was OO the last time I checked ;-) but if you mean that you
>want to use their Smalltalk to C translator, then you are right.

It was?  Amaising :-)  

But you guessed right, I was referring to the translator.  The alternative
would be of course to extend the translator to support methods using vtable
lookup.  The week definitely needs more weekends.


>Good point. You can define an empty method, but then it is only a normal
>object and not a method. Blocks look like methods, but they have a lot

No :-) An empty method isn't a method as a method is a method if and only
if it has code.  But it's pretty clear want you meant.

>> Hm, "super::someMessage" could mean an undirected resend while
>> "sma::someMessage" would resend someMessage to sma. "::" would become a new
>> operator and it's the responsibility of the parser, to distinguish keywords
>> from "::", which just needs a lookup buffer of 2.
>
>Why can't the lexer handle this?

You're right. It's of course the scanner (lexer), not the parser. My fault.

>I would recompile old Squeak code to Self bytecodes. The Jitter
>translator would generate the same threaded code as before, if all
>went well. Here is the plan I came up with:
>
>>1) subclass ObjectMemory and patch it so it deals with
>>   Self style object and headers

We'd need slot objects, slot array objects and byte array object - which
are all already supported by Squeak. The only difference is the map
reference instead of the class reference.  However, I'm no expect for the
ObjectMemory class and I've only a vague idea how the whole ObjectMemory
works.

>>2) copy Compiler and patch it so it will parse Squeak
>>   sources into Self objects and bytecodes (this
>>   involves throwing out a lot of stuff, but see step 4)

What kind of stuff?  Typically, a Smalltalk VM needs to support the
following kinds of instructions:

SMALLTALK              SELF

push self              SELF
push slot #            SELF SEND i_<slotname>
push temp #            SELF SEND t_<tempname>
push literal #         LITERAL #

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.

store slot #           SELF SEND i_<slotname>:
store temp #           SELF SEND t_<tempname>:

Store doesn't pop the stack. Two other instructions, dup and pop are
typically used to optimize cascading and multiple assignments. There's no
direct way to express this using the SELF bytecodes, however that's no
problem as the stack will be always cleaned up when the method execution
has been completed.

send msg, argnum       [SELF] SEND msg (sends to self must be treaten special)
supersend msg, argnum  SUPER SEND msg

SELF probably determines the number of arguments from the selector which
isn't problematic as this happens only at (byte code) compile time.

RETURN STACKTOP        --- (No need to translate this, as this is the
     default action after the method execution has been completed.)

BLOCKRETURN STACKTOP   NON-LOCAL-RETURN

The following instructions aren't needed by SELF because it doesn't inline
common control flow instructions like #ifTrue: or #whileTrue:.  It might be
a good idea however, to extend the original SELF instruction set to support
similar instructions if the instructions aren't compiled and optimized but
just interpreted.  As the SELF instruction bears no parameter, there's room
for 31 other parameterless instructions.

BRANCH TO address
BRANCH IF STACKTOP IS FALSE TO address

PRIMITIVE number

I think, with one exception, byte codes can be translated very easily.  The
exception are cascades, which need to be compiled a bit differently.
Before code generation, we perform the following translation:

rcv m1; m2; ... mN  -->  
([:value | value m1. value m2 ... value mN] value: (rcv))

Alternatively, we can add DUP and POP instructions to the SELF instruction
set.

Either I oversaw something obvious or there're no big problems in
generating SELF instructions instead of Smalltalk instructions, assuming
we've the same class hierarchy intrastructure.

>>5) translate (4) to C and compile it. We now would have
>>   a Squeak that looks and works exactly like the original,
>>   but is very different inside.

Sounds too simple to be true :-)

>You can tell when this was from the reference to Squeak 1.31. The
>need to copy the whole Jitter hierarchy to change it was particularly
>bothersome, in my opinion. I don't normally miss multiple inheritance,
>but this was a case when I did.

:-)  Time to refactorize the whole interpreter/dynamicInterpreter stuff.

>But it would be great if someone were to create a Self/Squeak like
>I described above.

Indeed.


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