Sorry, I promess it's the last reply for today! Please don't rant on me!
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?
(Calm down, I'll also stop with the UNIX thing...)
- Branden
