rre@ihlpg.UUCP (07/15/87)
Hi. Tired of my UCSD Pascal for my Apple //c (just extending it), I saw an ad for Small-C which would interfact with the ORCA/M shell from Byte Works, the people who make the ORCA/M assembler. I like the shell, so I'm intrigued by the fact that it is C, and Prodos, and only $35.00. But, what is Small-C? Just how much of standard K&R C does it implement or leave out? Thanks. Roger Espinosa ihnp4!ihlpg!rre -- Roger R. Espinosa Live from the Rabbit Ranch ihnp4!ihlpg!rre
dupre@spitfire.UUCP (Frank Dupre) (07/17/87)
In article <3452@ihlpg.ATT.COM> rre@ihlpg.ATT.COM (Velveteen Rabbit Corps) writes: > >But, what is Small-C? Just how much of standard K&R C does it >implement or leave out? > >Roger Espinosa >ihnp4!ihlpg!rre Small-C is a public domain subset of K&R originally written by Ron Cain and published in Dr. Dobb's Journal issue no. #45 (may80). In DDJ #74 (dec82) James E. Hendrix published Small-C v.2, which was followed by his book The Small-C Handbook, ISBN 0-8359-7012-4, Reston Publishing Company, circa 1984. It should be noted that these version were from the Intel 8080/ Zilog Z80, i.e., CP/M machines. Version appeared for the Intel 8088/8086 - 80x86 as 'commerical' products, notably Datalight's Small-C. The original version only recogized char & int, had one-dimensional arrays, and the, while statement, was the only loop-control. The 'new and improved' v2 & v2.1, included th quote Hendrix: (1) code optimization, (2) data initialization, (3) conditional compilation, (4) the extern storage class, (5) the for, do/while, switch, and goto statements, (6) assignments operators (7) Boolean operators, (8) the one's complement operator, and various other features. An implementation for the Mostek 6502, Atari 400,600,800,800XL, 65XE,130XE was done by John Howard Pelevich, this version supported Atari graphics, etc. and was not PD, though the purchase included source code. There have been several other ports of both the original and version 2, to other processors, as well as extentions to the language, and libraries of 'useful stuff' have been created in it, for it. At one time I worked on a version for the 68000 as part of a project for a Compiler Construction Class. Can't find now 8-( still haven't unpacked my graduate school books yet! Hope this helps you out 8-) * (XNS) Frank Dupre:LSBG-EGP/CAD:Xerox * (uucp) (...!seismo!rochester!rocksanne!xrxns!dupre) * (US Post) Xerox Corporation - XICTMD P.O. Box 2000 Leesburg, VA. 22075 * (Intelnet) 8*437-5487 (Ma Bell) (703) 729-8000 Ex# 5487
mlinar@poisson.usc.edu (Mitch Mlinar) (07/18/87)
In article <213@xrxns.UUCP> dupre@spitfire.UUCP (Frank Dupre) writes: >In article <3452@ihlpg.ATT.COM> rre@ihlpg.ATT.COM (Velveteen Rabbit Corps) writes: >> >>But, what is Small-C? Just how much of standard K&R C does it >>implement or leave out? >> >>Roger Espinosa >>ihnp4!ihlpg!rre > > [ some good information ] > >It should be noted that these version were from the Intel 8080/ >Zilog Z80, i.e., CP/M machines. Version appeared for the Intel >8088/8086 - 80x86 as 'commerical' products, notably Datalight's >Small-C. > In fact, nearly EVERY 8-bit compiler on the market (Aztec, Software Toolworks, Manx, etc.) was based upon Small-C. The only three exceptions I know about to date are BDS-C (which was before Small-C), Mix C (which is just awful in 8-bit), and CZ (a Z80 assembly based compiler). > > [ LOTS more good stuff by Frank ] > The current versions of Small-C support 2 dimensional arrays and even limited structures, but - do not support passing anything other than char, int, addresses, or pointers on the stack (no struct) - lousy initialization - no floating point or bit fields - no union - limited complexity (stuff like char *(foo[6])(i,j) will fail) - limited library (as in almost none) BUT in defense of Small-C (which I highly recommend if you want to see the SOURCE to a compiler), it is FREE and a LOT of commercial packages STOLE it (that's what I call it), added and/or fixed a few things, and stamped their own label on it. With the exception of Software Toolworks C/80 (only $49), the rest are overpriced for the amount of ownership. But, Manx at one time also included the source to the compiler for a extra $25 (above its $80), so that might be a better way to go. Nobody includes source in IBM that I know about (for commercial C). Again, if you want to learn a little about compilers, just working with Small-C a few weeks will give you a good feel of the issues, complexity, and headaches of writing a compiler. You might also have some fun. -Mitch
mwilson@crash.CTS.COM (Marc Wilson) (07/20/87)
In article <3433@oberon.USC.EDU> mlinar@poisson.usc.edu.UUCP (Mitch Mlinar) writes: > >In fact, nearly EVERY 8-bit compiler on the market (Aztec, Software >Toolworks, Manx, etc.) was based upon Small-C. The only three exceptions >I know about to date are BDS-C (which was before Small-C), Mix C (which >is just awful in 8-bit), and CZ (a Z80 assembly based compiler). > >The current versions of Small-C support 2 dimensional arrays and even >limited structures, but > - do not support passing anything other than char, int, addresses, or > pointers on the stack (no struct) > - lousy initialization > - no floating point or bit fields > - no union > - limited complexity (stuff like char *(foo[6])(i,j) will fail) > - limited library (as in almost none) > >BUT in defense of Small-C (which I highly recommend if you want to see the >SOURCE to a compiler), it is FREE and a LOT of commercial packages STOLE >it (that's what I call it), added and/or fixed a few things, and stamped >their own label on it. With the exception of Software Toolworks C/80 (only >$49), the rest are overpriced for the amount of ownership. But, Manx at >one time also included the source to the compiler for a extra $25 (above its >$80), so that might be a better way to go. Nobody includes source in IBM >that I know about (for commercial C). > >Again, if you want to learn a little about compilers, just working with >Small-C a few weeks will give you a good feel of the issues, complexity, and >headaches of writing a compiler. You might also have some fun. > >-Mitch 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 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. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Marc Wilson ARPA: ...!crash!mwilson@nosc.mil ...!crash!pnet01!pro-sol!mwilson@nosc.mil UUCP: [ cbosgd | hp-sdd!hplabs | sdcsvax | nosc ]!crash!mwilson INET: mwilson@crash.CTS.COM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mlinar@poisson.usc.edu (Mitch Mlinar) (07/22/87)
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.
kenw@arcsun.UUCP (Ken Wallewein) (07/23/87)
Has anyone heard anything about a public-domain (Small?) C++? I've head a lot of good stuff about both, the marriage would be made in heaven :-). /kenw
abp@j.cc.purdue.edu (Jeffrey J Wieland) (07/27/87)
I've been looking for a nice Z-80 C compiler. (Having suffered at the hands of Mix-C also.) Can you give any more information about CZ? Do you have any experience with ECO-C80? Thanks, Jeff Wieland abp@j.cc.purdue.edu
dg@wrs.UUCP (David Goodenough) (07/28/87)
If anyone out there has the source for Small-C I would like very much to
get a copy of it.
Thanks in advance,
--
dg@wrs.UUCP - David Goodenough
+---+
| +-+-+
+-+-+ |
+---+wsd@whuts.UUCP (DINSMORE) (07/28/87)
From: ihnp4!homxb!whuts!wsd
Received: by ihnp4.ATT.COM id AA03691; 23 Jul 87 02:19:13 CDT (Thu)
To: ihnp4!homxb!ihnp4!ptsfa!ames!elroy!cit-vax!oberon!poisson.usc.edu!mlinar
Subject: Re: Small-C
Newsgroups: comp.lang.c,comp.lang.misc
In-Reply-To: <3433@oberon.USC.EDU>
References: <3452@ihlpg.ATT.COM> <213@xrxns.UUCP>
Organization: AT&T Bell Laboratories, Whippany, NJ
Cc:
munch munch munch ....
SMALL-C most certainly does support floating point! I know
because I have the original and am currently installing V2.1 on
the C-128 using CP/M 3.0, all of which support floating point. Many
fixes and such were documented in Doctor Dobb's Journals and have
been routinely added to all original Small_C versions created by
Ron Cain. Jim Hendrix has gone so far as to upgrade the compiler
to a more useful and Unix*-like variant.
The book "Dr. Dobbs Toolbook of C" has all the source for the
V2.1 compiler, an extensive Unix*-like library with a bdos interface,
a C preprocessor, an assembler with linker and library management
utilities, and optimizers. An interesting note about the library
is that the assembler and linker will only extract those modules
specifically called out. The bdos interface is always called and the
minimum inclusion is about 5k; small price for the exceptional
capabilities of the library.
Probably the best part of all this is that you could have a very
good C compiler for the price of the book, $28. Please note that you
must have at least Ron Cain's compiler to create V2.1 and the book
gives many references to DDJ issues to do any upgrading you made need,
if any, since most versions in the PD are already upgraded.
If enough interest arises I will consider uploading all my source
for the original upgraded Ron Cain source. As for the J. Hendrix source,
if anyone has V2.0/2.1 already in electronic format I would be
interested in obtaining that. I plan to make a full CP/M 3.0 utility
disk for C including the new assembler, linker, preprocessor etc... for
free in the interest of all public domainers. If someone is/has done this
I would be greatly appreciative in obtaining/providing/working_with any
sources currently available.
Could someone please tell me how I should eventually get all of
my completed source to a public domain router so this code may be
enjoyed by all. I hate to see people paying some outrageous price for
an original PD source. My immense gratitude to Ron Cain, Jim Hendrix,
and all those who have worked so diligently on Small-C so far.
Please reply directly to whuts!mvuxi!wsd for any source
transfers via uucp.
Wayne Dinsmore AT&T Bell Labs AN-4A-118
Phone: (617)691-3653
For the serious implementation of Good/Useful PD Software.jjc@sdiris1.UUCP (Jim J. Carter) (07/28/87)
in article <4853@j.cc.purdue.edu>, abp@j.cc.purdue.edu (Jeffrey J Wieland) says: > I've been looking for a nice Z-80 C compiler. (Having suffered at the hands > of Mix-C also.) Can you give any more information about CZ? Do you have > any experience with ECO-C80? I have had some experience with ECO-C88, and quite pleased. All the reviews on ECO-C80 that I have read have been very positive. -- Jim Carter, jim@sdiris1
bill@ozdaltx.UUCP (Billy Bob) (08/02/87)
In article <277@wrs.UUCP>, dg@wrs.UUCP (David Goodenough) writes: > If anyone out there has the source for Small-C I would like very much to > get a copy of it. > > dg@wrs.UUCP - David Goodenough > You might try some of the CPM bulletin boards and see what they have. Another idea might be to post the message to comp.os.cpm and see what information you can come up with. good luck, bob Billy Bob {..ihnp4!killer!ozdaltx!bill} #!
peter@sugar.UUCP (Peter da Silva) (08/04/87)
There is a floating point library you can use, similar to the one that BDS-C uses. The only data types in Small-C are int, char, int*, and char*. The only reason it doesn't have more pointer types is that Ron Cain didn't really understand 'C' pointers when he wrote it... which only makes it more amazing. -- -- Peter da Silva `-_-' ...!seismo!soma!uhnix1!sugar!peter (I said, NO PHOTOS!)
mlinar@poisson.usc.edu (Mitch Mlinar) (08/14/87)
In article <2507@whuts.UUCP> wsd@whuts.UUCP (DINSMORE,W.S.) writes: > > SMALL-C most certainly does support floating point! I know > because I have the original and am currently installing V2.1 on > the C-128 using CP/M 3.0, all of which support floating point. Many > fixes and such were documented in Doctor Dobb's Journals and have > been routinely added to all original Small_C versions created by > Ron Cain. Jim Hendrix has gone so far as to upgrade the compiler > to a more useful and Unix*-like variant. I was both gone on vacation and had to FINALLY go check out my Small C library before answering this one: Small C definitely does NOT support floats inherently. There are four and ONLY four data types allowed: int/char/int*/char*. The floating point stuff is merely a set of function calls to implement floats. You cannot do the following in Small C: float x,y x = y * 3.0; Rather, you have to use a function call. Agreed floats are do-able, but I do NOT call this float support, just a patch job. > Probably the best part of all this is that you could have a very > good C compiler for the price of the book, $28. Please note that you Agreed. This is a very good book for someone interested in how compilers are constructed. > must have at least Ron Cain's compiler to create V2.1 and the book > gives many references to DDJ issues to do any upgrading you made need, > if any, since most versions in the PD are already upgraded. > > Wayne Dinsmore AT&T Bell Labs AN-4A-118 Source for SMALLC21 is available on SIMTEL-20 for those who can get it or on the Torrance RQP/M at (213) 320-9309. Both SIMTEL and the RQP/M have the IBM and the CP/M versions; they ARE slightly different - 8088 and 8080 object code don't get along too well :-) I am also interested in any libraries one could add to this stuff. Some of the things you mentioned, Wayne, are not around in the BBS network. Maybe you would be so kind to help this out? I have pretty much a direct link to take anything off ARPA into DOS or CP/M (and the reverse); if I can help, let me know. -Mitch