🚀 go-pugleaf

In article <498@iscuva.UUCP>, jimc@iscuva.UUCP (Jim Cathey) writes:
> Certainly speed!  For non-68020's, interesting longword instructions
> generally take longer (and are sometimes larger) than the equivalent word
> instructions.  What bothers me about C is not that, say, an int is 32
> bits and a short is 16 bits since I can declare variables either way I
> want, but that ALL EXPRESSIONS AND STACK PARAMETERS ARE COERCED TO BE
> INTS!  

Nope.  Simply not true for expressions.

> Thus, for a 32-bit int compiler any multiply/divide MUST use a
> subroutine (including array subscripting operations), every simple
> int(char)- taking subroutine takes longer to call, etc...  

I can't speak to the accuracy of that claim for all compilers, but
clearly it is possible to do 16-bit arithmetic in MPW C.  I was
upset at having to link a library (not speed) for one example in my
book, so I coerced it to 16-bit arithmetic with

	buff[0] = '0' + (ashort / (short) 10);
	buff[1] = '0' + (ashort % (short) 10);

> I am also
> bothered about the coersion of float to double, but since I never use
> floating point I'm not bothered too much.

float to double is, of course, standard K&R, although the ANSI committee
seems inclined to modify it for speed freaks.

> According to K&R, an int is supposed to be the most natural sized operation
> for any given machine, which, face it, for a 68000/68010 is 16 bits.  

As Johan Strandberg points out, you have many problems with sizeof(int) !=
sizeof(char *).  This was also discovered by people moving code around
like news.

> Personally I am fond of compilers that have switches that allow you to 
> generate code either way suits your needs (and/or fancy).

This is the best possible solution, as long as you correctly handle
the Macintosh interfaces with either setting.
-- 
	Joel West
	{ucbvax,ihnp4}!sdcsvax!jww	(ihnp4!gould9!joel once I fix news)
	jww@sdcsvax.ucsd.edu	if you must