Re: Potential (small) ABI switch

[Eduardo Horvath <eeh%NetBSD.org@localhost>]

On Mon, 18 Aug 2014, Martin Husemann wrote:

> Folks,
> 
> we are currently trying to synchronize the idea the compiler has about
> the various int types and the declarations in the NetBSD headers.
> 
> This mainly boils down to minor differences in the {u}int_fastN_t definitions.
> 
> There is no obvious single wrong or right way for sparc64 (IMHO), and
> a few days ago we "accidently" switched ABI for these types by moving from
> the old header definitions to new ones based on the compiler defaults.
> A few other architectures will soon be fixed by adapting the compiler's
> idea about these types to the old NetBSD headers, but I am leaning toward
> not following this move with sparc64.
> 
> As of netbsd-6 sparc64 used:
> 
> int_fast8_t           long int (64 bit)
> uint_fast8_t          unsigned char (8 bit)
> int_fast16_t          long int (64 bit)
> uint_fast16_t         unsigned short int (16 bit)
> int_fast32_t          long int (64 bit)
> uint_fast32_t         unsigned int (32 bit)
> int_fast64_t          long int (64 bit)
> uint_fast64_t         unsigned long int (64 bit)
> 
> As far as I can tell Solaris always used the same types as without "fast",
> e.g. uint_fast8_t = uint8_t, int_fast8_t = int8_t, ...
> 
> Everyone else uses a much simpler sheme:
> 
> int_fast{8,16,32}_t   int (32 bit)
> uint_fast{8,16,32}_t  unsigned int (32 bit)
> int_fast64_t          long int (64 bit)
> uint_fast64_t         unsigned long int (64 bit)
> 
> ... and this is what we have now in -current as well. IMHO it can stay this
> way. While the old NetBSD state is arguable from the instruction set POV,
> it is not a clear winner speed wise and the C standard leaves quite a bit
> of rope.
> 
> Strictly speaking this is an ABI breakage/change, worse with C++ - and in
> general this is something we don't do in NetBSD, so this needs carefull
> thoughts.

So... (I probably should have editted the preceeding, but I'm lazy) 
according to the US I documentation, load operations take an extra cycle 
to sign-extend signed integers.  I don't know off hand about other 
processors, but I'd expect the US II has the same issue.

Hence the original design decision that all signed values are 64-bits and 
unsigned are whatever.  Under normal circumstances I'd say it doesn't 
really matter.  However, since I'm only able to fill load delay slots 
about a third of the time when I write assembly by hand, unless the 
compiler is really good at filling all the extra load delay slots, that's 
a lot of potential CPU cycles you could be shaving off.

Eduardo