gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] gnu go for ArmLinux


From: Dave Denholm
Subject: Re: [gnugo-devel] gnu go for ArmLinux
Date: 05 Feb 2002 11:06:31 +0000

Arend Bayer <address@hidden> writes:

> On Mon, 4 Feb 2002, brian lee dae yung wrote:
> 
> > is it the footprint or the memory requirements that are big?  i read
> > that it GNU Go uses a hefty RAM cache.
> If I compile GNU Go 3.1.24 without debugging information and configured
> with
>   ./configure --disable-dfa
> I get an executable of a little more than 3M; with --enable-dfa (which
> improves performance) it is about 1.4M more. With cache-size set to 16 M
> (easy to adjust that, see the docs), it uses <= 22M of RAM on my GNU/Linux
> system.
> 
> > > Could you tell us a little more about the Yopy? How much
> > > RAM does it have?
> > 
> > the YP-3000 has 64MB SDRAM and 16MB FlashROM and uses the StrongARM
> > SA1110 @ 206 MHz.  It runs XWindows on ARMLinux + GMate's [the
> > manufacturer] own modifications.  It supports MMC, of which i have 2 64
> > MB cards.
> 
> That sounds like more than enough memory. I guess you will just have to go
> ahead and try it! GNU Go is all plain C, so I would not expect problems
> with compilation -- but I have never tried cross-compilation.


Hmm : usually I cross-compile for linux-arm, but because the build needs
to make and run things like mkpat on the development machine, I'd
assumed that extra work would be required to allow cross compilation of
gnugo.  [If cross-compilation was deemed important, one way out would
be to redo mkpat in an interpreted language.]


I tried compiling 3.1.3 on a linux/arm box, but got

owl.s: Assembler messages:
owl.s:8034: Error: address offset too large
owl.s:8176: Error: address offset too large

when compiling owl.c

.stabn 68,0,1997,.LM942-owl_determine_life
.LM942:
        add     r3, r7, r7, asl #1
        rsb     r3, r3, r3, asl #3
        add     ip, r5, r3
        add     r8, fp, ip
        sub     r2, r8, #36
        b       .L990
.L992:
        .align  0
.L991:
        .word   board_size
        .word   p
        .word   life
.L990:
        ldrsb   r3, [r2, #-888]  <--------
        cmp     r3, #0
        ble     .L888
.stabn 68,0,2000,.LM943-owl_determine_life
.LM943:
        mvn     r6, #0
        strb    r6, [r2, #-888]
.stabn 68,0,2003,.LM944-owl_determine_life



Which I guess corresponds to

        if (mx[m][n] <= 0)
          continue;

        mx[m][n] = -1;
        topological_intersections--;

(all the shifting was working out [m][n], and now its trying
to access the local.)


Probably just a bug in my gcc, since it's generating code
with too big an offset. (Looks like owl_determine_life() has
more local variables than this gcc expects..?)



dd
-- 
address@hidden          http://www.insignia.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]