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

[Douglas Atique]

jecel at lsi.usp.br wrote:

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

OK, so it count the colons. All right, but if it already does that, we don't need to do
anything else, just call stringOopClass::arg_count(). I didn't notice this because I was
looking at the codes byteVector as a byteVectorOop, but the NIC looks at it as a
stringOop. I'll think about this. Thanks, Jecel.

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

This is just to know where we have to write new code and where we can call existing
methods (like arg_count()).

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

What if we simply turn off this cache (I am talking about turning off everything that is
SPARC-dependent)? I was implicitly thinking about always performing a lookup. Sorry not
to have said it.
I told you it was going to be a slow but portable approach...
In fact, I was thinking about (but I am not certain yet) instantiating a new interpreter
instance for each send. So, we have an interpreter chewing bytecodes from a slotsOop, it
finds a send, performs a lookup and the lookup returns it another oop that is the
receiver and another slotsOop that is the object referred to by the matching slot in the
receiver. Then it simply instantiates a new interpreter and gives the receiver and
matching slot's object for it to execute bytecodes. So it goes, it is kind of a stack of
interpreters, ain't it? This might look cumbersome but the intention is to get simple.
Remember it can later be changed.
Regards,
Douglas

>
>
> 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 Spotlight:
> "Latino Veterans of America" - Latino/Latina American veteran discussion,
> news, events, people, places, history and information exchange.
> http://clickhere.egroups.com/click/126
>
> eGroups.com home: http://www.egroups.com/group/self-interest
> http://www.egroups.com - Simplifying group communications


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

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