[self-interest] bytecodes

[Marko Mikulicic]

Jecel Assumpcao Jr wrote:

> Marko Mikulicic wrote:
> > Jecel Assumpcao Jr wrote:
> > > where lexical level 0, slot 1 is 'z', level 1 slot 0 is 'a' and level 2
> > > slot 2 is 'tmp'.
> >
> > ah. I understand. This is only to allow fast indexing through local slots, without
> > literals.
>
> Exactly. Urs did several comparisons between ParcPlace Smalltalk and
> the Self NIC (the Non Inlining Compiler, and also speculated on a Self
> interpreter) in his thesis. He saw that the main performance difference
> between the NIC and an interpreter is the use of message sends for
> local slot access (page 31). These new bytecodes fix this.

And the PICS ? Can they be implemented with the new bytecode ?
What is the impact of PICS then ?

>
>
> He also found out that the NIC would be 2.5 times faster if it inlined
> the "if" and "while" messages and blocks like Smalltalk does. The
> branch bytecodes would fix this (if they were used).

but the inlining compiler does that job good, right ?
Branch bytecodes are IMHO bad, because the parser statycally gives meaning to a message
(ifTrue:...)

Perhaps hinting the compiler with such bytecodes could help. The compiler generates
code
for two versions of the expression: one inlined for true/false objects, and one that
uses
normal send. This analysis could be done by the compiler but for an interpreter it
could be a gain
without paying a big price for flexibility.

>
>
> > I think that maybe for the interpreter there could be two levels of bytecode, one
> > created by the parser (the standard set) and
> > one deeper, closer to the interpreter (just in time interpreting). Of course there
> > is a waste of space (like for machine code) but at least
> > I don't break compatibility with older snapshots or Self programs wich accessed
> > bytecodes (emulators,...) only because I want to make my VM
> > portable.
> >  What do you think ?
>
> Urs suggested something like this. You could include PICs and other
> complications in this second set of bytecodes. The advantage of such a
> solution over the current NIC is that it could easily be ported to any
> machine with a C++ compiler.
>
> It would be great if someone were to do this.
>

I will try it in openself. The framework is similar to that for machine code. I'll have
to
plug-in an interpreter.

>
>
> Bytecode 2 should be a "send", not a "push". And I counted 4 bytecodes
> above instead of 3.

Sorry.

>
>
> > 1: 'z'
> > 2: 'a'
> > 3: '+'
> > 4: 'tmp:'
> > ------
> > 4*4 = 16 bytes
> >
> > total: 19 bytes    versus yours 5*4 = 20 bytes   => you loose 1 byte :-)
>
> Don't forget to add 4 more words for the bytevector (header word, map
> pointer, size, bytes pointer). I came out 16 bytes ahead!

You can encode bytecodes and literals in one vector (using an additional word for bcode
size,
and the padding max. 3 bytes) so you come out with 4+(0..3) bytes :-)
For methods with repetitive literals (many "ifTrue:"..., matematical operations, ....)
the old format is better, but I agree that for the general case your encoding can be
better.
I think only the real statistical data can judge.

>
>
> > I imagine that for a bit longer methods there is a gain of 1 byte (at least for 16
> > codes).
> > But every duplicate eats 4 bytes!
>
> See the details in my 28 Aug 1999 message to this list:
>
>     http://www.egroups.com/message/self-interest/299
>
> I saved 400KB.
>

Nice

>
>
>
> > I thought to stay more or less compatible but I think I won't follow that.
> > Maybe it won't be bad if we could share the images between OpenSelf and Self/R.
>
> That would be great, but as long as we can read in each other's textual
> Self source it would be a good start too.

Sure, it's good. My parser is really bad :-)
Maybe a parser written in Self would be good. Bootstrapped using a bad parser is
possible.
We would have then the same parser and 100% source compatibility,
every effort would be shared and it would a good example of Self's flexibility.
Can Mango do the job ?

_____
Marko