At 05:41 PM 9/10/2001 -0400, Ken Fox wrote:
>Dan Sugalski wrote:
> > =item if tx, X, Y
>
>What's the purpose of providing Y? Does it make anything easier
>allowing Y != 0?
Hmmm. No, it doesn't, it just bloats out the opcode stream by an IV. I'll
fix that.
> > =item jump tx
>
>I expected a "call" op too. Not a named sub call, but just "call
>tx" where tx has the same semantics as in "jump".
>
>A "return" op is needed too.
In the next rev, I just haven't mailed it out yet.
> > =item iton Nx, Iy
> > =item ntoi Ix, Ny
> > =item tostring Sx, ty, Iz
>
>Are these good names? They aren't very regular IMHO. Why is
>integer abbreviated "i" and string left spelled out? Why does
>tostring have three operands and the other two?
No, because, and the third is a string type, on the off chance you wanted a
non-native string. (Unicode, EBCDIC, whatever) Respectively. :)
> > =item inc tx, nn *
> > =item dec tx, nn *
>
> > Decrement register x by nn. nn is an integer constant. If nn is
> > omitted, decrement by 1.
>
>Variable length ops don't sound so cool to me. Why not use
>add/sub to inc/dec by something other than 1?
They aren't variable length. They're actually inc_i & inc_i_ic (and inc_n,
inc_n_nc, and so on...) under the hood. The assembler is supposed to be
smart enough to see you did:
inc N2, 5
and know it's supposed to emit the inc_n_nc form.
The assembler's not that smart yet.
>Also, it would be nice if inc/dec *always* kept Parrot semantics
>instead of automagically transmogrifying to Perl inc/dec. Is
>this the plan?
Dunno what you mean. I & N registers increment numerically, PMC registers
get the variable's vtable inc function called, and I don't know what
happens if we do it on a string register. We might not allow it.
> > =head2 Register and stack ops
>
>I'm a little confused why we can only push/pop entire register
>frames. Won't this make function value returns via registers
>impossible? IMHO, instead of push/pop a rotate command
>would be nice. That would allow SPARC-like register usage which
>has always seemed elegant to me.
There are things missing. There's a fetch from the past op, a
push-with-clone op, and a push on the generic stack op. They're just not in
the doc I mailed yet.
> > =item warp [string]
> >
> > Reset the current register stacks to the state they were in when the
> > warp was set. Resets only the frame pointers, doesn't guarantee the
> > contents of the registers. Be I<very> careful modifying the frame
> > pointers by, for example, pushing register frames.
>
>I don't understand this explanation. It sounds like you are setting
>up co-routines or maybe resuming a continuation. Shouldn't the ops
>be a little safer? IMHO we don't want a co-routine construction set,
>we just want co-routines.
It's more for the case when we've pushed a few frames of registers and need
to get back to the marker for a moment. Sort of like
setjmp/longjmp/comefromjmp in C. (If it had a comefromjmp to undo the
longjmp...)
Might turn out to be a stupid thing. If so, it's out of there.
> > =item find_lex Px, sy
> >
> > Find the lexical of name sy and store the PMC pointer in register Px.
>
>You're expecting the current lexical scope to be carried implicitly
>via the PC?
No, it'll be in the interpreter struct.
>Seems like find_lex should really be implemented as a
>vtable method on a compiler's scope object.
Well, if we had one we could, I suppose.
> > =item find_method Px, Py, tz
> > =item call_method Px, ty
>
>Multi-methods are notably absent.
Haven't gotten there yet.
>I'm assuming that Parrot does not
>understand multi-methods and requires the object (or the compiler
>generating the object) to register a multi-method dispatcher as the
>single-dispatch method known to Parrot.
Nope, multimethod dispatch will be built in, at least for some number of
args. (At least 2, maybe more) It's a lot more efficient if parrot handles
that.
>This only lets us use multi-methods where arg0 is an object. Is
>this sufficient for implementing Perl 6?
Ummm... how on earth do you plan on calling a method of something that's
not an object? Methods sorta require them... :)
Anyway, I realized that bit of the PDD was unfinished after I sent it. I'd
hoped to correct it before it got poked at, but didn't get a chance.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk