wagner (02/01/83)
(this appeared originally in net.micro.68K, but is copied here
since it has more general applicability. The two versions are
almost identical, except for this note; it isnt worth reading
both. Sorry)
I was looking at 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