|x86 register allocation firstname.lastname@example.org (1999-03-23)|
|Re: x86 register allocation email@example.com (1999-03-28)|
|Re: x86 register allocation firstname.lastname@example.org (Robert Sherry) (1999-03-28)|
|x86 register allocation email@example.com (Matt Postiff) (1999-03-28)|
|Re: x86 register allocation firstname.lastname@example.org (1999-03-28)|
|Re: x86 register allocation email@example.com (Sander Vesik) (1999-03-28)|
|Re: x86 register allocation firstname.lastname@example.org (Charles E. Bortle, Jr.) (1999-03-28)|
|From:||Sander Vesik <email@example.com>|
|Date:||28 Mar 1999 17:04:59 -0500|
In comp.compilers firstname.lastname@example.org wrote:
> Can anyone give me a pointer to help me with x86 register allocation?
A distinct possibility in the case of "hyperoptimised" processors with
a small number of registers would probably be to treat the real
processor as the microcode for a "virtual" processor with a different
number of registers.
So instead of allocating for the 8 registers (and maybe scheduling
instructions on the top of that for the processor resources) not
allocate for a fictional set of say 32 registers that are allocated in
a separate "scratchpad" area of RAM.
The real register allocation would then be just a two level wrap-up
optimisation on top of that, with the first pass selecting a set of
the fake registers (equal in number to the rename registers in the
specific processor?) and the second pass as a scheduling pass on top
After all, adress calculation is often a separate unit in modern x86s,
as are there things like memory write forwarding, memory renaming, etc.
that would remove some of cost added with copy ins and outs of the
well, mostly just an idea.
Return to the
Search the comp.compilers archives again.