Message-ID: <5124@ucbvax.ARPA>
Date: Wed, 27-Feb-85 21:14:24 EST
Article-I.D.: ucbvax.5124
Posted: Wed Feb 27 21:14:24 1985
Date-Received: Fri, 1-Mar-85 08:27:39 EST
Sender: daemon@ucbvax.ARPA
Organization: University of California at Berkeley
Lines: 48

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 Hamachi

Message-ID: <189@cadtroy.UUCP>
Date: Thu, 28-Feb-85 13:42:27 EST
Article-I.D.: cadtroy.189
Posted: Thu Feb 28 13:42:27 1985
Date-Received: Sat, 2-Mar-85 04:17:37 EST
References: <5124@ucbvax.ARPA>
Organization: CADMUS [Troy Office], Troy NY
Lines: 17

 >  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

Message-ID: <122@peora.UUCP>
Date: Sat, 2-Mar-85 16:57:39 EST
Article-I.D.: peora.122
Posted: Sat Mar  2 16:57:39 1985
Date-Received: Sat, 2-Mar-85 19:17:04 EST
References: <5124@ucbvax.ARPA> <189@cadtroy.UUCP>
Organization: Perkin-Elmer SDC, Orlando, Fl.
Lines: 38

 >>      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
					

Message-ID: <307@talcott.UUCP>
Date: Fri, 1-Mar-85 23:47:34 EST
Article-I.D.: talcott.307
Posted: Fri Mar  1 23:47:34 1985
Date-Received: Mon, 4-Mar-85 07:45:51 EST
References: <5124@ucbvax.ARPA> <189@cadtroy.UUCP>
Organization: Harvard University
Lines: 17

 >>      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.

Message-ID: <130@ISM780.UUCP>
Date: Sat, 2-Mar-85 00:52:10 EST
Article-I.D.: ISM780.130
Posted: Sat Mar  2 00:52:10 1985
Date-Received: Mon, 4-Mar-85 07:49:59 EST
Lines: 14
Nf-ID: #R:cadtroy:-18900:ISM780:25400002:000:514
Nf-From: ISM780!darryl    Mar  1 07:34:00 1985

 > 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.

Message-ID: <620@plus5.UUCP>
Date: Sun, 3-Mar-85 15:30:17 EST
Article-I.D.: plus5.620
Posted: Sun Mar  3 15:30:17 1985
Date-Received: Mon, 4-Mar-85 20:27:16 EST
References: <5124@ucbvax.ARPA> <189@cadtroy.UUCP>
Organization: Plus Five Computer Services, St. Louis
Lines: 88

 >>      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

	

Message-ID: <334@lzmi.UUCP>
Date: Mon, 4-Mar-85 21:57:17 EST
Article-I.D.: lzmi.334
Posted: Mon Mar  4 21:57:17 1985
Date-Received: Wed, 6-Mar-85 04:34:26 EST
References: <189@cadtroy.UUCP>
Organization: AT&T-IS Enhanced Network Services
Lines: 25

 >>  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.

Message-ID: <787@amdcad.UUCP>
Date: Thu, 7-Mar-85 19:25:42 EST
Article-I.D.: amdcad.787
Posted: Thu Mar  7 19:25:42 1985
Date-Received: Fri, 8-Mar-85 04:38:19 EST
References: <130@ISM780.UUCP>
Reply-To: jimb@amdcad.UUCP (Jim Budler)
Organization: AMDCAD, Sunnyvale, CA
Lines: 13
Summary: 

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