hamachi@ucbkim (02/28/85)
From: hamachi@ucbkim (Gordon Hamachi)
Additional information concerning my C compiler evaluation at the
MacWorld Expo:
I sent my benchmark results to Bill Duvall at Consulair Corp. and he
phoned me right back with some comments:
1. After the show he added register variables to his compiler. With
register variables the sieve program runs in 3.6 seconds. Is that
right? I may have misunderstood him.
2. Bill points out that the Megamax compiler uses 16 bit integers, while
his compiler uses 32 bit integers. When the Consulair compiler used
16 bit integers in the sieve program the run time with his old compiler
was 6.3 seconds.
This is an excellent point. I neglected to notice whether the other
compilers used 16 or 32-bit integers. Someone told me that the C
standard stipulates that an integer's worth of bits must be able
to span the entire address space. I don't know about this. Can
someone comment?
3. Bill doesn't think that the size of binaries for small programs is
a significant test of a compiler. With small programs it doesn't
matter that much if some extra stuff gets loaded, while with larger
programs almost everything ends up getting used.
I personally have mixed feelings about this. If you're limited to
400K floppy disks, you probably don't want many useless bits on them.
Bill says that he's planning a smarter linker that only links in what's
needed. The anticipated release date is a month after his April
release (the one that will include floating point).
4. Bill says that a better benchmark might have lots of function calls
in it. His compiler has paid special attention to making calls go
fast, since he believes that real sized programs make lots of them.
The sieve benchmark doesn't let him show off that feature.
I'd have run the famous fibonacci benchmark if I'd had the time. Many
of the compiler vendor booths were so packed with people that I couldn't
tie up their machines long enough to do everything I'd wanted.
Watch this space for additional details. Consulair Corp. is lending me
a copy of their compiler so I can do additional evaluation. I'll post
the results as soon as they are available.
--Gordon Hamachihako@ur-univax.UUCP (02/28/85)
One comment with regard to the C compilers is that, correct me if I am wrong, only Megamax supports float at this point. This is definitely a must for me, apart from being standard K&R. So I bought Megamax. Megamac says their sieve using registers runs in 4.2sec. Hanne UofRj ..!seismo!rochester!ur-univax!hako
schoff@cadtroy.UUCP (Martin Lee Schoffstall) (02/28/85)
> 2. Bill points out that the Megamax compiler uses 16 bit integers, while > his compiler uses 32 bit integers. When the Consulair compiler used > 16 bit integers in the sieve program the run time with his old compiler > was 6.3 seconds. > > This is an excellent point. I neglected to notice whether the other > compilers used 16 or 32-bit integers. Someone told me that the C > standard stipulates that an integer's worth of bits must be able > to span the entire address space. I don't know about this. Can > someone comment? Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T 68010 UNIX distribution C compiler believes that ints are 16bits. marty schoff@cadmus.ARPA {wanginst,seismo}!ucadmus!schoff
tmb@talcott.UUCP (Thomas M. Breuel) (03/02/85)
> > This is an excellent point. I neglected to notice whether the other > > compilers used 16 or 32-bit integers. Someone told me that the C > > standard stipulates that an integer's worth of bits must be able > > to span the entire address space. I don't know about this. Can > > someone comment? > > Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T > 68010 UNIX distribution C compiler believes that ints are 16bits. No 'C' standard guarantees that sizeof(int)==sizeof(char *). A 'C' compiler for which this is true will allow you to port programs to it more easily, though, since many, many programs in the real world make just that assumption. For more info see net.lang.c, where there was a lot of discussion about this point. Thomas.
darryl@ISM780.UUCP (03/02/85)
>Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T >68010 UNIX distribution C compiler believes that ints are 16bits. > >marty >schoff@cadmus.ARPA >{wanginst,seismo}!ucadmus!schoff I don't have the documentation here right now, but I believe that the AT&T Sys V PCC2 cross compiler for the 68000 can be built with 16 or 32 bit ints, depending on how you like it. --Darryl Richman, INTERACTIVE Systems Inc. ...!cca!ima!ism780!darryl The views expressed above are my opinions only.
jer@peora.UUCP (J. Eric Roskos) (03/03/85)
>> Someone told me that the C >> standard stipulates that an integer's worth of bits must be able >> to span the entire address space. > > Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T > 68010 UNIX distribution C compiler believes that ints are 16bits. > A very lengthy, and ultimately unfruitful, discussion along these lines occurred in the ARPA UNIX-WIZARDS conference last Spring. The underlying problem is that many programmers earnestly want to write portable code, yet vehemently believe that the C "standard" should support various programming tricks they have discovered which just as surely prevent portable code from ever being written. What's at issue here is that the C language will allow you to assign pointers to integers. The K&R language standard (which is in Appendix A of the book) states "Certain conversions involving pointers are permitted but have implementation-dependent aspects. ... A pointer may be converted to any of the integral types large enough to hold it. Whether an int or long is required is machine dependent. The mapping function is also machine dependent, but is intended to be unsurprising to those who know the addressing structure of the machine." The essence of this statement is that assigning pointers to integers is "implementation dependent," i.e., if you do it, the resulting programs will be nonportable; and, although the standard uses the word "machine," it is far wiser to read "compiler" dependent instead. The moral of this story is this. If you are writing programs for yourself, or for a particular compiler, you can do whatever you want; but if you are writing portable programs, you should avoid such features altogether. Doing so prevents C from losing its expressiveness and flexibility, while avoiding surprises when porting programs. Eric Roskos Perkin-Elmer Corp. SDC <jer@peora.UUCP>
eric@plus5.UUCP (Eric W. Kiebler) (03/03/85)
> > This is an excellent point. I neglected to notice whether the other > > compilers used 16 or 32-bit integers. Someone told me that the C > > standard stipulates that an integer's worth of bits must be able > > to span the entire address space. I don't know about this. Can > > someone comment? > > Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T > 68010 UNIX distribution C compiler believes that ints are 16bits. > > marty > schoff@cadmus.ARPA > {wanginst,seismo}!ucadmus!schoff Which standard? IEEE/usr/group standard? So what if AT&T believes ints are 16 bits? White Book page 102, section 5.6, says "5.6 Pointers are not Integers". Page 34 says: int an integer, typically reflecting the natural size of integers on the host machine. This would appear to be 16 bits, eh? That is, of course, if you consider MOVE.L unnatural... Now, the C Reference Manual, section 4, states "Types CHAR and INT of all sizes will collectively be called INTEGRAL TYPES". Then, section 14.4 states "An object of integral type may be explicitly converted to a pointer. The mapping always carries an integer converted from a pointer back to the same pointer, but is otherwise implementation independent". So, if we consider a long int at 32 bits to be an integral type, then 16 bit ints are swell. Now, section 6.4 states "Two pointers to objects of the same type may be subtracted; in this case the result is converted to an integer as specified in the discussion of the subtraction operator." What does this all mean? If the result of pointer subtraction is 16 bits, the number of objects in an array is limited to 64K. This, as it were, sucks. The only guarantee for longs is that they aren't shorter than shorts, so they may in fact be 16 bits. So, a resolution of the problem for the 68K is to make the result of pointer subtraction an integral type as opposed to an integer, and to make ints 16 bits, chars 8 bits, and longs 32 bits. That way, compiler writers could still follow the standard and we could still access the entire address space of the machine using pointer expressions. If you don't think that people should use arrays that big then your mom was right, you're never going to amount to anything, and you smell bad, too :-). On the other hand, making the result of pointer subtraction a long (which is what would be required) makes passing the result of pointer subtraction non-backward-compatible with existing programs. A long does not get converted to an int when being passed as an actual parameter, so people who code things like ... int a[100000], *pia, *pib; pia = a+10; pib=a+99999; ... plop(pib-pia); ... plop(dif) int dif; {...} are going to be very disappointed. I am sure there are other examples of this kind of problem. I like 32 bit ints, myself; I don't want to fix all those old programs, and I want to access big arrays. I will live with the speed difference. I don't have my copy of the proposed /usr/group standard -- did they fix this somehow? eric PS. I know this was flying around in net.unix* a while ago, but I didn't care back then because I was using a VAX :-). -- ..!ihnp4!wucs!plus5!eric ..!ihnp4!plus5!eric (314) 725-9492
psc@lzmi.UUCP (Paul S. R. Chisholm) (03/05/85)
>> 2. Bill points out that the Megamax compiler uses 16 bit integers, while >> his compiler uses 32 bit integers. When the Consulair compiler used >> 16 bit integers in the sieve program the run time with his old compiler >> was 6.3 seconds. > >Hmmm, the 68000 inside the MAC has a 24bit address space. A AT&T >68010 UNIX distribution C compiler believes that ints are 16bits. The Gosphel According to Richie states "'Plain' integers have the natural size suggested by the host machine architechture; the other sizes are provided to meet special needs. AT&T has two 68000 compilers: one generates 16 bit ints, the other, 32 bit. A friend (and former supervisor) of mine chose the former for his boss's extremely non-trivial 68000 based project. The 16 bit machine produces code that is 10% smaller and 10% faster (my failing memory may be underexaggerating). Aside from being *very* careful not to store a pointer in an int, everything went fine. (BTW, normal lint will not catch this error; it has PDP-11isms hardwired into it. Oddly enough, my first assignement for this guy was to fix lint so it understood VAXes; helped him a lot when he went to the 68000.) -- -Paul S. R. Chisholm ...!{pegasus,cbosgd}!lzmi!psc The above opinions are my own, ...!{hocsj,ihnp4}!lznv!psc not necessarily anyone else's.
jss@sjuvax.UUCP (J. Shapiro) (03/05/85)
[Pacman's revenge...] Manx (Aztec) also supports float.... Jon Shapiro
jimb@amdcad.UUCP (Jim Budler) (03/08/85)
The question of 16 and 32 bit ints is addressed in Consulair C
with a compil time switch. The manual states that 16 bit ints
is implied by the architecture of the 68000. Use of the 16 bit ints
will generate smaller, faster code, but more care must be taken to insure
that word boundaries are respected.
--
Jim Budler
Advanced Micro Devices, Inc.
(408) 982-6547
UUCPnet: {ucbvax,decwrl,ihnp4,allegra,intelca}!amd!jimb
Compuserve: 72415,1200
The Source: STW265