This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

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 ;)

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

Ralf




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]