jay (09/07/82)
#N:hp-pcd:6200004:000:10744 hp-pcd!jay Sep 7 11:29:00 1982 A while back I posted a request for information about the BD Software C Compiler. I received numerous responses and numerous requests that I forward the information, so here it is. The messages I received are unedited except for deleting the message headers and names. I want to thank everyone for their input. I ended up buying a copy and so far I am quite pleased with it. Jay Phillips ucbvax!hplabs!hp-pcd!jay ---------------------------------------------------------------------- Yes, BDS C is a win, but this is not based on my personal experience. Instead, a friend down in LA who is working extensively in BDS C to design a Unix-like OS for an 8080 (believe it or not) reports that it is great, much better than any other C he's tried. I've seen the results of his hacking and yes, BDS C can run fairly quickly, can compile fairly quickly, and is an honest-to-goodness subset of Kernighan & Ritchie, missing only a few things that supposedly will be put in with time. ---------------------------------------------------------------------- I played with an early version of the BDS-C compiler, and wasn't too pleased with it. It had lots of bugs and incompatibilities with standard K&R C, but I understand that since then it has been shaken out and is now a solid product. The C I use is C/80 from The Software Toolworks, 14478 Glorietta Dr., Sherman Oaks, CA 91423, phone (213)-986-4885. It is full C except for floats and longs and some trivia like typedef and bit fields. It does have structures and arbitrary pointers and everything I need. It even has the facility to drop into assembler within a routine or anywhere, so you can hand-code tight loops. It generates 8080 code, but you can embed Z80 instructions if your assembler recognizes them. (Toolworks also sells a good Z80 macro assembler). C/80 is $39.95, I think, but you might want to call to confirm that the price is still good. Anyway, I do everything in C/80 and strongly recommend it. It generates good code, too. There is a recent Toolworks ad in some of the standard micro journals that compares its performance to the other Cs on the market. The only one that beat it is Whitesmith, I think, but its compile times are much much faster. ---------------------------------------------------------------------- yes, it IS well worth it, although it is a limited subset it makes up for this with lightining-fast compiles. I'm talking to you via a huffman-encoded terminal program (average 5 bits/char) in BDS C now. ---------------------------------------------------------------------- BDS-C is fast, (almost) bug-free, and wonderful. A 1,000 line program compiled and linked in under three minutes. The only problem is that it does not produce the incredibly efficient code the Whytesmith's compiler will give you. BDS-C is /more/ than worth the pittance Lifeboat charges for it. You might consider using BDS-C during development, and then compiling with Whytesmith's for the final object.... ---------------------------------------------------------------------- I have used the BDS C compiler now for close to three years. It is definitely worth the money!!!!! [Exclamation points are not an overstatement.] It is fast (considering the nature of the equipment that it runs on) and relatively bug-free. I have tried Whitesmith's which is large and cumbersome; it has some wierd stuff like putfmt() instead of printf(), etc., and using it is just the pits. Whitesmith's support can be described as benevolently indifferent, at least for the RT-11 version about which I had to deal with them. BDS supports their compiler through a users' group in Kansas. I had originally purchased version 1.3 and I have been updated through the current release, 1.46, by that group. They do it for the price of a disk! The users' group has many useful utilities and libraries in its software collection, all in the public domain. And since the author, Leor Zollman, "listens" to info-cpm, serious bugs can be taken up with the software's creator. Alas, what BDS C lacks is the ability to handle longs, floats, and initialization. But there are some ways to make do -- some of the users group disks have libraries that somewhat circumvent the first two omissions. They now have command-line redirection available. The linker supports overlay structures. And BDS generates reasonably tight code. Invoking it is a two step procedure: CC1 FOO.C CLINK FOO (rather nice compared to the complexity of Whitesmith's). All in all, the package is worthy of a hearty recommendation! ---------------------------------------------------------------------- If you're looking for a full C implementation for Z80 under CP/M, you might check out Aztec C II from Manx. It supports all of Kernighan & Ritchie except, oddly, "#if", and most of the functions (like printf) are there too. $195. I looked at BDS C and chose to pass on it. It implements too little of the language. I can't live without initialization of static data, for example. By contrast, I just finished writing a BASIC-to-Z80 compiler in Aztec C. ---------------------------------------------------------------------- I have been using BDS-C steadily for the last year and am quite pleased with it. I have an 8080 system, but find that compilation and linking are sufficiently fast and require no assembly step. There is a users group which provides new versions of the compiler and various utility routines at the cost of handling. The treatment of external variables (like FORTRAN unlabelled common blocks) is the only significant complaint I have. The compiler etc. is definitely worth the $140. ---------------------------------------------------------------------- This compiler is the heart of the MARK operating system (unix-like for CP/M) from Lauren Wienstien (sp??). I heard that the compiler doesn't support the long data type (as well as floats and doubles I would assume). ---------------------------------------------------------------------- BDS-C is fast, (almost) bug-free, and wonderful. A 1,000 line program compiled and linked in under three minutes. The only problem is that it does not produce the incredibly efficient code the Whytesmith's compiler will give you. BDS-C is /more/ than worth the pittance Lifeboat charges for it. You might consider using BDS-C during development, and then compiling with Whytesmith's for the final object.... ---------------------------------------------------------------------- I have used the BDS C compiler now for close to three years. It is definitely worth the money!!!!! [Exclamation points are not an overstatement.] It is fast (considering the nature of the equipment that it runs on) and relatively bug-free. I have tried Whitesmith's which is large and cumbersome; it has some wierd stuff like putfmt() instead of printf(), etc., and using it is just the pits. Whitesmith's support can be described as benevolently indifferent, at least for the RT-11 version about which I had to deal with them. BDS supports their compiler through a users' group in Kansas. I had originally purchased version 1.3 and I have been updated through the current release, 1.46, by that group. They do it for the price of a disk! The users' group has many useful utilities and libraries in its software collection, all in the public domain. And since the author, Leor Zollman, "listens" to info-cpm, serious bugs can be taken up with the software's creator. Alas, what BDS C lacks is the ability to handle longs, floats, and initialization. But there are some ways to make do -- some of the users group disks have libraries that somewhat circumvent the first two omissions. They now have command-line redirection available. The linker supports overlay structures. And BDS generates reasonably tight code. Invoking it is a two step procedure: CC1 FOO.C CLINK FOO (rather nice compared to the complexity of Whitesmith's). All in all, the package is worthy of a hearty recommendation! ---------------------------------------------------------------------- I have been using BDS-C steadily for the last year and am quite pleased with it. I have an 8080 system, but find that compilation and linking are sufficiently fast and require no assembly step. There is a users group which provides new versions of the compiler and various utility routines at the cost of handling. The treatment of external variables (like FORTRAN unlabelled common blocks) is the only significant complaint I have. The compiler etc. is definitely worth the $140. ---------------------------------------------------------------------- I've been using BDS C for over 2 years now, and I'm fairly happy with it. There are three major problems (as far as I am concerned): 1) The I/O library is not quite the Unix standard. Close enough to be usable if you don't do file I/O, but... 2) No initializers! (Try initalizing a parse table...) 3) Globals are weird. The look like one (count 'em, 1) FORTRAN common. The lack of statics agravates this. I would still recommnend you buy it. I just recently went through my software, and come up with 2+ Megabytes of BDS C source, almost all of it in the public domain (a line editor, a visual editor, another C compiler, a compiler-compiler, beautifiers, etc). As for other C compilers, I am waiting on the Aztec II C compiler. They claim to have the full stdio library except for scanf. They support int, float, long & double! The cost is $200. If you are interested, let me know and I'll send you/the list a commentary. ---------------------------------------------------------------------- I have used this compiler for well over 1 1/2 years now and am very impressed with it. The author, Leor Zollman, modestly bills himself as "just a graduate student working his way through MIT" but in my opinion, 99% of the software houses could desparately use someone of his talent. BDS C compiles quickly, produces reasonable .COM files (overhead is only objectionable for small programs), and executes fast enough for me to have written communications programs for my Superbrain that operate perfectly at 1200 baud (and could most likely operate at higher rates if I wasn't concerned with gagging my slower per- ipherals). Another example: a colleague has written a production program which prints mailing labels received from a remote UNIX system while accepting, checking and storing on diskette, input from the keyboard destined for subsequent transmission to the host system. A major draw-back is the lack of longs and (if you need them) floats. There are some other goodies not implemented, but for $150, it is a surprizingly complete sub-set of the C language.