At 05:41 PM 2/6/2001 -0200, Branden wrote:
>Sorry, I promess it's the last reply for today! Please don't rant on me!
I have not yet begun to rant. :) And I won't start, either. (And you
certainly don't have to stop arguing your point. I don't claim to hold some
sort of divine inspiration on interpreter or vtable design. And I can be
rather dense sometimes...)
>Dan Sugalski wrote:
> > At 04:23 PM 2/6/2001 -0200, Branden wrote:
> > >Dan Sugalski wrote:
> > > > Don't forget we have an opcode machine here--we are *not* emitting C
>code
> > > > to be compiled. That means we're going to be storing temps in a
>register
> > > > file of some sort. (Or pushing them on a stack, or whatever) That
>means
> > > > that if we generate intermediaries that aren't PMCs then we need extra
> > >temp
> > > > space for them. Your way will mean an int, num, and string stack (or
> > > > register file, or whatever) in addition to a PMC stack/register
> > > > file/whatever. That's more stuff to track. (Which isn't to say we
>won't,
> > > > mind. We will if we have to)
> > > >
> > >
> > >I know that (althought I don't have the exact definition of opcode yet).
>I
> > >wrote C code only to illustrate my point.
> > >
> > >If a opcode is what I'm thinking, in the fact that the interpreter
>executes
> > >a opcode kind of atomically, like a machine instruction in assembly, then
>I
> > >would like to say that the entries you are proposing to the vtables are
> > >probably much better as opcodes than mine. But I'm actually not saying
>that
> > >one vtable function call should be a opcode. I mean, an `add' instruction
> > >could be built above that that would do all that at once, and that could
>be
> > >the opcode...
> >
> > If I was feeling crankier, I'd rant here for a moment. I'm not, though, so
> > I won't. (And please, everyone, lets also be a touch restrained)
> >
> > Perl is an interpreter, one that executes a stream of opcodes. That fact
> > *must* be kept in mind, as it places constraints that must be heeded for
> > speed. Your scheme may be a bit faster (certainly conceptually simpler)
> > than the one I'm proposing for a direct-to-C translator, but we're not
> > writing that--we're writing an interpreter. Different beasts.
> >
> > Think of the perl interpreter as a big CPU, with none of the neato-keen
> > tricks available to it that modern designers have. You'll find that the
> > design will tend towards a more CISC-like architecture than a RISC-like
>one.
> >
> > >I actually don't see a reason why the vtable entries should be the
>opcodes.
> > >Is there?
> >
> > Speed.
> >
>
>
>Actually, I don't see the problem of defining a C function that would do:
>
> void add(SVAR *result, SVAR *lop, SVAR *rop, SVAL *tmp1, SVAL *tmp2) {
> /* tmp comes from the temporary file */
> lop->vtable->FETCH(tmp1, lop);
> rop->vtable->FETCH(tmp2, rop);
> lop->vtable->ADD(tmp1, tmp1, tmp2);
> result->vtable->STORE(result, tmp1, tmp2);
> }
>
>And have it be my opcode. Passing the indexes wouldn't be a problem either.
>Is there any problem here?
Well, no, but what's the point? If you're calling lop's ADD vtable entry,
why not have that entry deal with the rest of it, rather than stick things
into, and later remove them, from temp slots?
>(Calm down, I'll also stop with the UNIX thing...)
That one's up to you. Doesn't bother me (despite my rep as "that damn VMS
guy"... :) but the point I was (probably badly) making was important. There
are a number of ways to do things, and the way that X does it (where X
could be Unix, or VMS, or Windows, or even X) isn't necessarily the best
way overall. It's usually a good way given other design constraints (well,
except perhaps for signals, but we won't go there), but good is always
relative to other things. In all engineering efforts there are tradeoffs,
and things that seem really good taken alone end up being less good than
other alternatives given the design choices already made.
Of course, I could be wrong here. Wouldn't be the first time, and not the
last I'm sure.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
