[self-interest] arg count (was: Self bytecodes)

Jecel Assumpcao Jr jecel at lsi.usp.br
Wed Jun 2 21:14:47 UTC 1999


Douglas Atique wrote:
> There is something I don't understand. Why does the interpreter look at the Self
> text and counts colons, when it can get as input a slotsOop's map, then from it a
> byteVectorOop with all the codes already built and an objVectorOop with the
> literals. I have been looking at the NIC code and it doesn't count colons when
> generating a send. It only gets the argument count for the send from somewhere. The
> parser might already have counted the arguments.

See FSelfScope::genSend in fast_compiler/fscope.c  which calls
    stringOopClass::arg_count in memory/stringOop.h  which calls
    str_arg_count in parser/stringUtil.c  which does indeed count the
colons.

Kids: don't try this at home unless you have adult supervision and
find/xargs/grep :-)

I didn't get the relation between giving the interpreter a bytecode
vector and a
literal vector to digest and the part about counting colons.

> It is like a surgery, we must find all the places in the VM code where any
> compilation takes place and introduce at that point an
> # ifdef PORTABLE
> // create interpreter instance, passing as argument the slotsOop that contains the
> bytecodes
> # else
> // original code goes here
> # endif

My initial thought was that this wouldn't work, as the interpreter might
need to be
called more often than the compiler is. But if you make the code cache
always miss and
there is no inlining, then I am probably wrong.

David Ungar wrote:
> [constant slots with arg count for cannonical strings]
> Also an good idea! (forgive, me I am reading mail backwards today)
> It does have the slight drawback that the count is a memory-reference away
> instead of being in the interpreter's I-stream.

Right. In tinySelf 1 the sending of a message and the receiving of the
same message
are decoupled - the message may wait for a long time in a queue. But in
a simple
sequential interpreter you always follow a message send by a lookup,
which results
in a method object being found. So another idea would be to store the
argument count
in the method's map (each method has a diffent map anyway, so this
wouldn't be a big
deal). This is also no in the I-stream, but it is an object into which
you would have
to look anyway after the lookup.

-- Jecel


------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/self-interest
http://www.egroups.com - Simplifying group communications






More information about the Self-interest mailing list