Simon --
> Gregor's just committed a load of interesting stuff, and I have no
> idea what it is. Hey, Gregor, what's going on?
I'm working on some cleanup to the various scriptage related to op
processing. I still have some things in mind, but (IMO) its looking
better.
I'm going to post a message soon with the commit log message details
for interested parties.
I have a few goals I'm working toward:
* Reduce the amount of repetetive stuff in core.ops. For example,
I replaced a bunch of logic in the dest-less branch ops with
calls to a new stack function pop_dest().
* Make a distinction between the "simple" ops and the "complex"
ops. Simple are marked "inline". The idea is that simple ops
can probably be implemented JITly, but complex ops probably
still need to be function calls in the JIT stream.
Daniel and I have been discussing the question: "calls to *what*
function?". I'm thinking the prederef stuff or something like it
might come in handy here. Calling the main opfunc for the op
could work, but would feel a little silly (since we pass in a
pointer to the byte code -- feels like JIT shouldn't have to
point back at its "source" code)
We might even be able to autogenerate Parrot_*_BODY() funcs
that are JIT-compatible (whatever that ends up meaning) for the
bodies of non-inline ops.
BTW, you can usually tell an opfunc isn't "simple" (and therefore
shouldn't be marked "inline") if it has local variables. There
are other criteria, sure. But I'm thinking that the bodies of
inline ops could be laid end-to-end without trouble (after some
munging of non-default control flow stuff) much like pbc2c.pl
does.
* Eventually getting rid of (all?) references to the implicit args
of opfuncs (interpreter and cur_opcode). If they are implicit,
let them stay hidden. Dan is thinking this may become easier
when/if we can store interpreter as TLS or something.
Today the main use of interpreter is for passing to string funcs.
Its also used for some stack ops and flag bit twiddling.
* Getting rid of copy-paste-edit code reuse, since that's Bad (TM).
(I get to say this because *I'm* the one who did it originally :)
Merry Christmas!
Regards,
-- Gregor
____________________________________________________________________
/ Inspiration >> Innovation >> Excellence (TM) \
Gregor N. Purdy [EMAIL PROTECTED]
Focus Research, Inc. http://www.focusresearch.com/
8080 Beckett Center Drive #203 513-860-3570 vox
West Chester, OH 45069 513-860-3579 fax
\____________________________________________________________________/
[[EMAIL PROTECTED]]$ ping osama.taliban.af
PING osama.taliban.af (68.69.65.68) from 20.1.9.11 : 56 bytes of data.
>From 85.83.77.67: Time to live exceeded
