Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!oberon!poisson.usc.edu!mlinar From: mlinar@poisson.usc.edu (Mitch Mlinar) Newsgroups: comp.lang.c,comp.lang.misc Subject: Re: Small-C Message-ID: <3566@oberon.USC.EDU> Date: Tue, 21-Jul-87 23:08:29 EDT Article-I.D.: oberon.3566 Posted: Tue Jul 21 23:08:29 1987 Date-Received: Thu, 23-Jul-87 07:16:09 EDT References: <3452@ihlpg.ATT.COM> <213@xrxns.UUCP> <3433@oberon.USC.EDU> <1415@crash.CTS.COM> Sender: nobody@oberon.USC.EDU Reply-To: mlinar@poisson.usc.edu.UUCP (Mitch Mlinar) Organization: University of Southern California, Los Angeles Lines: 60 Keywords: Byte Works, Inc., Small-C, Xref: mnetor comp.lang.c:3201 comp.lang.misc:564 In article <1415@crash.CTS.COM> mwilson@crash.CTS.COM (Marc Wilson) writes: > > Where is this newer version of Small-C. I have the 2.1 version, and >it definately does NOT support the things you describe. I also have an OLD ^^^^^^^^^^^ which things? (an honest question, really) >copy of C/80 that I'd love a manual for... if someone can point me in the >right direction? > > Also, why is 8-bit Mix C so bad? No flames, please, just objective > opinions. >-- Hmmm. Put me under the gun, eh? I will have to revisit my Small C disk before I can fully answer your questions. Same goes for Mix C: my evaluation of both is over a year old and I have not looked at EITHER since. Mix C has (had) many problems for the CP/M version. (Some have since been fixed, I am sure.) Besides a major lseek() glitch and other library bugs (although C/80 has the MOST anemic library for a commercial product), other observations were: - slowest compile of the bunch (bunch = C/80, Aztec, Manx, BDS, Small-C, and CZ. I was having fun evaluating and got carried away.) - optimizers for speed or size (mutually exclusive) would slow down compilation by 15% and squeeze about 1-3% out of the code or pick up 5% in speed. Not very impressive (unless the code is efficient already), BUT - second worst code size (but not by much). The worst is Aztec and often produces code 2x BDS and C/80 and 3x of CZ. Small-C was pretty good, but did not have a lot of power. - NO machine language support to speak of: writing assembler code to link to their C routines was not possible. Now I know they fixed this in IBM world, and may have done so in CP/M, but not at that time. - code speed was THE slowest. Although compilation was also the worst, it was not the worst by much (Aztec won second place). Code speed was second slowest in - you guessed it - Aztec again, but still ran circles around the Mix object code. Worst ratio was CZ versus Mix, CZ ran 4x faster in some cases! However, this much I will say about Mix C: the manual is VERY good for learning C and is the first "human readable" definition of union I have seen. (Programmers don't seem to have trouble with that, but MANY non-programmers have trouble grasping that the first time. In 3 out of 3 cases, the non-programmer involved read the Mix C manual and understood.) In fact, of all the C packages described, it has the BEST manual with no second banana in sight. I keep the manual on the shelf and tossed the disks into the closet; I still believe the manual was worth the price and they could keep the disks... (It is not a good reference, but has very good explanations.) -Mitch P.S. For you Aztec C fans out there, it does have one STRONG point: it is one of only two C compilers that can digest C code produced on UN*X. Hence, when I had to shuttle code back and forth at one time, it was used quite heavily. (CZ, the other, now handles that task when needed.) Aztec also suffers from fanatical K&R-itis; few of the accepted extensions to C are digested in the latest version I have (Nov last year: 1.06D?) I cannot count C/80, Manx, or BDS as these compilers have had no updates since 83 or 84.