Re: Support for export keyword ?
On Jan 22, 8:15 pm, Jerry Coffin <jerryvcof...@yahoo.com> wrote:
In article <c3429901-2c15-4721-91bc-d675cd3d5b7a@
30g2000yqu.googlegroups.com>, james.ka...@gmail.com says...
[ ... ]
No -- Intel produces object code directly.
That would surprise me. Every compiler today uses several
phases, the first of which parses and translates the code to an
intermediate representation.
Yes, in this case, "directly" just means you'd have to work
_really_ hard to get at/see the intermediate code (e.g. run
the compiler under a debugger, and decipher the intermediate
code from a dump of memory...)
Yes and no. The intermediate code is generally not that hard to
get at. The only difference is that generally, if it's not C,
it's not text at all, so you'd need some sort of special program
to read it.
[ ... ]
All compilers today (and ever since I can
remember) divide compilation into several phases.
Generally it's going the other direction -- at one time,
compilers used far _more_ passes (phases, if you prefer)
simply due to memory limitations. I've never seen it
confirmed, but according to rumor one of the early PL/I
compilers reputedly used over 100 passes...
There are swings. I remember a PL/I compiler that ran in 16 KB.
And took three or four hours to compile a 200 line program. But
I think it still only did two passes: what made it slow was that
just about every distinct operation in each pass was in a
separate overload (loaded from disk), and it kept almost all of
its data structures (parse tree, symbol table, etc.) on disk.
Today, I suppose that it would be entirely possible to do
everything on the fly, generating the intermediate
representation of each function in memory, then invoking the
back-end on it, before continuing to the next function. I don't
know of any compiler which actually does this (but some do
maintain the intermediate representation, or some variant of it,
until link time).
Anyhow, for those not familiar with compiler technology, the
"classical" compiler uses four passes: a front-end (which
creates the intermediate representation), an optional optimizing
pass (sometimes called the middle-end, for mostly machine
independent optimizations, like common sub-expression merging
and hoisting invariants out of loops), a back-end which
generates machine code, and an optional peep-hole optimizer
which does low level optimizations. The original C compiler
added a preprocessor, and generated assembler, rather than an
object file, both of which added a pass, but it skipped the
optimization passes. Modern C++ compilers will probably be
closer to the classical model, merging the preprocessor with the
front-end, and going directly from the intermediate
representation to object format, rather than assembler. The
better ones, of course, will defer object code generation and
most of the optimization to link time.
[ ... ]
And the EDG front end is without a doubt the best front end
currently available. Configure it to generate C, and add a high
quality C compiler as the back end, and you have one of the best
C++ compilers around.
As I understand it, you don't really have to configure it to
generate C -- that's what it generates by default. The C
generator demonstrates the hooks you use to generate other
output. From what I've read, EDG's license with Comeau _may_
preclude others from selling versions that only generate C as
output though (not certain of that, but one old newsgroup post
from one of the EDG guys gave that impression). At most that's
purely a licensing situation though -- there's certainly no
technical reason anybody else couldn't do it.
As I understand it (but I could easily be wrong), the EDG
front-end doesn't do anything by default. You have to configure
it specifically. EDG doesn't sell compilers to people like you
and me; they sell front-ends to people who will provide their
custom back-end, plus additional packaging.
I would note, however, that there's a bit more to implementing
export than just getting the front-end right.
This is something I've often wondered about. Doing export
correctly would seem to involve more than the front end.
Comeau also uses a pre-linker that (among other things)
detects whether an object file contains all the necessary
instantiations of an exported template, and re-runs the
compiler to produce others of needed. The front-end _does_,
however, implement the two-phase name lookup, which is the
hard part.
The bottom line is that Comeau themselves (himself, mostly)
does make a real contribution to this -- it's not just a
matter of compiling the EDG front end and selling the result.
Agreed. EDG does all of the really hard bits, but Comeau still
has a fair amount of work to do. An awful lot, if you consider
that it's basically a one man firm. Greg Comeau certainly earns
every penny he makes off the compiler.
--
James Kanze