Re: Compiler back-ends [Q] (Jeff Jackson)
Fri, 27 Oct 1995 21:47:36 GMT

          From comp.compilers

Related articles
Compiler back-ends [Q] (1995-10-21)
Re: Compiler back-ends [Q] (1995-10-23)
Re: Compiler back-ends [Q] (1995-10-25)
Re: Compiler back-ends [Q] (1995-10-27)
Re: Compiler back-ends [Q] (1995-10-29)
Re: Compiler back-ends [Q] (1995-11-03)
Re: Compiler back-ends [Q] (Sebastian Schmidt) (1995-11-03)
Re: Compiler back-ends [Q] (1995-11-03)
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Jeff Jackson)
Keywords: registers
Organization: I would rather be windsurfing.
References: 95-10-099 95-10-114
Date: Fri, 27 Oct 1995 21:47:36 GMT

> Register allocation is an amazing can of worms, and I don't know
> of any machine-generated code techniques being used there.

Actually, the PQCC compiler of Wolf, Leverit, etc had a very powerful
model for describing the registers of machines for a portable register
allocator. We use it in our CCG technology here at Harris Computer
Systems. We've used the same register allocator on diverse
architectures from the H-Series (6024 -- a 24 bit word addressable
machine where every register either overlaps part of another or has a
number of special uses or both), to modern RISC machines such as
PowerPC, 88110, etc.

The basic idea is that you have an "address space" called a storage
base. General Registers, Floating Point Registers and Stack are
examples of storage bases. A storage base is composed of storage
classes where each class consists of sets of groups elements of
storage bases that can be used more or less interchangeably for some
purpose. Thus even numbered general register pairs excluding r0,r1
might compose one storage class. Individual instructions take
operands of only specific classes. The compiler then extracts from
the machine description of operations where it can/must put variables
and temporaries.
Jeffrey Glen Jackson

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.