Front page | perl.perl6.internals |
Postings from May 2001
>>>>> "NI" == Nick Ing-Simmons <nick@ing-simmons.net> writes: NI> Uri Guttman <uri@sysarch.com> 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 --------- uri@sysarch.com ---------- 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.htmlThread Previous | Thread Next