morgan@fluke.UUCP (Bruce Eckel) (07/09/85)
>I am planning on buying a C compiler to run on my CP/M system. What I >would like to know is which one should I buy? Things that I would like >to do are: > * Write interrupt handlers. > * Produce 'com'able code > * Mixed language programming >Would anybody with C compilers on their machines care to relate their >experiences? All responses will be greatly appreciated. > > Mark Ryding > {..trwrb!trwrba!ryding} I have used several C compilers on CP/M and have tried most of the things you refer to. All of them produce "com"able code, if you mean produces a .com file. I also think all of them require you to go through and assembler, linker and loader to accomplish this. If you mean "rom"able, I know Aztec does it and I think the others will too if you put in the right ORG statements or whatnot. There is usually a way even if they didn't design it in. 1) Aztec. Expensive at $200, but K&R complete, or more so than most. Good library. Includes its own assembler, linker and librarian. Slow as mollasses. I use it because I am familiar with it and didn't want to mess with the idiosyncrasies of the others (at the time). No bit fields or preprocessor macros, but it seems NOBODY has those. The manual is geared after UNIX (not a terribly good precedent but OK) which I am sure they developed the language on. One of the big plusses about this system is its transportability -- Aztec makes (virtually) identical compilers for essentially every processor and operating system. They even make cross-compilers so you can (for example) develop on cp/m and run on apple. 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: 3) C/80 . for 50$ (might be 60 now) and 20 extra for floating point, the real bargain in C compilers. I used an early version of this and didn't like it because they didn't seem to conform to K&R (at least not the library functions) and as I was struggling to *learn* the language in the first place, I didn't want to mess with language variants. Now, however, it seems to have been cleaned up significantly. People seem to love it only second to Turbo pascal, and amazing things have been written with it. The people at Software Toolworks (makers of C/80) have written a lot of stuff with it themselves, notably MyCalc (best spreadsheet for cpm I have seen; I am told supercalc does sorts better, but I just like the way MyCalc works. Amazing that visicalc made any money at all, considering how limited it was) and Mychess. Lots of other people use C/80. Real nice to have floating point; I think it comes with Aztec but you might have to pay extra for it. C/80 is probably your best bet (at least to get started). 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). What do I prefer? Well, they all do so many disk accesses, and of course going in and out of the editor (wordstar) is incredibly time consuming. I get very frustrated and am thinking of putting a RAM disk on my Kaypro with a megabyte (~$450) to speed up *everything*. But it seems such a waste for most tasks, which are fast. I keep hearing rumors about: 5) Turbo C. Vaporware at the moment, but if it is anything like Turbo P, it will be worth waiting for. They may have put all their efforts into Modula-2, but we can hope. I would by Turbo C in a second, and be off and running. Failing that, I may just give up the wait and buy Turbo Pascal. Bruce Eckel <morgan> uw-beaver!fluke!morgan
shor@sphinx.UChicago.UUCP (Melinda Shore) (07/09/85)
[]
A few quick follow-up notes to the discussion of various CP/M C compilers:
1) Aztec *does* support parameterized pre-processor macros.
2) The icky thing about the BDS compiler is that it is somewhat
non-standard. Another thing is that, at least in earlier versions
(here's hoping this has been fixed), the compiler didn't know about
floats. There was floating point support in the libraries, however.
--
Melinda Shore ..!ihnp4!gargoyle!sphinx!shor
University of Chicago Computation Center Staff.Melinda%chip@UChicago.Bitnetedwards@h-sc1.UUCP (william edwards) (07/10/85)
> > 1) Aztec. Expensive at $200, but K&R complete, or more so than most. Good > library. Includes its own assembler, linker and librarian. Slow as mollasses. > I use it because I am familiar with it and didn't want to mess with the > idiosyncrasies of the others (at the time). No bit fields or preprocessor > macros, but it seems NOBODY has those. My version of Aztec C for CP/M-80 (1.05g) definitely supports parameterized #defines. Bill Edwards harvard!edwards edwards@harvard.ARPA
Ghenis.pasa@XEROX.ARPA (07/10/85)
I'd like to add that C/80 produces the smallest and fastest .com files. BDS-C compiles very fast, but is probably the most non-standard. For "standardness" and portability you can't beat Aztec. Personally, I have a short fuse, so I stick with Turbo Pascal, which doesn't tax my patience at compile time. I recommend referring to the very complete review of C compilers published recently in Computer Language magazine.
mwm@ucbtopaz.CC.Berkeley.ARPA (Mike (I'll be mellow when I'm dead) Meyer) (07/11/85)
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