|[2 earlier articles]|
|Re: Optimizing in assembly language firstname.lastname@example.org (Shankar Unni) (2001-03-26)|
|C as assembly language email@example.com (Joachim Durchholz) (2001-04-04)|
|Re: C as assembly language firstname.lastname@example.org (2001-04-10)|
|Re: C as assembly language email@example.com (2001-04-10)|
|Re: C as assembly language firstname.lastname@example.org (Morrisett) (2001-04-10)|
|Re: C as assembly language email@example.com (jacob navia) (2001-04-10)|
|Re: C as assembly language firstname.lastname@example.org (felix) (2001-04-10)|
|Re: C as assembly language email@example.com.OZ.AU (2001-04-10)|
|Re: C as assembly language firstname.lastname@example.org.OZ.AU (2001-04-12)|
|Re: C as assembly language email@example.com (2001-04-12)|
|Re: C as assembly language firstname.lastname@example.org (felix) (2001-04-14)|
|Re: C as assembly language email@example.com.OZ.AU (2001-04-14)|
|Re: C as assembly language firstname.lastname@example.org (Randall Hyde) (2001-04-14)|
|[8 later articles]|
|Date:||10 Apr 2001 01:33:34 -0400|
|References:||01-03-006 01-03-046 01-03-130 01-04-027|
|Posted-Date:||10 Apr 2001 01:33:34 EDT|
Joachim Durchholz wrote in message 01-04-027...
>Hmm... there are a few additional cases where C is simply inappropriate:
>1) You want to check for integer overflow.
>2) You need exceptions.
>Oh, and slightly off-topic, there are a few other things that annoy
>those who want to use C as a backend for their compiler:
>3) It has no support for tail call recursion.
>4) It has no support for automatic garbage collection.
>(The following are from http://www.cminusminus.org/faq.html:)
>5) It cannot return multiple values in registers
>6) It cannot bind global variables to registers
>7) It has no support for lightweight concurrency
>Not all of these features are required for each language, but many
>(most?) languages need at least one of them.
It is generally true that C has it's problems when considered
an "assembly" language, but I would like to add something to
1) Integer overflow detection is a big problem in C (I would say
perhaps even the biggest). The obvious solution to perform
integer- and floating-point arithmetic in parallel will of course
always be inferior. It would be interesting, though, to measure
how much of the fp-arithmetic can be done truly in parallel
on modern RISC processors with separate execution units
for integer- and fp-math.
2) Well setjmp()/longjmp() are there. I see no reason not to
3) Tail-recursion is hard in C. Even GCC can't do it in the
general case. Possible solutions: a driver-loop (or "trampoline")
as used in Steele's Rabbit, in Gambit or sml2c, or Continuation Passing
4) The Boehm collector is a very convenient way out of this.
And writing a precise GC isn't impossible, either.
5) CPS would be a possible answer: a return is transformed into
a call, so multiple values can be passed in registers without problem.
6) GNU C can use global registers.
7) With underlying concepts like trampolines or CPS lightweight
threads are no problem, either. The next release of the
Gambit Scheme compiler is supposed to offer threads based on first-class
continuations that outperform all types of native Linux- and Java-
Some additional points:
8) First class continuations: CPS or trampolines.
9) Language issues: aliasing rules in C can limit the set of
possible optimizations (GNU C offers "-fstrict-aliasing", how
far this helps, I can't say).
10) Platform issues: SPARC register windows are often more
in the way than helpful (GNU C has "-mflat").
Concepts like CPS or trampolines/driver-loops have of course their
own problems. I'm not saying any of these is the perfect solution.
But an important points is IMHO that C (or GNU C - limiting yourself
to GNU C as a target language would be perfectly acceptable)
offers a couple of things:
- Easy availability
- Availability of tools like profilers, debuggers, etc.
The huge amount of effort put into GCC, for example, is hard to match.
This is one reason why I think C-- will have a hard time ever to
compete seriously with it.
The huge amount of work needed to write a robust and optimizing native
code backend is IMHO out of the question for anything but large
Return to the
Search the comp.compilers archives again.