guido@boring.UUCP (12/29/84)
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@mcvax.UUCPken@rochester.UUCP (Ken Yap) (12/30/84)
> - Doesn't implement ++ and -- for float/double
While ++ and -- on float/double suggest they mean the same thing as
{+-}= 1.0, some compilers object to this, with some justification.
This is a non-portable construct. {+-}= 1.0 is clearer to read anyway.
--
Ken Yap
UUCP: (..!{allegra, decvax, seismo}!rochester!ken) ARPA: ken@rochester.arpa
USnail: Dept. of Comp. Sci., U. of Rochester, NY 14627.km@cadre.UUCP (01/02/85)
Your comments are well taken. C86 certainly has its share of faults. My major point was that I had an easier time living with them than using the early version of Lattice, and that access to the library sources was helpful. My own two major gripes with C86 are the "extern" problem, which does NOT exist with Lattice when the "-x" flag is used, and the inability to use common member names in different structures with differing offsets, which also does not exist with Lattice. I have not had access to the "large" version of Lattice and cannot comment on the relative speed sacrifices with (uugh) "long" 8086 pointers. I have noticed a pronounced speed degradation with the long pointers in C86, particularly in code containing a lot of arrays. In summary, I did not mean to unilaterally "praise" C86 but to simply comment on my own experience, admittedly with compilers of quite different currentness. I would very much like to see the DeSmet compiler, and others.
henry@utzoo.UUCP (Henry Spencer) (01/02/85)
> > - Doesn't implement ++ and -- for float/double > > While ++ and -- on float/double suggest they mean the same thing as > {+-}= 1.0, some compilers object to this, with some justification. > This is a non-portable construct. {+-}= 1.0 is clearer to read anyway. It's more than just suggested. K&R, section 7.2, says in so many words that "++x" is equivalent to "x+=1". There is nothing ill-defined or implementation-dependent about the semantics of the latter, even when applied to floating-point. "--x", "x++", and "x--" are defined with reference to "++x". A compiler which does not implement the ++ and -- operators on floating-point operands is wrong, period. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry