Re: Compiling to C (where C is used as misspelled assembly)

fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)
17 May 1997 22:54:56 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: Compiling to C (where C is used as misspelled assembly) chase@world.std.com (David Chase) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) darius@phidani.be (Darius Blasband) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) hbaker@netcom.com (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) ramb@spring.epic.com (Ram Bhamidipaty) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) dwight@pentasoft.com (Dwight VandenBerghe) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) conway@mundook.cs.mu.OZ.AU (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) fjh@mundook.cs.mu.OZ.AU (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) monnier+/news/comp/compilers@tequila.cs.yale.edu (Stefan Monnier) (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) cdg@nullstone.com (Christopher Glaeser) (1997-05-17)
Re: Compiling to C (where C is used as misspelled assembly) conway@mundook.cs.mu.OZ.AU (1997-05-22)
Re: Compiling to C (where C is used as misspelled assembly) conway@mundook.cs.mu.OZ.AU (1997-05-22)
Re: Compiling to C (where C is used as misspelled assembly) Dave@occl-cam.demon.co.uk (Dave Lloyd) (1997-05-22)
Re: Compiling to C (where C is used as misspelled assembly) partain@dcs.gla.ac.uk (Will Partain) (1997-05-22)
[2 later articles]
| List of all articles for this month |
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
--


Post a followup to this message

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