|IL design? email@example.com (2006-12-11)|
|Re: IL design? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-12-11)|
|Re: IL design? bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-12)|
|Re: IL design? Juergen.Kahrs@vr-web.de (=?ISO-8859-1?Q?J=FCrgen_Kahrs?=) (2006-12-13)|
|Re: IL design? bobduff@shell01.TheWorld.com (Robert A Duff) (2006-12-14)|
|Re: IL design? firstname.lastname@example.org (Russ Cox) (2006-12-14)|
|Re: IL design? email@example.com (Robert H) (2006-12-21)|
|From:||Robert A Duff <bobduff@shell01.TheWorld.com>|
|Date:||12 Dec 2006 18:30:45 -0500|
|Organization:||The World Public Access UNIX, Brookline, MA|
|Keywords:||design, performance, C|
Jürgen Kahrs <Juergen.Kahrs@vr-web.de> writes:
> Not joking. C is a portable macro assembly language.
That's what everybody says, but I don't think it's true. I think an
"assembly language" is a language whose semantics are defined in terms
of what code gets generated. The presence of macros and whatnot does
not change this -- even with a macro assembler, the programmer has
complete (or nearly complete) control over the generated code.
A "higher level language" has semantics defined in terms of what the
program does. C is clearly this.
As to using C as the output of a compiler, well it has the advantage
of portability. But C is not really a particularly good language for
this task. There is no way in C to get at the hardware's overflow
detection features. There is no efficient way to implement exception
handlers in terms of C. It is very difficult to create source-level
analysis tools (debuggers and whatnot) if you feed everything through
a C compiler.
I've built compilers that generate C, and it can certainly work, but
it's far from ideal.
Return to the
Search the comp.compilers archives again.