At 02:08 PM 5/30/2001 +0000, Nick Ing-Simmons wrote:
>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)
>
>Classic CISC code generation taught "us" that CISC is a pain to code-gen.
>(I am not a Guru but did design TMS320C80's RISC specifically to match
>gcc of that vintage, and dabbled in a p-code for Pascal way back.)
Right, but in this case we have the advantage of tailoring the instruction
set to the language, and given the overhead inherent in op dispatch we also
have an incentive to hoist opcodes up to as high a level as we can manage.
> > >> 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.
>
>All that dividing registers into sub-classes does it cause you to do
>register-register moves when things are in the wrong sort of register.
>Its only real benefit is for encoding density as you can "imply" part
>of the register number by requiring addresses to be in address registers
>etc. It is not clear to me that perl special variables map well to that.
>Mind you the names are just a human thing - it is the bit-pattern that
>compiler cares about.
Fair enough. Having the equivalent to perl5's push stack (well, one of 'em)
to save and restore named specials is probably a better idea. There's no
real overriding performance reason to have the specials in the register set.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
