From: | fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) |
Newsgroups: | comp.compilers |
Date: | 17 May 1997 22:54:56 -0400 |
Organization: | Comp Sci, University of Melbourne |
References: | 97-05-183 97-05-196 |
Keywords: | C, assembler |
Darius Blasband <darius@phidani.be> writes:
>For more exotic models, you might have a look at Mercury (see
>http://www.cs.mu.oz.au/research/mercury) that uses some of gcc's
>subtleties to by pass the limitations of the common C model
>(restrictions to local gotos, for instance). They do support plain C
>as well by using a set of rather intricate preprocessor macros.
>
>On the other hand, I am not sure this (I mean, using gcc's multiple
>extensions) is much less work than actually writing a reasonably naive
>code generator from scratch.,
Well, getting it all to work was a fair bit of work, I suppose. And
the code we are generating is pretty low-level: we're doing all our
own stack management, and most of our own register allocation.
However, we didn't have to do instruction selection or instruction
scheduling. And most importantly, we basically only had to do it
once. Porting to a new processor is much much easier this way.
>while these extensions, by performing operations on registers beyond
>gcc's control, might (no evidence) limit gcc's ability to produce
>optimal code.
We divide the registers into two sets; one set we define as global
register variables, and allocate ourselves, while the other set we
leave for gcc to use for expression evaluation, etc. On machines with
a decent set of registers, this works pretty well. On x86s it
probably costs us a bit.
--
Fergus Henderson <fjh@cs.mu.oz.au>
WWW: <http://www.cs.mu.oz.au/~fjh>
PGP: finger fjh@128.250.37.3
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.