>>>>> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Uri Guttman <[EMAIL PROTECTED]> writes:
>>
>> 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)
NI> Classic CISC code generation taught "us" that CISC is a pain to code-gen.
NI> (I am not a Guru but did design TMS320C80's RISC specifically to match
NI> gcc of that vintage, and dabbled in a p-code for Pascal way back.)
i disagree. cisc went out of style for speed reasons, not because of
compilers. most risc compilers are much more complicated than cisc
compilers. they have to manage complex register usage, deal with delayed
branches, reorder instructions to fill pipelines, etc. what happened was
that the higher level instruction logic in a cisc chip was removed and
put into the compiler. but we are not doing a risc like IL so this is moot.
>>
>> >> 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.
NI> All that dividing registers into sub-classes does it cause you to do
NI> register-register moves when things are in the wrong sort of register.
NI> Its only real benefit is for encoding density as you can "imply" part
NI> of the register number by requiring addresses to be in address registers
NI> etc. It is not clear to me that perl special variables map well to that.
NI> Mind you the names are just a human thing - it is the bit-pattern that
NI> compiler cares about.
no register to register moves are needed. if you call tr with the
default $_ it get generated as:
TR_OP REG_ARG, <map_reg>, <result_reg> ; REG_ARG is $_
where <> are register indexes generate by the compiler. it assumes
something is already in $_
if you use tr on $foo you code gen:
push <reg> ; save reg if needed
load <reg>, $foo ; load if needed - probably more code
; than this
TR_OP <reg>, <map_reg>, <result_reg>
the first two lines are only there is $foo isn't in a register yet.
in both cases <result_reg> is picked by the compiler and must be free to
use. it gets the tr count return (the result of the op).
the idea is that coding for $_ or $foo is basically the same. you just
use the special register index for $_ vs. any regular one for $foo.
code generation with this type of IL is almost one to one with
perl. most of the language level operations map to one op code, so it is
mostly a case of managing the data in and out of the registers and
calling the op codes. a real compiler has to do so much more. TIL and c
back ends will need much more work than the basic perl to IL
translation.
idea: we have a VOID special register. it is like /dev/null. if you
execute an op in a void context, you pass in the VOID special register
to get the result. then either no result is generated or stored
depending on how we code it. this doesn't handle the runtime context of
sub calls.
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
