>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> "We" need to decide where a perl6 sub's local variables are going
NI> to live (in the recursive case) - if we need a "stack" anyway it
NI> may make sense for VM to have ways of indexing the local "frame"
NI> rather than having "global" registers (set per thread by the way?)
i made that thread point too in my long reply to dan.
but indexing directly into a stack frame is effectively a register
window. the problem is that you need to do an indirection through the
window base for every access and that is slow in software (but free in
hardware).
NI> What I do agree with is that
NI> push a
NI> push b
NI> add
NI> pop r
NI> is lousy way to code r = a + b - too much pointless copying.
NI> We want
NI> add #a,#b,#r
NI> were #a is a small number indexing into "somewhere" where a is stored.
and that is an N-tuple opcode with a fixed size register set. register
windowing is not needed here, as pushing/popping as needed works well.
the win of a stack system is a cleaner and simpler op code api with
fewer op codes. but that doesn't gain us much as we have so many complex
ops that compiling them to simpler ones and all the extra runtime is a
loss.
BTW, an N-tuple op code is easily converted to/from an asm form which is
a feature that has been mentioned as desired. you can look at higher
level CISC instruction sets (e.g. vax) for examples. hell, the vax had a
polynomial op code and high level string ops!
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
