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

Reply via email to