Re: C as assembly language

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
each point:


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
    use it.


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
    Style.


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-
    threads.


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:


- Portability
- Easy availability
- Efficiency
- 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
projects.




cheers,
felix

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