Re: [boost] Re: stdint.h

From: Beman Dawes (beman_at_[hidden])
Date: 2000-09-26 13:30:12

At 02:02 PM 9/26/2000 +0000, Ken Hagan wrote:
 >John Maddock asked
 >>
 >> Shouldn't the int_fastX_t's be at least int sized?
 >
 >Not for x86-family machines they shouldn't. For the 386
 >and above, byte arithmetic and load/stores are as fast
 >as "int" sized ones. It would be unfair to force everyone
 >to use four times as much space when there is no speedup.
 >Considering how common the x86 is, it would be nice to
 >get this one right.
 >
 >I have a suspicion that 16-bit operations carry no penalty
 >on Pentium II and higher, although these certainly took
 >a hit on earlier Intel processors. (I think AMD chips were
 >better in this regard. I don't know about Cyrix.)
 >
 >16-bit values do carry a code _size_ penalty, since the
 >actual instructions are 1 byte longer. However, I don't
 >think either the "fast" or the "small" typedefs consider
 >this as an issue.
 >
 >On balance, I would reckon that most x86 machines around
 >today would be fairly represented by defining the "fast"
 >types the same way as the "small" ones. The only possible
 >exception is int_fast16_t, which might be 32-bit for the
 >benefit of older Intel CPUs.

Thanks, Ken.  So many once valid rules-of-thumb just don't apply to modern 
CPU's.  I've changed to the comment to:

//  These are fairly safe guesses for some 16-bit, and most 32-bit and 
64-bit
//  platforms.  For other systems, they will have to be hand tailored.
//
//  Because the fast types are assumed to be the same as the undecorated 
types,
//  it may be possible to hand tailor a more efficient 
implementation.  Such
//  an optimization may be illusionary; on the Intel x86-family 386 on, for
//  example, byte arithmetic and load/stores are as fast as "int" sized 
ones.

--Beman