Re: C as assembly language

"felix" <felixundduni@freenet.de> writes:


>2) Well setjmp()/longjmp() are there. I see no reason not to
> use it.


One problem is that on some systems they are very slow. E.g. they may
do a system call to save/restore the signal mask.


However, there are alternatives: Posix has sigsetjmp(), which you can
tell to *not* save the signal mask. And GNU C has __builtin_setjmp()
and __builtin_longjmp(), which compile to a quite small amount of
inline code -- they are quite efficient.


However, even that may still not be very satisfactory if your source
language has LOTS of exception handlers (e.g. C++ destructors) -- in
that case you really want a table-driven exception handling approach,
one that doesn't add significant run-time over per exception handler,
but you can't get it in C.


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


The trouble with the driver loop approach is that you can't pass
arguments in registers anymore (unless you use global register
variables -- and see below for the problems with that), and you have
to use your own call stack, rather than the C call stack. This also
makes interoperability more difficult.


The trouble with continuation passing style is that C compilers don't
do general tail call optimization (indeed, doing so in C is tricky,
because the program might take the address of local variables). So a
straightforward CPS will suffer from stack leaks. There are
approaches to avoid this, but they do have their drawbacks.


>4) The Boehm collector is a very convenient way out of this.
> And writing a precise GC isn't impossible, either.
...
>6) GNU C can use global registers.


Unfortunately, recent versions of GNU C don't support global
registers. It's still in the manual, but gcc often rejects programs,
reporting "internal error / impossible asm", if you use them. For
example, if you add global register variable declarations to the Boehm
collector, it doesn't compile with gcc 2.95.3. And the GCC
maintainers have not expressed any interest in fixing the bugs,
instead the response has been that the global register variable
feature was a bad idea.


>10) Platform issues: SPARC register windows are often more
> in the way than helpful (GNU C has "-mflat").


Unfortunately GCC's `-mflat' does not work in combination with `-fpic',
or at least it didn't last time I looked (2.95.2?).


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


I agree with all of the above. Because of this, I think it's worth
also pursuing another approach, complementary to that of C--, namely
adding support for the features that we need (for example, proper tail
calls) to C or GNU C.


--
Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit
                                                                        | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

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