Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!caip!nike!ucbcad!ucbvax!PAVEPAWS.BERKELEY.EDU!dillon
From: dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon)
Newsgroups: net.micro.amiga
Subject: re: C Philosophy
Message-ID: <8606161842.AA20107@pavepaws>
Date: Mon, 16-Jun-86 14:42:07 EDT
Article-I.D.: pavepaws.8606161842.AA20107
Posted: Mon Jun 16 14:42:07 1986
Date-Received: Wed, 18-Jun-86 04:02:42 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: University of California at Berkeley
Lines: 61


>George Robbins:
>
>	The Berkeley in you is showing.  If you have a machine that has
>a 16 bit processor, runs faster with 16 bit operands and generates
>smaller code, it is just plain lazy to say 'looks like 32 bits to me'.
>
>	As you pointed out, assuming that pointers and integers are
>the same length cause no end of portability problems.  The people who
>decided that an int on a VAX should be 32 bits did the micro-world a
>big disfavor, and the doubled it with a 'nothing smaller than a VAX
>is worth worrying about...' attitude.
>
>	Call a pointer a pointer, and an integer an integer (oops,
>I mean a short)...

	No, the practicality in me is showing.  I don't have a machine that
has a 16 bit processor (IBM's don't count; all of INTEL's processors are
screwed up anyway).  I consider the VAX and 68000 to be 32 bit machines, even
though they have 16-bit external data paths.  The registers are 32 bit.
With a good compiler, you don't really need to worry about the longer 
access time for long words over words.. it's trivial compared to
other possible improvments in code generation.  Additionaly, when 32 bit 
things are in 32 bit registers, the generated code is not any slower.  The
only real loose with 32 bit integers is with multiplication.

	Some people are paranoid about all of this, and NEVER use 'ints'...
They use either shorts or longs (which have definate minimum bit lengths).

	There are many cases where I have two int's and want to multiply them
together.  With a 16 bit compiler, I must force these int's to long's before
multiplying or my result will be truncated to 16 bits.... makes for messy
code.  One can say that I'm lazy in the fact that I do not want to deal with
or worry about having to cast my integers to longs (or vise versa).  This
whole deal about pointers is actually quite trivial compared to other reasons.
For instance, the 16 bit compiler people have to cast some passed values to 
long for function calls such as Seek(), or extern more than a reasonable
number of functions which return 'longs'.  32767 is simply not a large 
enough number for me to use as a default.

	there is a question of technology.   Do you really think
techonology is going to stick to 16 bit processors?  It's obvious to me, at
least, that it isn't.  My opinion is that today's 32 bit processors will 
become the 'standard' until the next big leap occurs some decades in the
future.  You can then ask 'what will happen to the 16 bit processors' or
'why do 8 bit processors still exist'.  The answer to that is simple.

	Take a look at your microwave.  Yup, you got it.  The small-control
-systems side of science is inheritting the 8/16 bit processor.  The handset
on your mobile telephone probably has a one chip 8 bit processor in it.
Your car's ignition system, your telephone, modem, 10 function clock-radio.
these are all items where the 8 bit processor fits the industry's needs to a
T.  There is no need for incredible speed, or major calculations, but there
is a need to conserve space and power.

	The reason I don't care to make my software (immediately) transportable
to these other processors is simply that my software wouldn't apply to these
other processors.  In fact, anything anybody writes for the latter would be
completely custom and non-portable anyway, would it not?

						-Matt