Date: Fri, 7 Oct 1994 17:49:41 -0700 (PDT)
From: "Frederick W. Reimer" <fwreimer AT crl DOT com>
Subject: Re: djgpp and the 386SX
To: Chris Tate <FIXER AT FAXCSL DOT DCRT DOT NIH DOT GOV>
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu

On Wed, 5 Oct 1994, Chris Tate wrote:

> The fact that DJ's port of GCC produces "32-bit" code means that *pointers*
> are 32 bits, not necessarily integers.  It happens to be the case that
> integers are also 32 bits in size, but that's by no means a requirement
> for "32-bit compilers" in and of itself.

This is simply not true!  A TRUE 32 bit compiler is 32-bits throughout, 
instead of using 16 or 32 bits here and there.  This is a major 
complaint of users of Borland and Microsoft compilers that are touted to 
be 32-bit compilers where they don't use 32-bits for their integers.  
There is a MAJOR difference on Intel CPU where integers are only 
16-bits.  This may not be true for other CPU's, but I would hazard to 
guess that it is a standard truth.  I don't know about the MacIntosh or 
other comilers, but for Intel computers, 32-bits is definately faster.

If anyone is interested, I have Intel's programer's guide to the 386+ 
processors, and I would be glad to post the timing specs for both 16-bit 
and 32-bit instructions.

As far as Unix programs and such are concerned, what's wrong with 
assuming that the size of an int is the same as the size of a pointer?  
This is almost a given in the C programming world, or at least is should 
be.  I conceed that assuming the length of any pointer is bad programming 
practice -- and, in general, assuming the byte ordering of any "pointer" 
or "int" type is bad programming practice; but for those programs (device 
drivers / kernels) that require a low-level understanding of the 
architecure[sp] that it is running on, what else are the programs to 
assume?  There is a certain level of non-portability in every program, it 
just depends on what the program is designed to accomplish as to how 
non-portable it is.

 > 
> For example, many Macintosh compilers have 32-bit pointers, and 16-bit
> 'int's.  Or, for example, the Metrowerks C/C++ compilers (again for the
> Mac), in which an 'int' is 16 bits when compiling for the MC680x0, and
> 32 bits when compiling for the PowerPC.  The reason is efficiency; 16-bit
> operations are faster on the Motorola chips than 32-bit operations.  Thus
> the choice of a 16-bit 'int', the "natural" integer type.  For the PPC,
> the 32-bit integer is faster, so *it* is made the 'default' int.

I would suggest that the compilers for the Mac which use 16-bit ints are 
not true 32-bit compilers.  When you say that a particular compiler is 
32-bit, what do YOU assume?  Than POINTERS are 32-bits?  That's IT?  I 
assume that it uses 32-bit int's.  I could care less what type it's 
pointers are.  If it's an Intel machine, let it use far pointers or 
something, I really don't care.  But to say that a compiler is 32-bits 
when it uses 16-bit int's is streaching it a bit, if you ask me.

> I believe that 16-bit integer operations are faster on the I486 and before;
> I don't know about the Pentium.  Anybody know for sure?

Yes, they may be faster, but if you have to compute a 32-bit aritmetic 
value, what would be faster?  Two (actually more because of the 
conditional carry) instructions or just one?  I would submit that the one 
32-bit instruction is faster, and I would be willing to provide the 
instruction timmings to prove it.

> (When coding for portability, never assume that an 'int' is more than 16
> bits.  And *especially*, never assume that "int" and "void *" are the same
> size - Unix programmers are notoriously lax about this, and it causes
> major headaches when porting Unix-origin software to many non-Unix-hosted
> compilers.)

Point well take.  All proficient programmers will include the appropriate 
headers and use the definitions defined[sic] therein to write their 
code.  Yes, Unix code does have a lot to be desired, but at least I can 
compile the majority of it on my PC without chages with DJGPP.  Can you 
say that for your Mac? (just wondering)...
	

Fred Reimer

+-------------------------------------------------------------+
| The views expressed in the above are solely my own, and are |
| not necessarily the views of my employer.  Have a nice day! |
| PGP2.6 public key available via `finger fwreimer AT crl DOT com`   |
+-------------------------------------------------------------+