On Mon, Nov 19, 2007 at 01:07:40PM +0200, Paul Irofti wrote:
On Mon, Nov 19, 2007 at 12:23:58PM +0200, Paul Irofti wrote: [--snip--]
My new error is:
[--attached--]
/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 polynomial/elem/cl_UP.cc:36: polynomial/elem/cl_UP_GF2.h: In function `const cln::_cl_UP cln::gf2_mul(cln::cl_heap_univpoly_ring*, const cln::_cl_UP&, const cln::_cl_UP&)': polynomial/elem/cl_UP_GF2.h:846: error: cannot convert `uintD*' to `uint32*' for argument `3' to `uint32 cln::gf2_mul32(unsigned int, unsigned int, uint32*)' polynomial/elem/cl_UP_GF2.h:862: error: cannot convert `uintD*' to `uint32*' for argument `3' to `uint32 cln::gf2_mul32(unsigned int, unsigned int, uint32*)'
It seems that this is generated by my former fix (the one I was inquiring about). I can't just remap a 64-bit to a 32-bit function so a devel will have to write an additional assembly routine for 64-bit sparc here: .global C(gf2_mul16),C(gf2_mul32),C(gf2_mul64) ^^^^^^^^^^^^ The file is src/polynomial/elem/cl_asm_sparc_GF2.cc.
Hi Paul! You wrote:
Echo!
echo is on :) Sorry for the late answer, I've been traveling. I've committed the .register %2,#scratch patch and the one for not redefining cl_word_alignment to the main branch. The patch to mulu32 is obsolete there. I intend to release CLN-1.2 before x-mas (yes, this year), so I have little incentive to touch the CLN-1.x branch.
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). [...]
It seems that this is generated by my former fix (the one I was inquiring about). I can't just remap a 64-bit to a 32-bit function so a devel will have to write an additional assembly routine for 64-bit sparc here:
Hmm, why not just drop the assembler support on sparc64 for these polynomial functions? Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Wed, Nov 28, 2007 at 11:49:57PM +0100, Richard B. Kreckel wrote:
Hi Paul!
You wrote:
Echo!
echo is on :) (-:
Sorry for the late answer, I've been traveling.
I've committed the .register %2,#scratch patch and the one for not redefining cl_word_alignment to the main branch. The patch to mulu32 is obsolete there. I intend to release CLN-1.2 before x-mas (yes, this year),
Thank you.
so I have little incentive to touch the CLN-1.x branch.
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). [...]
It seems that this is generated by my former fix (the one I was inquiring about). I can't just remap a 64-bit to a 32-bit function so a devel will have to write an additional assembly routine for 64-bit sparc here:
Hmm, why not just drop the assembler support on sparc64 for these polynomial functions? Don't know, if its possible and it doesn't affect the codebase then do it, afterwards I'll start retesting on sparc64 for porting.
cln entered the OpenBSD ports tree btw. I had sparc64 marked broken. Currently trying to get GiNac as well, it should probably be in by the end of the week (there seemed to be a problem with the test unit make target as it took much longer than the former version to complete).
Hi! Paul Irofti wrote:
On Wed, Nov 28, 2007 at 11:49:57PM +0100, Richard B. Kreckel wrote:
It seems that this is generated by my former fix (the one I was inquiring about). I can't just remap a 64-bit to a 32-bit function so a devel will have to write an additional assembly routine for 64-bit sparc here: Hmm, why not just drop the assembler support on sparc64 for these
You wrote: [...] polynomial functions? Don't know, if its possible and it doesn't affect the codebase then do it, afterwards I'll start retesting on sparc64 for porting.
You mean, without even having access to such a machine? Ugh... Well, let's see. Earler, you wrote the error is:
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.)
Indeed, function gf2_mul32_ is defined if intDsize==64 and it refers to gf2_mul_table which is defined unless on sparc or sparc64. Hmm, this seems to suggest an easy fix: Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; } -#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better? Does this help? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
I wrote:
Indeed, function gf2_mul32_ is defined if intDsize==64 and it refers to gf2_mul_table which is defined unless on sparc or sparc64. Hmm, this seems to suggest an easy fix:
Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; }
-#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better?
Does this help?
Echo!
On Tue, Dec 11, 2007 at 12:02:02AM +0100, Richard B. Kreckel wrote:
I wrote:
Indeed, function gf2_mul32_ is defined if intDsize==64 and it refers to gf2_mul_table which is defined unless on sparc or sparc64. Hmm, this seems to suggest an easy fix:
Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; }
-#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better?
Does this help?
Echo! Echo On (-:
I've sent the patch a few days ago, still waiting for the reply.
On Thu, Nov 29, 2007 at 11:02:17PM +0100, Richard B. Kreckel wrote:
Hi!
Paul Irofti wrote:
On Wed, Nov 28, 2007 at 11:49:57PM +0100, Richard B. Kreckel wrote:
It seems that this is generated by my former fix (the one I was inquiring about). I can't just remap a 64-bit to a 32-bit function so a devel will have to write an additional assembly routine for 64-bit sparc here: Hmm, why not just drop the assembler support on sparc64 for these
You wrote: [...] polynomial functions? Don't know, if its possible and it doesn't affect the codebase then do it, afterwards I'll start retesting on sparc64 for porting.
You mean, without even having access to such a machine? Ugh...
Well, let's see. Earler, you wrote the error is:
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.)
Indeed, function gf2_mul32_ is defined if intDsize==64 and it refers to gf2_mul_table which is defined unless on sparc or sparc64. Hmm, this seems to suggest an easy fix:
Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; }
-#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better?
Does this help?
Indeed it does: the library compiles, but some of the tests fail. Maybe you can shed some light into this.
Hi Paul, Paul Irofti wrote:
On Thu, Nov 29, 2007 at 11:02:17PM +0100, Richard B. Kreckel wrote:
Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; }
-#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better?
Does this help?
Indeed it does: the library compiles, but some of the tests fail. Maybe you can shed some light into this.
Okay, I've applied that patch to the main branch. We've made it compile. That was the easier part. It appears like test loops in src/base/digitseq/cl_asm_sparc64_.cc are broken. You can try debugging the problem. As a blind shot, you could try redefining LOOP_TYPE in that file. But trying patches and submitting them into some build queue does not make sense any more. Now, somebody must debug things on a machine. Paul, can you do that? It shouldn't be too difficult. If not, can you arrange a login for me? Please do contact me in private if there is a chance. Regards -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On Mon, Dec 17, 2007 at 09:18:06PM +0100, Richard B. Kreckel wrote:
Hi Paul,
Paul Irofti wrote:
On Thu, Nov 29, 2007 at 11:02:17PM +0100, Richard B. Kreckel wrote:
Index: src/polynomial/elem/cl_UP_GF2.h =================================================================== RCS file: /home/cvs/cln/src/polynomial/elem/cl_UP_GF2.h,v retrieving revision 1.8 diff -u -r1.8 cl_UP_GF2.h --- src/polynomial/elem/cl_UP_GF2.h 1 Aug 2007 22:07:37 -0000 1.8 +++ src/polynomial/elem/cl_UP_GF2.h 29 Nov 2007 22:01:03 -0000 @@ -95,7 +95,7 @@ return x; }
-#if !(defined(__sparc__) || defined(__sparc64__)) +#if !defined(__sparc__) || defined(__sparc64__) // Multiplication of polynomials over GF(2) can unfortunately not profit // from hardware multiply instructions. Use a table instead. // This is a 2^8 x 2^4 table. Maybe a 2^6 x 2^6 table would be better?
Does this help?
Indeed it does: the library compiles, but some of the tests fail. Maybe you can shed some light into this.
Okay, I've applied that patch to the main branch. We've made it compile. That was the easier part. Indeed.
It appears like test loops in src/base/digitseq/cl_asm_sparc64_.cc are broken.
You can try debugging the problem. As a blind shot, you could try redefining LOOP_TYPE in that file. But trying patches and submitting them into some build queue does not make sense any more. Now, somebody must debug things on a machine. Paul, can you do that? It shouldn't be too difficult. If not, can you arrange a login for me? Please do contact me in private if there is a chance.
I'll see if I can get a sparc64 shell on my hands, but the one I was testing with is out of the question (that's what the guy said and I understand). I'll get back to you. Let me know if you find something too.
participants (2)
-
Paul Irofti
-
Richard B. Kreckel