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

Dwight VandenBerghe <dwight@pentasoft.com>
16 May 1997 23:56:09 -0400

          From comp.compilers

Related articles
Compiling to C (where C is used as misspelled assembly) bear@sonic.net (Ray Dillinger) (1997-05-14)
Re: Compiling to C (where C is used as misspelled assembly) fabre@gr.osf.org (Christian Fabre) (1997-05-16)
Re: Compiling to C (where C is used as misspelled assembly) fjh@mundook.cs.mu.OZ.AU (1997-05-16)
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)
[4 later articles]
| List of all articles for this month |
From: Dwight VandenBerghe <dwight@pentasoft.com>
Newsgroups: comp.compilers
Date: 16 May 1997 23:56:09 -0400
Organization: Pentasoft Corporation
References: 97-05-183
Keywords: C, assembler, comment

Ray Dillinger <bear@sonic.net> wrote
> It will mean a program is
> compiled into a *single routine* of C code, with Goto destinations
> that might be more than 64K bytes away -- and no templates, no library
> functions linked, no header files, etc etc....
>
> Will modern C systems handle this?


I have to disagree with our moderator on this one. As the author of a
couple of commercial-grade C compilers, I remember well the period of
time when what we had for C++ was cfront, which generates really nasty
C code. When cfront reigned supreme, all the C vendors had to go in
and fix their compilers to take care of the things that you are
worried about. So I wouldn't be surprised if you could compile your
output right out of the box.


However ... and this is a big "however" ... what you are going to most
certainly find is that there is a limit to the size of a function that
can be "optimized." They will probably compile your code, but most C
compilers have an upper bound on the number of tree nodes that they
are willing to attempt to run through their full optimization
passes. This is due in part to static limits on tables and so forth,
and in part to the use of algorithms that run at something like
O(n^2). I would expect that you will be seeing a lot of "function
body too large, optimization pass skipped" messages.


And this is unfortunate. C compilers can do a lot of your work for
you, if you let them. In particular, if you can generate code that
assures that your pointers don't point to places they shouldn't (the
"aliasing" problem) then you can turn off aliasing in the C compiler
and it can generate way better code that if it has to assume aliases
might be around. There are other considerations like this as well.


So think about your problem, and consider some alternatives. Having a
function call here and there might be an acceptable tradeoff, mightn't
it, if it means that you get, say, 10% better code in the function
bodies due to the availability of the C compiler's optimizer? Run
some tests. It's easy to write a little awk script that generates a C
function of arbitrary size. See where the limits are in the compilers
that you are going to be working with primarily. Look at the code and
see if the optimized version is significantly better than the
unoptimized version.


Good luck!


Dwight
[Aha. I knew C++ was good for something. -John]
--


Post a followup to this message

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