From: utzoo!utcsrgv!utcsstat!wagner
Newsgroups: net.micro.68k
Title: Re: 68K software standardization with small-C
Article-I.D.: utcsstat.512
Posted: Tue Feb  1 13:48:44 1983
Received: Tue Feb  1 17:27:45 1983
References: tektronix.899

I dont have a 68K, so I dont really enter into this discussion
directly, but I do have a 6809, and some other things, and I
was looking to small C v2 to solve some problems for me as a
standard amongst my various machines and amongst my various
friends machines in the neighbourhood.  I am trying now to
get it up on UNIXtm as a first step to porting it to my
6809, and trying is the right word.  The language it is
written in is close enough to C to fool the unaided eye, but
it sure dont fool the compilers.  I dont mind a subset C
compiler, but I mind a compiler that accepts syntax outside
the language (not extentions, just bugs).  The compiler itself
misuses stdio so badly that it wont compile with UNIX stdio.
Some examples:
1) the files are all declared int instead of FILE *.
   The solution appears to be to change them all to FILE *,
   and then, in the header files,
#ifndef UNIX
#define FILE int
#endif
   and then change his support routines to expect *int instead
   of int.  Eventually, of course, he should be passing more
   info than just an int around if he wants to do things right,
   but at least this gives him the option of leaving the shape 
   of a FILE "variable" to the stdio.h file.
2) He tries in several places to read from stderr.  Needless to
   say, UNIXtm isnt amused.
3) He is forever assigning pointers to ints and back again.
   This happens to work on machines where pointers and ints
   are the same size (11/70, 8080+Z80) but will it work on
   new 16bit machines?  Will it keep working?  Memories are 
   getting cheaper, and already there are machines whose
   address space is bigger than the intuitive size of an int
   on that machine.
4) He #ifdefs himself to death, making the code very hard to
   read in sections.
5) He confuses int op[16]  (an array of 16 ints) with
           int (*op[16])() (an array of 16 pointers to functions returning int).
6) His include syntax is different from standard C for no 
   obvious reason.
7) From the code it would appear that #includes cannot be
   nested (I havent tried this)
	
	I now have the thing working, sort of, under UNIX.
At least it stopped giving me core dumps if I stick to the
straight and narrow and dont give it bad file names.
It might be possible to make it work sensibly under UNIX
with a lot more work.  It isnt obvious that it would then
compile itself any more.  I am trying to isolate UNIX changes
in ifdef UNIX sections, but it isnt always obvious what it will
and wont compile itself.
	But, and this is a big but, it seems to have the 
8080 architecture hard-wired into it, and ripping that out
will be more work again.  I must say, to its credit, that it
is a great improvement over release 1 of the compiler, which
was even more stuck in the 8080 grove.
	Fixing all these things up might be more work than
writing a proper subset compiler.  Does anyone else working
on this compiler have any thoughts on the subject?

Michael Wagner, UTCS

P.S. Perhaps I should have put this submission into net.micro
     rather than just the 68K part.  Forgive me.  I will copy
     it into the right place; it just seemed initially better
     to follow up the discussion on standardization on Smallc.