My experience with Linux/GCC

[hgm]

Indeed, that was the idea. Just write

Code: Select all

s.i = s1.i + s2.i;

The sign bit of one would contaminate the other, of course, and without making an assumption on the edianness of the hardware you don't know which is the contaminated one. But perhaps you don't care. I usually store some flag bits in the low bits of score tables (like null-move enable flags in the material table). The provide a bit of noise to the score, but who cares?

I once tried replacing Stockfish's Score type with a struct that used two 16-bit fields, and got identical benchmark results. The result surprised me at the time. (I had a pre-conceived notion that the compiler would generate inefficient code for loading and storing bitfields.)

A good optimizer should recognize if your bit-field is an addressible unit, like (x>>8 & 0xFF) is just the second-lowest byte, and could be fetched through a MOVB or MOVSX instruction. so the point is not to make it more efficient, but to make it more portable. And perhaps even optimally efficient without such a high optimization level. When you define 4 byte field within the integer, even the most stupid compiler would use MOVB when you access one of those, and interpret the sign bit properly.

[Daniel Shawul]

I use exactly that except the union is annonymous so that I don't have to do
move.s.mg_score... Some linux compilers complain about it though.
Anyway, how much do you gain by doing bit twidling ?

[UncombedCoconut]

GCC with -O2 setting optimizes very aggressively. In most cases where it makes a potentially 'unsafe' assumption it gives at least a warning. I had to rewrite some code pieces due to pointer-aliasing but that was pretty straightforward.

My favorite example of GCC's aggression involves enum types: it would assume their range was limited by the declared values. Combined with the "value range propagation" optimization and some technically incorrect code in older Stockfishes, this led to it happily optimizing eg_value(score) to zero! You can imagine how well those builds played.

SF was clearly not the only program affected, as the GCC devs noted in their changelog for version 4.6:

G++ no longer optimizes using the assumption that a value of enumeration type will fall within the range specified by the standard, since that assumption is easily violated with a conversion from integer type (c++/43680). The old behavior can be restored with -fstrict-enums.

[mcostalba]

The provide a bit of noise to the score, but who cares?

I think we care

We really want our poor man functionality checksum that is node count on a set of fixed positions is the same for all binaries out of the same sources, be it 32 or 64bit, Intel or PowerPc (read big endian Mac).

This is very important both for debug and safe development.

[hgm]

Wel, surely he endianness must be known at compile time. You could make an #ifdef BIGENDIAN which declares the two short fields in the reverse order.

[mcostalba]

SF was clearly not the only program affected, as the GCC devs noted in their changelog for version 4.6:

Perhaps a bit off-topic, but, because I see you have the new 4.6, I would like to ask if you see some warnings compiling SF 2.0.1

Thanks
Marco

[Evert]

We really want our poor man functionality checksum that is node count on a set of fixed positions is the same for all binaries out of the same sources, be it 32 or 64bit, Intel or PowerPc (read big endian Mac).

This is very important both for debug and safe development.

None of that should be affected by using a union to wrap the two 16-bit values in a 32-bit integer though.

[mcostalba]

Wel, surely he endianness must be known at compile time. You could make an #ifdef BIGENDIAN which declares the two short fields in the reverse order.

The problem is not the #ifdef BIGENDIAN, well, yes it is a bit of problem also that but the biggest part is the modification to the Makefile to correctly handle the BIGENDIAN flag under all cases / compilers, and this is not so trivial ! Apart for being extremely ugly and error prone.

P.S: Answering also to the next post: The problem is that the sign bit you don't know in advance if it goes in the mg_value or eg_value part so that result of an evaluation could be different between big and little endian.

[hgm]

You mean there is no standard macro for this? That sure would be a black mark on the compiler writers. What could be more natural than wanting to know the endianness of the machine? I never really tried any other compiler than gcc for x86, but I always assumed that symbols like WIN32 would be universally defined.

Btw, my engines use packed integers too. E.g. in the PST of HaQiKi D the 16 upper bits are the true PST values, and the two lowest bytes are attack points on the white and black Palace, respectively. But to prevent problems with overflow of the sign bit, I use excess encoding for the low bytes, like Bob suggests.

[wgarvin]

You mean there is no standard macro for this? That sure would be a black mark on the compiler writers. What could be more natural than wanting to know the endianness of the machine? I never really tried any other compiler than gcc for x86, but I always assumed that symbols like WIN32 would be universally defined.

Btw, my engines use packed integers too. E.g. in the PST of HaQiKi D the 16 upper bits are the true PST values, and the two lowest bytes are attack points on the white and black Palace, respectively. But to prevent problems with overflow of the sign bit, I use excess encoding for the low bytes, like Bob suggests.

There is no single standard macro, but there are various pre-defined macros that can be used to detect or infer compiler and endianness.

Here's a header file (posh.h) that can detect a lot of different compilers/platforms.