nelson@avsdS.UUCP (05/23/84)
#
The following flame about C compilers for micros specifically
discusses BDS C for 8080 and Aztec C for 8080/Z80. However,
the point being made is that standardization is not always
an acceptable tradeoff for speed. I'd like to hear from users
with experience on MS-DOS or CPM/86. From what I hear, DeSmet
seems to be the winner in that arena, and the cheapest.
I've recently been forced to use Aztec C for Z80 on a Kaypro 10 -
all software on the hard disk. I am shocked and disgusted at how
slow it is. I've come to the conclusion that I'd rather suffer
the trouble of a non-standard I/O library as in BDS C than have
to wait more than 5 times as long for compile/assemble/link.
Yes, it really does take 5x or more longer, really does run slower,
really is a less complete library.
The BDS library differs only in open, fopen, fwrite and such things.
Furthermore these are close enough to real v7 to require little
change. BDS C requires you to allocate space for the file pointer
and then call fopen with that arg, rather than returning the arg
to you. A relict from the early days of BDS when alloc() didn't
exist, I suspect, and one that is easily remedied.
The other big problem with BDS is that all files linked together
that use globals must use the same globals declared in the same order!
This is more like FORTRAN unnamed common, and is not true globals,
but there is an advantage - the BDS linker really screams because
it doesn't have to resolve references to external vars. It's easy
to program this way (use an include file for all globals), but
makes porting to BDS problematical.
Aztec C does not recognize the #if construct, only #ifdef!
BDS C has a symbolic debugger, I/O redirection facilities,
and lots of handy tools (Aztec has been slow to supply them).
I will gladly use Aztec for problems requiring floats, and must
use it when compiling source for v7 compilers, but in the micro
world speed is your greatest obstacle during developement.
All this hue and cry about standards is a moot point to us
non-coffee drinkers (goto coffee_break; /* Standard advice */).
BDS C can compile and link programs in 1 minute that take
5 minutes with Aztec. Slowness like that is inexcusable.
If the implementation is close enough to v7, I will gladly
suffer the small inconveniences.
Glenn Nelson Ampex Corp., Redwood City, CA
...!{nsc|hpda|megatest|amd70}!fortune!dsd!avsdS!nelson
415-367-2499geller@rlgvax.UUCP (05/25/84)
I use the LATTICE "C" compiler version 2.0 and am very happy with it. The
compiler adheres to the Kernighan and Ritchie standard 100%. The document-
ation is fairly good and the support from Lattice is superb. Source code
is compiled in two stages. The first stage parses the source and looks for
syntax errors. The second stage generates code for the 8088. Linking is
done using the IBM Linker which is included with DOS 2.0.
LATTICE provides a debugging tool that will disassembler the .exe file
while displaying the source code that the 8088 instructions pertain to.
This is useful in that it shows how compact and efficient the code is
that the Lattice compiler generates.
I've been a very satisfied Lattice "C" user for quite some time. I choose
Lattice because of its reputation, level of compatibility, and support. I
think I made a wise decision. If you haev any specific questions concerning
the product feel free to send me e-mail.
David P. Geller
Computer Consoles, Inc.
{seismo}!rlgvax!geller Office Systems Group
11490 Commerce Park Drive
Reston, VA 22091
703-648-3483
(of course I have nothing whatsoever to do with Lattice or IBM and
my views are solely mine and do not in any way reflect the views of
my employer)steve@ea.UUCP (05/29/84)
#R:avsdS:-75100:ea:7100013:000:350 ea!steve May 28 21:18:00 1984 <raid> I have a fairly close approximation of the Unix Standard library (as described in the Phototypesetter 7 documentation). I would be willing to post it to net.sources if there is sufficient interest. I have been using it for several years for my own applications. Steve Blasingame (at Oklahoma City University) convex!ctvax!uokvax!ea!steve
ad3@pucc-h (Brown) (05/30/84)
Please do post your library to net.sources.