There's a lot to be discussed on the issue. A few quick
thoughts:
* 32-bit integers are a sweet spot for CPU architectures.
There's rarely a provision for 16- or 8-bit operations; the
action is at 32- or 64-bit.
Speed can be still optimized by the compiler, behind the scenes.
The approach does not asks the compiler to promote everything to
widest-integral, but to do the job "as if". Currently, the choice
of int-C as the fastest-integral instead of widest-integral move
the burden from the compiler to the user.
* Then, although most 64-bit operations are as fast as 32-bit
ones, transporting operands takes twice as much internal bus
real estate and sometimes twice as much core real estate (i.e.
there are units that do either two 32-bit ops or one 64-bit op).
* The whole reserving a bit and halving the range means extra
costs of operating with a basic type.
Yes, there is a cost. But, as always, there is a balance between
advantages and drawbacks. What is favourable? Simplicity of
promotion or a supplimentary bit?
Besides, at the end of the day, a half-approach would be to have
a widest-signed-integral and a widest-unsigned-integral type and
only play with those two.
Eles
