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

[Ralf Corsepius]

On Thu, 2005-09-22 at 08:17 -0500, Joel Sherrill  wrote:
> Ralf Corsepius wrote:
> > On Thu, 2005-09-22 at 10:40 +0200, Corinna Vinschen wrote:
> > 

> 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.
Right.

> For this to work, there would have to be a gc predefine to indicate
> "size over speed".
To some extend it exists:

-Os causes cpp to add:
# 1 "<built-in>"
#define __OPTIMIZE_SIZE__ 1


However this isn't the issue I am referring to.

My point is: INT_MAX (rsp. __INT_MAX__) only is a very weak indication
for which type to consider a "sufficiently large fast int" (Remember
int_fast<N>_t types are least<N> types).

E.g. IIRC, on sh1's 16bit int access often is faster than 32bit access.
I.e. for the sh1's a
"typedef int_fast16_t int_least16_t" 

is faster (and less memory consuming) than a
"typedef int_fast16_t int_least32_t"

which might be the preferred form for most 32bit architectures.

> > 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.
Implementing the mechanism is isn't "that difficult". We'd have to
decide upon whether to distinguish upon arch or os.

Given the current implementation and RTEMS rsp. Cygwin's history, I'd
prefer using the os, so a "natural implementation" would be:
libc/include/stdint.h:
..
#include <sys/_stdint.h>
#ifndef __int_fast16_t_defined
typedef __int_least16_t __int_fast16_t;
#endif

typedef __int_fast16_t int_fast16_t;
...

libc/include/sys/_stdint.h:
/* empty file */

libc/sys/rtems/include/sys/_stdint.h:
#include <machine/_stdint.h>

libc/sys/cygwin/include/sys/_stdint.h:
/* hardcoded cygwin preferences */

etc. etc.

However, implementing the contents is a nightmare.

Given this background and current newlib's state, getting correct values
at all would be a real breakthrough. - Optimization is secondary, ATM.

> >>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. :)

Exactly.

Here the point is: Does this target support a specific int<N>_t type at
all and are we able to find one we can use?

The logic implemented here is: If we are able to find a type to support
int<N>_t, also map it to int_fast<N>_t so we can compile.

However, I think I understand Corinna's perspective: Cygwin has one
single target architecture, they have an "optimal" solution, perfectly
fitting their needs.

We (RTEMS) have ca. 10 different architectures to server, and are lucky
to get any solution at all without drowning in defines, but are in a
position that we can consider optimization for selected cpu-variants.

The generic target users (Shaun etc.) however, are in a similar, however
even more desparate position as RTEMS is: ATM, they can't even build
large portions of GCC without massive degradations and deformations.

Ralf