From: Jim Segrave <address@hidden>
Reply-To: address@hidden
To: Jonathan Kinsey <address@hidden>
CC: address@hidden
Subject: Re: [Bug-gnubg] gnubg on amd64 architecture
Date: Tue, 13 Feb 2007 12:18:45 +0100
On Tue 13 Feb 2007 (10:42 +0000), Jonathan Kinsey wrote:
>
> >From: Jim Segrave <address@hidden>
> >
> >I just got a new laptop with an Intel Core2 Duo and tried building
> >gnubg there (gentoo Linux as FreeBSD can't currently support the
> >Radeon graphics chip nor the Intel sound chip :-(( )
> >
> >I have a fix for the sse tests in neuralnet.c, which otherwise don't
> >compile (pushfl is not valid on this architecture, pushf pushes a 64
> >bit value, so the pop's must become popq's to 64 bit
> >registers). What's the best way of setting a #define so that
> >neuralnet.c can choose which assembler code to generate for 32 bit and
> >64 bit machines? #define ATHLON perhaps?
> >
> >As a side note, when it wouldn't compile and before I found the AMD
> >instruction set documents, I tried building it with the -march=sse2
> >and -DUSE_SSE_VECTORIZE flags omitted (on a fresh fetch from cvs), yet
> >conf.h still had #define USE_SSE_VECTORISE 1, so the compile still
> >failed. What's the correct way of suppressing the sse code?
> >
> >>From brief testing, the results of analysing a match with a CLI
> >invocation of gnubg gives virtually identical results as I was getting
> >on my 686 machine, so it looks like the sse code is working.
> >
> >However, in GUI mode, it is segfaulting in RenderBoard, I think because
> >nStride is -324, which in turn appears to be because nSize is
> >-1. Anyone know what's happening here? It's not 3d related, as a
> >rebuild --without-board3d behaves the same way.
>
> A stack trace would be handy, you might want to look at the value of
nSize.
> It might be an idea to do a cli build first to get things going.
>
> I'm going to check in a couple of small changes tonight which may well
effect
> the multi-threaded code on 64bit, so you will want to get that later.
>
> * Just remembered a crash I got the other day, when the direction of
play was
> swapped, didn't get time to track it down but may be the problem you
have.
I've been testing builds on both an i386 machine (my old laptop -
FreeBSD) and the amd64 box.
pulling cvs from 31 Jan 2007 or later fails on both machines
pulling cvs from 30 Nov 2006 appears to work on both machines (since
I'm not at home, I can't see the display on the amd64 machine, but it
isn't segfaulting when running in graphical mode)
As noted, nStride was -1 when the segfault occurs.
If it matters, my .gnubgautorc is set for clockwise play (I bear off
to the left).
I'm going to do a binary search to find the failure point.
Any ideas on what we should use as a define to call in the AMD64
compatible code in neuralnet.c?