[patch] Add fast<N>_t types to stdint.h

[Joel Sherrill <joel@OARcorp.com>]

Ralf Corsepius wrote:
> On Thu, 2005-09-22 at 10:40 +0200, Corinna Vinschen wrote:
> 
>>Hi Ralf,
>>
>>On Sep 22 05:47, Ralf Corsepius wrote:
>>
>>>Hi,
>>>
>>>the patch below adds fastN_t support to stdint.h
>>
>>I assume this is meant as a default implementation, right?
> 
> Yes. For the moment, my objective is to fill in the gaps, I had left and
> you had pointed out, ASAP.
> 
> 
>>The reason I'm asking is that this implementation defines the size
>>of the fast type to be the same as the type with the same width.
> 
> Yes, ...
> 
> 
>>  But
>>that's obviously not always the fast type.
> 
> ... right, the question is: Is there any fast type for an architecture,
> and if yes, which ?
> 
> 
>>  On 32 bit CPUs the
>>int_fast16_t type is mostly 32 bit, on 64 bit CPUs it's 64 bit.
>>But that's the problem, the implementation of fast types requires
>>a bit of knowledge about the CPU.
> 
> 
> Well, I think, actually it requires much more. It requires detailed
> knowledge of the architecture, on a compiler's optimization and on
> architecture variants.
> 
> E.g. on some targets, access to 16bit types is equally fast as 32bit
> access (one cpu cycle), but wastes less memory. So, in an ideal world
> "fast<N>_t" would either always be 16bit or should switch between 32bit
> and 16bit types depending on optimization options (-Os vs. -O<N>).

And gcc is far from perfect in setting cpp predefines that indicate 
command line switches.  I know Ralf and I have submitted multiple small
patches to correct even knowing if you have hardware or software FP.

For this to work, there would have to be a gc predefine to indicate
"size over speed".

> However there also is the case of 16bit access being faster (one cpu
> cycle) than 32bit access (2 cpu cycles). IIRC, the sh1 and sh2s are such
> kind of beasts). 
> 
> Worse, on some architectures, esp. 16bit architectures, using a fixed
> default of 32bit for fast<N>_t would be hardly possible, because some
> cpus can't access 32bit directly.
> 
> 
>>Wouldn't it make sense to implement something like a __WORDSIZE
>>macro in newlib, using some new header file inside libc/machine/*,
>>for instance bits.h?
> 
> Yes, this would be an alternative, except that I consider this approach
> to be close to be impossible to maintain.
> 
> Another alternative would be the approach FreeBSD applies: 
> FreeBSD has per-architecture machine/_types.h, which carry definitions
> of various __XXX<N>_t types. They include their machine/_types.h into
> sys/types.h and stdint.h to ensure consistency on fixed-size types.
> 
> This then could be used to override the "default implementation" in
> sys/types.h rsp. stdint.h. 
> 
> However, ... even FreeBSD resorts to mapping int_fast<N>_t types to
> int<N>_t for the sake of simplicity ;)

This at least gives a mechanism to do architecture specific tweaking.

>>OTOH, maybe it's already enough to use the INT_MAX definition which
>>falls out of sys/config.h.
> 
> Modern GCCs internally define __INT_MAX__ and __LONG_MAX__, so there
> shouldn't be any need to dig into other headers.
> 
> But the same comment as above also applies here, for instance on the
> h8300 (-ms):
> #define __INT_MAX__ 32767
> # 1 "<built-in>"
> #define __LONG_MAX__ 2147483647L
> # 1 "<built-in>"
> #define __LONG_LONG_MAX__ 9223372036854775807LL
> # 1 "<built-in>"
> #define __CHAR_BIT__ 8
> # 1 "<built-in>"
> #define __INTMAX_MAX__ 9223372036854775807LL
> 
> I.e. INT_MAX here corresponds to 16bit types.
> 
> 
>>  The default integer type is usually
>>equivalent to the native word type and therefore also the fast type...
> 
> True, but cf. above, "int"s can be less than 32bit, and "32bit" can be
> expensive.

Right.  Fast 32-bit on the h8300 is a contradiction. :)

--joel