Related articles |
---|
x86 register allocation dplass@yahoo.com (1999-03-23) |
Re: x86 register allocation dwight@pentasoft.com (1999-03-28) |
Re: x86 register allocation rsherry@home.com (Robert Sherry) (1999-03-28) |
x86 register allocation postiffm@umich.edu (Matt Postiff) (1999-03-28) |
Re: x86 register allocation bcombee@metrowerks.com (1999-03-28) |
Re: x86 register allocation sander@haldjas.folklore.ee (Sander Vesik) (1999-03-28) |
Re: x86 register allocation cbrtjr@ix.netcom.com (Charles E. Bortle, Jr.) (1999-03-28) |
From: | Sander Vesik <sander@haldjas.folklore.ee> |
Newsgroups: | comp.compilers |
Date: | 28 Mar 1999 17:04:59 -0500 |
Organization: | ERA/EKI FO |
References: | 99-03-080 |
Keywords: | 386, registers |
In comp.compilers dplass@yahoo.com 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
that.
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
scratchpad ram.
--
Sander,
well, mostly just an idea.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.