This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [patch] Add fast<N>_t types to stdint.h
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.