dillon@CORY.BERKELEY.EDU.UUCP (04/02/87)
>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. For the most part, 32 bit arithmatic isn't any longer in terms of instruction size. For the 68000, 32 bit arithmatic usually takes 2 extra clocks over 16 bit arithmatic. And, of course, expression calculation isn't all the generated C code must do. As far as speed goes, unless you are doing an incredible amount of number crunching, it's difficult to notice the slowdown. Even more important than the question of slowdown using 32 bit ints is the question of compiler optimization. For instance, if a compiler uses register relative instead of absolute addressing for all it's global references, and uses PC relative instead of absolute addressing for all it's subroutine calls, you save both time AND space... much more than simply using a 16 bit operation size. > 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... Most compilers optimize short/short and short*short expressions. >> 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. Even though a 68000 only has a 16 bit databus, I don't think of it as a 16 bit machine considering that all data and address registers are 32 bit. The only non-32-bit operations supported are multiply and divide. The problem with sizeof(int) != sizeof(char *) is not really due to 'int' delcarations per say. Instead, many programmers simply do not bother to specify any return type at all for declared functions (and they thus default to int), and WORSE, many programmers do not properly extern functions which return pointers in other modules. If you don't specify a function from another module in an extern, it is assumed to be int. These are things that are difficult to catch. LINT, of course, will catch most problems, but LINT has problems of its own which causes many programmers not to use it. Many of the *really* good programmers have a problem... they tend to forget to extern functions from other modules that return pointers rather than ints. Many more programmers have another problem... they tend to assign different types of pointers to each other. The latter doesn't cause any problems on most machines (except for IBM's), but the former really messes up a program compiled on machines where sizeof(int) != sizeof(char *). -Matt