Date   : Wed, 10 Jul 1985 22:59:33 GMT
From   : "Mike (I'll be mellow when I'm dead" <mwm%ucbtopaz.cc.ucb-vax.arpa@BRL.ARPA>
Subject: Re: C compilers for CP/M

More followup on the C compiler commentary.

In article <801@vax2.fluke.UUCP> morgan@fluke.UUCP (Bruce Eckel) writes:
>2) BDS .  A friend swears by it and it seems fast, efficient and correct.
>That is, the compiler seems fast.  I don't know that much about the code
>efficiency but he says it is efficient.  $150.  The manual is very good.
>No library is as complete as Aztecs, but you can always add your own
>library modules to any of these.  BDS was really the CPM C standard
>for quite a while, before:

Unlike other C compilers, BDS C does not produce an intermediate
assembler, but produces relocatables directly. This is one of the
reasons for it's compile-time speed. It comes with a program to turn
pseudo-assembler into .CRL files, and a source-level debugger (the only
CP/M-80 compiler to do so, last time I looked). It can be used to
generate rommable code and interrupt handlers (I've done so).

The major loss with BDS C is the I/O library, and no initializers. The
I/O library looks like the PWB library. BDS C is *not* suitable for
writing code for porting to other system, or for porting code from other
systems to CP/M-80. I think it's the best thing around for writing
CP/M-80 code, though.

>4) Q/C.  The only thing I can say about this is it comes with source code,
>written in C.  I don't know how it runs since I've never used it, but if 
>you want to know how a compiler is written, this would probably be $95
>well spent.  Chances are it is real slow (whereas BDS and C/80 are
>written, I believe, in assembly).

BDS C is written in assembler (yet another reason for it's speed). C/80
is written in C. In fact, C/80 and Q/C both started from the Public
Domain Small/C compiler. I was never happy with C/80, as the early
version (v2.0) I have is full of bugs. It did produce fast code, by
copying the arguments into a fixed area of memory, and then back onto
the stack for subroutine calls so recursion worked. This was (I think)
the reason that it evaluated and stacked subroutine arguments from left
to right instead of right to left (like nearly every other C compiler I
know of). This quirk could expose portability problems in your code, and
makes the printf function the single ugliest piece of C I've ever laid
eyes on. They may have fixed this by now.

       <mike