Lattice versus CI86

[guido at boring.UUCP]

I have long tried to be silent about this, but as it seems that Lattice
gets more flames, and CI86 more praise, than I find just, I must speak up.
This is a biased note: I try to show some of Lattice's good points and
all CI86's weak points.

1) Lattice allows you tou separately choose whether you want a big program
   space or a big data space, or both.  In CI86, it's all big or all small.
   Since big program space costs little extra (only function calls are
   somewhat slower) but big data space reduces running speed by about 30
   per cent (all pointer handling is far slower), it is nice to have a
   small data space but a large program space, if your problem needs this.

2) Most C compilers (including the vax ones) have trouble in redefining
   typedef'ed identifiers.  But CI86 is the worst I've seen: it even thinks
   an identifier is a typedef when used in a structure element context,
   e.g. typedef int foobar; struct { int foobar; }; (Yes this is ugly,
   but it's according to K&R: typedef identifiers are in the same class
   as ordinary identifiers, while structure elements and tags are in another
   class.)

3) Regarding porting code originating from UNIX: it is a good practice to
   put the same identifier on #else and #endif constructs as on the corres-
   ponding #ifdef:
	#ifdef LATTICE
		... /* Many lines of code, including nested #ifdefs */
	#endif LATTICE
   CI86 gives an error message if there is something after #else; worse,
   it treats the remainder of an #endif line as program text!

4) Several nasty things showing CI86 didn't implement K&R as well as you
   thought:
   - Doesn't allow trailing comma in initializer (e.g. int x[]= {1, 2, 3,};).
   - Balks at complicated casts such as (foobar (*)())
   - Doesn't allow /* inside strings!!!!!! (Yes, the manual warns you...)
   - Doesn't implement ++ and -- for float/double
   - Doesn't support setbuf, and (consequently) stdio.h doesn't declare BUFSIZ.

5) CI86 doesn't allow casts in global initializers.  (This is not in K&R but
   it was certainly a slip of the pen that it wasn't, see old net.lang.c
   discussions; anyway, it hampers - again - porting code from UNIX.)

6) Loader problems: CI86 puts a reference to everything you declared as
   external in the object file, whether you actually used it or not.
   This caused me a great pain when I had a large header file declaring all
   functions of a certain module (but that weren't all used nor defined in
   the same file), because the loader couldn't handle that many externals from
   one file.  (It may also mean that you always load all library routines
   that are declared in a header file but not used, but this depends on
   details of the loader.)

7) Lattice by default compiles code to check for stack overflow (it can
   be turned off); CI86 has no such check, not even optional.

I won't speak about more subjective problems, such as CI86 generating larger
code (I didn't really take a close look) or the quality of the manual --
I certainly enjoyed Lattice's more than CI86's.

A final word: there may be other brands of compilers that weren't available
when I purchased Lattice and CI86 (DeSmet was useless because it didn't
support large memory models; I suppose it still doesn't).  I used Lattice
version 2.04 and CI86 version 2.10, purchased at about the same time (2Q84).

	Guido van Rossum, "Stamp Out BASIC" Committee, CWI, Amsterdam
	guido at mcvax.UUCP