Related articles |
---|
Compiler back-ends [Q] Ben.Sloman@reading.ac.uk (1995-10-21) |
Re: Compiler back-ends [Q] cliffc@ami.sps.mot.com (1995-10-23) |
Re: Compiler back-ends [Q] pardo@cs.washington.edu (1995-10-25) |
Re: Compiler back-ends [Q] jgj@ssd.hcsc.com (1995-10-27) |
Re: Compiler back-ends [Q] collberg@cs.aukuni.ac.nz (1995-10-29) |
Re: Compiler back-ends [Q] Martin.Jourdan@inria.fr (1995-11-03) |
Re: Compiler back-ends [Q] sc@iaxp01.inf.uni-jena.de (Sebastian Schmidt) (1995-11-03) |
Re: Compiler back-ends [Q] cliffc@ami.sps.mot.com (1995-11-03) |
Newsgroups: | comp.compilers |
From: | cliffc@ami.sps.mot.com (Cliff Click) |
Keywords: | code, registers |
Organization: | none |
References: | 95-10-099 95-10-114 95-11-017 |
Date: | Fri, 3 Nov 1995 22:24:42 GMT |
collberg@cs.aukuni.ac.nz (Christian Collberg) writes:
> The BEG back-end generator automatically generates a register
> allocator based on a description of the register set (register
> names, register classes, double registers, etc). You also get
> a choice between a fast/dumb and a slow/smart allocator.
So what's the slow/smart allocator based on?
Can you "automatically" handle ABI's where float args must be passed
in int registers, and there's no float<->int move instructions
(must go through memory)? Automatically here means you don't write
code that sez "if this is a call with float args, then st/ld them
through a magic address", but instead sez something like "I got a
value in register class F, but I need it in register class I, and
there's no F->I move, so spill it & load it & now it's in memory
should I need to spill it later".
Cliff
--
Cliff Click Compiler Researcher & Designer
RISC Software, Motorola PowerPC Compilers
cliffc@risc.sps.mot.com (512) 891-7240
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.