>>>>> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Simon Cozens wrote:
>> To be more specific about the software CPU, it will contain a large
>> number of registers.
KF> The register frames store values, not pointers to values? If
KF> there's another level of indirection with registers, I'm not sure
KF> what the advantage is over just pointing into the heap. Also, heap
KF> based activation records might be faster and more compact than
KF> register files.
the registers are the way to make op code args be simple and small
integers which is portable and clean. with a direct heap, you need
pointers or large integers and complex code generation.
the point of registers is to make the op code tree simple to generate
and to use all the older compiler tricks for register machines. there
are no classic heap based compilers to steal from.
>> As in Perl, Parrot ops will return the pointer to the next operation in
>> the bytecode stream. Although ops will have a predetermined number and
>> size of arguments, it's cheaper to have the individual ops skip over
>> their arguments returning the next operation, rather than looking up in
>> a table the number of bytes to skip over for a given opcode.
KF> This seems to limit the implementation possibilities a lot. Won't a
KF> TIL use direct goto's instead of returning the next op address?
TIL is a different beast. the code layer directly called by the op code
dispatch will be gone in TIL. how goto's and stuff will be handled is
not clear yet. and TIL is not an issue with the register machine, it is
a different back end effectively. it will use the real op functions to
do most of its work along with in line real machine code to call them.
KF> I'd like to see a description of *just* the opcode stream and have
KF> a second section describe the protocol for implementing the ops.
KF> Won't we have separate implementations of the opcode interpreter
KF> that are optimized for certain machines? (I'd at least like to see
KF> that possibility!)
there will be support for custom op code dispatch loops. in particular a
event loop version will be made without checking the event flag between
each op. instead it will do that check when event callbacks return. it
should be somewhat faster and more tuned for event style design.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture and Stem Development ------ http://www.stemsystems.com
Search or Offer Perl Jobs -------------------------- http://jobs.perl.org
