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

[Corinna Vinschen]

On Sep 22 11:24, Ralf Corsepius wrote:
> On Thu, 2005-09-22 at 10:40 +0200, Corinna Vinschen wrote:
> >   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.
> [...]
> 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>).

I don't think so.  The fast type is pretty much fixed by the way the
CPU works.  The space vs. speed optimization doesn't influence this.
Consider the least<N> type being the right type if space is important,
the fast<N> type being the right type if speed is important.

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

Sure, but that apparently decides pretty quickly about the fast16 type
on these architectures, doesn't it?

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

Well, that's basically the same as my suggestion, just another name
of the file.  I didn't mean to imply that the name bits.h is a must.

> However, ... even FreeBSD resorts to mapping int_fast<N>_t types to
> int<N>_t for the sake of simplicity ;)

Ok, but other OSes don't, for instance GNU/Linux (or, FWIW, Cygwin).

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

Yep, I agree.

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

I don't understand the conclusion here.  Are we in violent agreement,
perhaps?  If an architecture has a non-sensical (well) definition of
__INT_MAX__, then the fast (and maybe even the least) definitions should
be overridden in, say, machine/_types.h or in stdint.h.  But in most
cases this would be a no-brainer, wouldn't it?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat, Inc.