At 04:25 PM 5/29/2001 -0400, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> If someone can make a compelling argument for details on how the
> DS> registers should be done that should be visible to the bytecode
> DS> (Like, say, a variant on SPARC's windowing system, or forcing them
> DS> on the stack such that pushes and pops renumber the registers)
> DS> that'd be keen. I can see the merits, but I'm not compelled one
> DS> way or the other quite yet.
>
>here is an idea. if we use a pure stack design but you can access the
>stack values with an index, then the index number can get large. so a
>fixed register set would allow us to limit the index to 8 bits. so the
>byte code could look something like this:
Right, but that means values can potentially have their offsets change
based on what might happen during the course of a section of code, and I'm
not too comfortable with that. The potential for error worries me. Plus it
might make a mixed-type stack trickier. (And yes, I realize the irony of me
arguing against one form of error-prone activity in the same paragraph that
advocates another...)
> literal data support is needed (read only)
Yup. We'll need some sort of constant support, as well as some sort of
sectional literal table.
>the op code is stored in network endian order and the interpreter will
>always build a 16 bit int from the 2 bytes.
Not network. Native. We can put a marker at the beginning of any bytecode
stream, and provide an endian-swapper. That way we're always running at
platform optimal encoding, and if we get bytecode from a platform with
different endianness we can run the utility to swap things for us.
>all registers point to PMC's
I really think we'll win if we have support for at least integers as well
as PMCs. There's potentially a lot of integer work that'll be generated by
the optimizer and, while integer opcodes might not make the interpreter
much faster, they'll speed up TIL and generated C code significantly since
they won't need to call opcodes.
>passing lists to/from subs is via an array ref. the data list is on the
>stack and the array ref is in @_ or passed by return().
PMC for a list, and the args are in the list. (Potentially aliased, of
course) Subs prototyped with input and return data won't use lists,
they'll pass the parameters in registers. (Or something like that)
>special registers ($_, @_, events, etc.) are indexed with a starting
>offset of 64, so general registers are 0-63.
I'd name them specially (S0-Snnn) rather than make them a chunk of the
normal register set.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
