Mail Archives: djgpp/1994/10/08/01:04:17
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` |
+-------------------------------------------------------------+
- Raw text -