>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 04:25 PM 5/29/2001 -0400, Uri Guttman wrote:
>> 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:
DS> Right, but that means values can potentially have their offsets
DS> change based on what might happen during the course of a section
DS> of code, and I'm not too comfortable with that. The potential for
DS> error worries me. Plus it might make a mixed-type stack
DS> trickier. (And yes, I realize the irony of me arguing against one
DS> form of error-prone activity in the same paragraph that advocates
DS> another...)
current compilers do it all the time. they track register usage at
compile time and push/pop at runtime to keep the code working. a given
op is passed its args as register offsets. before/after that, there may
be ops to set up the registers. only during that single op call are the
needed registers known. this is not a sub call in perl with complex
stuff, but a single IL op call with a handful of registers passed to
it. most registers will be recycled after each perl level statement as
they are temps. only those that are mapped to real vars (and other live
things) are kept between statements.
think of this as classic CISC code generation with plenty of registers
and a scratch stack. this is stable technology. we could even find a
code generator guru (i don't know any obvious ones in the perl6 world)
to work with us on this.
>> the op code is stored in network endian order and the interpreter will
>> always build a 16 bit int from the 2 bytes.
DS> Not network. Native. We can put a marker at the beginning of any bytecode
DS> stream, and provide an endian-swapper. That way we're always running at
DS> platform optimal encoding, and if we get bytecode from a platform with
DS> different endianness we can run the utility to swap things for us.
i disagree. bytecode should be portable without conversions. we store 16
bits in a known order (i picked network at random :) and build a native
16 bit int as we execute. or use only an 8 bit op code with one or more
escape code for the next 256 codes (like Hong Zhang said).
>> all registers point to PMC's
DS> I really think we'll win if we have support for at least integers
DS> as well as PMCs. There's potentially a lot of integer work that'll
DS> be generated by the optimizer and, while integer opcodes might not
DS> make the interpreter much faster, they'll speed up TIL and
DS> generated C code significantly since they won't need to call
DS> opcodes.
ok, some special registers for hardware ops like add. but they should be
indexed off the same register set with the other special registers.
>> 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().
DS> PMC for a list, and the args are in the list. (Potentially
DS> aliased, of course) Subs prototyped with input and return data
DS> won't use lists, they'll pass the parameters in registers. (Or
DS> something like that)
same idea but you clarified it.
>> special registers ($_, @_, events, etc.) are indexed with a starting
>> offset of 64, so general registers are 0-63.
DS> I'd name them specially (S0-Snnn) rather than make them a chunk of the
DS> normal register set.
oh, they have macro names which are special. something like:
#define MAX_PLAIN REG 64 /* 0 - 63 are plain regs */
#define REG_ARG 64 /* $_ */
#define REG_SUB_ARG 65 /* @_ */
#define REG_ARGV 66 /* @ARGV */
#define REG_INT1 67 /* integer 1 */
#define REG_INT2 68 /* integer 1 */
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Learn Advanced Object Oriented Perl from Damian Conway - Boston, July 10-11
Class and Registration info: http://www.sysarch.com/perl/OOP_class.html
