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
// platforms. For other systems, they will have to be hand tailored.
// Because the fast types are assumed to be the same as the undecorated
// it may be possible to hand tailor a more efficient
// 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk