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.