Re: [gnugo-devel] Re: [PATCH 4/4] Autotools refresh.

[Gunnar Farnebäck]

On 09/23/10 20:52, Yann Dirson wrote:
> configure does report results for the compiler's target platform
> (which autostuff calls "host machine", it reserves "target machine" to
> talk about the target of a toolchain when we are building one - so the
> "canadian cross" setup is building on a "build machine" a compiler
> that will run on "host machine" to build binaries for "target
> machine" - now *that* is fishy ;)

Ok, so then the world is basically sane. Is there any way of making
the target SIZEOF_LONG available to the native build?

> > Here's an experiment you could try. After running configure on your
> > 64-bit machine, change SIZEOF_LONG to 4, then do your cross-build and
> > see if fusekiN.c compiles better.
>
> It correctly reports SIZEOF_LONG as 4 when I cross-compîle, and 8 when
> I compile natively.  But since my "build machine" printf's 64bit
> longs, the cross-compiler with 32bit longs issues truncation warnings.

My idea is to cheat the native compilation to build with SIZEOF_LONG 4
despite sizeof(long) being 8. But apparently it's also necessary to
first make this modification:

diff --git a/engine/hash.c b/engine/hash.c
index 6ccf892..ee18352 100644
--- a/engine/hash.c
+++ b/engine/hash.c
@@ -60,7 +60,7 @@ hash_rand(void)
   int i;
   Hashvalue h = 0;

-  for (i = 0; 32*i < (int) (CHAR_BIT*sizeof(Hashvalue)); i++)
+  for (i = 0; 32*i < (int) (CHAR_BIT*SIZEOF_HASHVALUE); i++)
     h |= (Hashvalue) gg_urand() << 32*i;

   return h;

After that uncompress_fuseki builds perfectly fine 32 bit fusekiN.c.
Unfortunately this won't work the other way round with forging
SIZEOF_LONG 8 when sizeof(long) is 4. (Not to speak of the horrors of
having different CHAR_BIT on host and target...)

The primary problem is that, for efficiency reasons, uncompress_fuseki
generates hash values which are built into the final binary, so
uncompress_fuseki must agree on the hash value details with the board
library in the final build. This can be achieved by either:
1. Building for and running uncompress_fuseki on the target platform.
2. Having identical datatypes for Hashvalue on host and target.
3. Giving uncompress_fuseki information about the size of Hashvalue on
   the target platform.

Alternative one is really the proper solution, although impractical in
practice. The second option is of course what your patch aims at but
it doesn't make proper use 64 bit registers when such are available,
there's no guarantee that uint32 exists (iirc), and it won't build
with c99 unaware compilers (I think). I really like the simplicity of
just using long.

The third option requires that SIZEOF_LONG (and to be picky CHAR_BIT)
for the target is available to the native build and a bit more work to
make proper use of the knowledge. I'd prefer this approach if it's
feasible.

/Gunnar