[CLN-list] Re: [cln] sparc64 and OpenBSD

Paul Irofti bulibuta at gmail.com
Mon Nov 19 11:23:58 CET 2007


On Fri, Nov 16, 2007 at 11:38:38PM +0100, Richard B. Kreckel wrote:
> Hi Paul,
>
> (I'm CCing the mailing list.)
That's fine, I subscribed today to the mailing list.

>
>
> Paul Irofti wrote:
>> I'm currently porting cln on OpenBSD. I'm having some problems with the
>> sparc64 arch. I fixed some bugs and have others in my to do list.
>
>
> Thanks you very much. Your patches are against CLN 1.1.13. Could you, 
> please, check out CVS HEAD instead (a.k.a. CLN 1.2-pre)? At least the 
> "\n\t" patch is already in there.
I know it was there, I'm currently working on porting the stable branch
to OpenBSD, not the head as that would be hard to maintain and prone to
error.

I'm browsing the WebCVS though and looking for fixes, so except the
`\n\t' fix most are new patches, I'll mark the new ones from now on.

[--snip--]

>
>> Currently I'm stuck on one in polynomial/elem. It has to do with a
>> multiplication.  In src/polynomial/elem/cl_UP_GF2.h, why do you define the 
>> gf2_mul_table
>> only for arches that are not sparc? Calls to this table are made further
>> for arches that have intDsize=64 (that includes sparc64) and thus error
>> out.
>> I'll further let the error messages and the patches talk for them selfs.
>> Please get back to me so we can fix these and make cln available for
>> OpenBSD. FreeBSD already marked sparc64 as broken arch and NetBSD,
>> apparently, didn't even test it on this platform.
>
>
> I'm no Sparc expert. To me, some of the patches don't talk for themselves. 
> Can you, please, add short Changelog entries?

Well, I'm no sparc expert either (-:

I've actually never seen one or operated on one. But I'm working with a
developer from OpenBSD that mails me the build errors and I figure them
out. So far everything seems to be working fine and errors were easy to
spot as they were semantics or some sort of `typos' (like the missing
`%' in one of the patches).

I'll try and detail what each of the patch does further on...

>
>
>> ------------------------------------------------------------------------
>> /usr/local/bin/libtool  --mode=compile c++ -O2 -pipe -Wformat -Wbounded
>> -I/usr/local/include -I../include -I../include -I./polynomial -I./base
>> -I./base/hash -I./base/digitseq -I./base/digit -Ibase  -c
>> ./polynomial/elem/cl_UP.cc
>>  c++ -O2 -pipe -Wformat -Wbounded -I/usr/local/include -I../include
>> -I../include -I./polynomial -I./base -I./base/hash -I./base/digitseq
>> -I./base/digit -Ibase -c ./polynomial/elem/cl_UP.cc  -fPIC -DPIC -o
>> .libs/cl_UP.o
>> In file included from ../include/cln/univpoly.h:6,
>>                  from polynomial/elem/cl_UP.cc:11:
>> ../include/cln/object.h:29:1: warning: "cl_word_alignment" redefined
>> ../include/cln/object.h:26:1: warning: this is the location of the 
>> previous
>> definition
>> In file included from polynomial/elem/cl_UP.cc:36:
>> polynomial/elem/cl_UP_GF2.h: In function `uint64 cln::gf2_mul32_(unsigned
>> int, unsigned int)':
>> polynomial/elem/cl_UP_GF2.h:766: error: `gf2_mul_table' undeclared (first
>> use this function)
>> polynomial/elem/cl_UP_GF2.h:766: error: (Each undeclared identifier is
>> reported only once for each function it appears in.)
>> ------------------------------------------------------------------------
>> $OpenBSD$
>> --- src/base/cl_low.h.orig	Mon Nov 12 17:43:08 2007
>> +++ src/base/cl_low.h	Mon Nov 12 17:48:07 2007
>> @@ -238,7 +238,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar
>>    #define mulu32(x,y,hi_zuweisung,lo_zuweisung)  \
>>      ({ var register uint64 _hi;					\
>>         var register uint64 _lo;					\
>> -       __asm__("umul %2,%3,%1\n\trd %y,%0"			\
>> +       __asm__("umul %2,%3,%1\n\trd %%y,%0"			\

This was missing an `%' character needed in order to escape the
formatting.

>>  	       : "=r" (_hi), "=r" (_lo)				\
>>  	       : "r" ((uint32)(x)), "r" ((uint32)(y))		\
>>  	      );						\
>> @@ -429,7 +429,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar
>>        __asm__ __volatile__ (       \
>>          "wr %%g0,%%g0,%%y\n\t"     \
>>          "udiv %2,%3,%0\n\t"        \
>> -        "umul %0,%3,%1"            \
>> +        "umul %0,%3,%1\n\t"            \
>>          "sub %2,%1,%1"             \
>>          : "=&r" (__q), "=&r" (__r) \
>>          : "r" (__x), "r" (__y));   \
>> @@ -518,7 +518,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar
>>        __asm__ __volatile__ (       \
>>          "wr %%g0,%%g0,%%y\n\t"     \
>>          "udiv %2,%3,%0\n\t"        \
>> -        "umul %0,%3,%1"            \
>> +        "umul %0,%3,%1\n\t"            \
>>          "sub %2,%1,%1"             \
>>          : "=&r" (__q), "=&r" (__r) \
>>          : "r" (__x), "r" (__y));   \
>> @@ -568,7 +568,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar
>>        __asm__ __volatile__ (       \
>>          "wr %%g0,%%g0,%%y\n\t"     \
>>          "udiv %2,%3,%0\n\t"        \
>> -        "umul %0,%3,%1"            \
>> +        "umul %0,%3,%1\n\t"            \
>>          "sub %2,%1,%1"             \
>>          : "=&r" (__q), "=&r" (__r) \
>>          : "r" (__x), "r" (__y));   \
>> @@ -680,7 +680,7 @@ inline uint32 mulu32_unchecked (uint32 arg1, uint32 ar
>>        __asm__ __volatile__ (       \
>>          "wr %2,%%g0,%%y\n\t"       \
>>          "udiv %3,%4,%0\n\t"        \
>> -        "umul %0,%4,%1"            \
>> +        "umul %0,%4,%1\n\t"            \
>>          "sub %3,%1,%1"             \
>>          : "=&r" (__q), "=&r" (__r) \
>>          : "r" (__xhi), "r" (__xlo), "r" (__y)); \

These are the `\n\t' fixes that you already have in the CVS.

>> ------------------------------------------------------------------------
>> $OpenBSD$
>> --- src/base/digitseq/cl_asm_sparc64_.cc.orig	Fri Jan 28 13:37:28 2000
>> +++ src/base/digitseq/cl_asm_sparc64_.cc	Wed Nov 14 16:42:47 2007
>> @@ -42,6 +42,8 @@
>>           .seg "text"
>>  +	.register	%g2,#scratch
>> +
>>          .global C(mulu16_),C(mulu32_),C(mulu32_unchecked),C(mulu64_)
>>          .global C(divu_6432_3232_),C(divu_3216_1616_)
>>          .global 
>> C(copy_loop_up),C(copy_loop_down),C(fill_loop_up),C(fill_loop_down)

You have to register the globals in order to use them in your code,
please see sparc documentation.

Mainly you have to do a ``.register %g[2367], #scratch'' for every
global register that you use within    ^^^^

>
>
> Your other patch:
>
>> $OpenBSD$
>> --- include/cln/object.h.orig	Thu Nov 15 11:58:06 2007
>> +++ include/cln/object.h	Thu Nov 15 11:58:13 2007
>> @@ -22,7 +22,7 @@ namespace cln {
>>  #if defined(__m68k__)
>>    #define cl_word_alignment  2
>>  #endif
>> -#if defined(__i386__) || defined(__mips__) || defined(__mipsel__) || 
>> defined(__sparc__) || defined(__hppa__) || defined(__arm__) || 
>> defined(__rs6000__) || defined(__m88k__) || defined(__convex__) || 
>> defined(__s390__)
>> +#if defined(__i386__) || defined(__mips__) || defined(__mipsel__) || 
>> (defined(__sparc__) && !defined(__sparc64__))|| defined(__hppa__) || 
>> defined(__arm__) || defined(__rs6000__) || defined(__m88k__) || 
>> defined(__convex__) || defined(__s390__)
>>    #define cl_word_alignment  4
>>  #endif
>>  #if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || 
>> defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__)

This is a patch that removes a warnning:
[---]
`` In file included from ../include/cln/univpoly.h:6,
                  from polynomial/elem/cl_UP.cc:11:
 ../include/cln/object.h:29:1: warning: "cl_word_alignment" redefined
 ../include/cln/object.h:26:1: warning: this is the location of the 
 previous
 definition''
[---]

Because the sparc64 arch defines __sparc__ and __sparc64__ there was a
a double definition for cl_word_alignment. The first statement matched
__sparc__ (on sparc64) and defined it as 4 and then the next one also
matched __sparc64__ and /redefined/ it as 8.

>> $OpenBSD$
>> --- src/polynomial/elem/cl_UP_GF2.h.orig	Thu Nov 15 11:51:38 2007
>> +++ src/polynomial/elem/cl_UP_GF2.h	Thu Nov 15 11:56:45 2007
>> @@ -746,10 +746,10 @@ uint32 gf2_mul32 (uint32 x, uint32 y, uint32* plo)
>>   // Multiply two GF2-polynomials of degree < intDsize.
>>  // Stores the low part, returns the high part.
>> -#if (intDsize==32)
>> +#if (intDsize==32) || defined(__sparc64__)
>>    #define gf2_mul_uintD  gf2_mul32
>>  #endif
>> -#if (intDsize==64)
>> +#if (intDsize==64) && !defined(__sparc64__)
>>    inline uint64 gf2_mul32_ (uint32 x, uint32 y)
>>    {
>>  	var uint16 *ptr; // uint16 ptr[0x10];

This is the reason while I emailed you in the first place (I would've
sent the entire patches when I would've finished). You see this file
define a rather long table of multiplications that is valid while on any
arch but sparc (be it sparc64 or sparc).

Now, the function that you see in the diff above uses this table be it
sparc or not, thus you get an undefined variable error:
[---]
 In file included from polynomial/elem/cl_UP.cc:36:
 polynomial/elem/cl_UP_GF2.h: In function `uint64 cln::gf2_mul32_(unsigned
 int, unsigned int)':
 polynomial/elem/cl_UP_GF2.h:766: error: `gf2_mul_table' undeclared (first
 use this function)
 polynomial/elem/cl_UP_GF2.h:766: error: (Each undeclared identifier is
 reported only once for each function it appears in.)
[---]

One of the functions in the same file, when having to deal with sparc,
mapped the function to another that did not use the gf2_mul_table. This
was a 32-bit function, the one that errors out is a 64-bit one. I've
attempted to remap it to the same one in case of 64-bit as a temporary
hack until you guys can fix-up a 64-bit function for sparc.

My explanation here has to be accompanied with the source file,
otherwise it might not make much sense. Please give it some thought and
ask what you don't understand or correct me where I'm wrong.

>
>
> Aha, so __sparc64__ *is* defined. Good. The earlier patch by Sven 
> Verdoolaege implied that it wasn't.
>
> So, you got it to compile in the end? Did you run make check? What did it 
> report?
With the fix that I mentioned (and tried to explain) above it compiled
quite a bit further.

My new error is:

I'll work on it today and see what I can do/find.

>
> Looking forward to see CLN fixed on sparc64
Me too.


More information about the CLN-list mailing list