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]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.