From: Helmut D. <de...@fh...> - 2005-02-28 15:27:17
|
I am trying to compile clisp on an embedded system (arm-linux 2.4.22, gcc-3.3.4-glibc-2.2.5) and get the following error: Configure ok, but make quits after lisp.run tries to load the previously compiled 'compiler.fas'-file. ;; Loading file /tools/clisp-2.33.2/src/compiler.fas ... *** - SET-STREAM-EXTERNAL-FORMAT: illegal :EXTERNAL-FORMAT argument (0 0 0 0 0 0 0 0 0 1 CHARSET::DA 31 CHARSET::E4 CHARSET::|0F| 1 19 1) It appears that compiler.fas does not contain correct opcodes, as compared with compiler.fas from my x86-linux clisp: all opcodes are 0. The first lines of compiler.fas are: (SYSTEM::VERSION '(20040222.)) #0Y UTF-8 #Y(#:|(IN-PACKAGE "COMMON-LISP")-1| #00Y(00 00 00 00 00 00 00 00 00 01 DA 31 E4 0F 01 19 01) (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) "COMMON-LISP" COMMON-LISP::*PACKAGE*) #Y(#:|(EXPORT '(EXT:EVAL-ENV) "EXT")-2| #00Y(00 00 00 00 00 00 00 00 00 01 DA DB 31 D7 19 01) (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) (EXT::EVAL-ENV) "EXT") #Y(#:|(EXPORT '(CUSTOM:*PACKAGE-TASKS-TREAT-SPECIALLY*) "CUSTOM")-3| #00Y(00 00 00 00 00 00 00 00 00 01 DA DB 31 D7 19 01) (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) (CUSTOM::*PACKAGE-TASKS-TREAT-SPECIALLY*) "CUSTOM") #Y(#:|(EXT:RE-EXPORT "CUSTOM" "EXT")-4| #00Y(00 00 00 00 00 00 00 00 00 01 DA DB 31 E5 19 01) (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) "CUSTOM" "EXT") Any ideas how to solve this problem? Thanks, and regards Helmut Dersch |
From: Sam S. <sd...@gn...> - 2005-02-28 16:03:51
|
> * Helmut Dersch <qrefpu@su-shegjnatra.qr> [2005-02-28 16:27:10 +0100]: > > I am trying to compile clisp on an embedded system > (arm-linux 2.4.22, gcc-3.3.4-glibc-2.2.5) and get the following > error: Configure ok, but make quits after lisp.run tries > to load the previously compiled 'compiler.fas'-file. > > ;; Loading file /tools/clisp-2.33.2/src/compiler.fas ... > *** - SET-STREAM-EXTERNAL-FORMAT: illegal :EXTERNAL-FORMAT argument (0 0 0 > 0 0 0 0 0 0 1 CHARSET::DA 31 CHARSET::E4 CHARSET::|0F| 1 19 1) > > It appears that compiler.fas does not contain correct opcodes, > as compared with compiler.fas from my x86-linux clisp: all opcodes > are 0. The first lines of compiler.fas are: it appears that the _length_ of the bytecode vectors is printed as 0: note "#00Y" instead of "#17Y" > (SYSTEM::VERSION '(20040222.)) > #0Y UTF-8 > #Y(#:|(IN-PACKAGE "COMMON-LISP")-1| > #00Y(00 00 00 00 00 00 00 00 00 01 DA 31 E4 0F 01 19 01) > (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) "COMMON-LISP" > COMMON-LISP::*PACKAGE*) > #Y(#:|(EXPORT '(EXT:EVAL-ENV) "EXT")-2| > #00Y(00 00 00 00 00 00 00 00 00 01 DA DB 31 D7 19 01) > (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) (EXT::EVAL-ENV) "EXT") > #Y(#:|(EXPORT '(CUSTOM:*PACKAGE-TASKS-TREAT-SPECIALLY*) "CUSTOM")-3| > #00Y(00 00 00 00 00 00 00 00 00 01 DA DB 31 D7 19 01) > (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) > (CUSTOM::*PACKAGE-TASKS-TREAT-SPECIALLY*) "CUSTOM") > #Y(#:|(EXT:RE-EXPORT "CUSTOM" "EXT")-4| > #00Y(00 00 00 00 00 00 00 00 00 01 DA DB 31 E5 19 01) > (COMMON-LISP::T COMMON-LISP::T COMMON-LISP::T) "CUSTOM" "EXT") -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://pmw.org.il/> <http://www.memri.org/> <http://www.iris.org.il> <http://www.mideasttruth.com/> <http://www.honestreporting.com> Live free or die. |
From: Helmut D. <de...@fh...> - 2005-02-28 17:22:55
|
On Mon, 28 Feb 2005, Sam Steingold wrote: >... it appears that the _length_ of the bytecode vectors is printed as 0: > note "#00Y" instead of "#17Y" > Thanks for the correction! Any idea why this happens? Regards Helmut Dersch |
From: Bruno H. <br...@cl...> - 2005-02-28 17:33:17
|
Sam wrote: > it appears that the _length_ of the bytecode vectors is printed as 0: > note "#00Y" instead of "#17Y" > > > (SYSTEM::VERSION '(20040222.)) > > #0Y UTF-8 > > #Y(#:|(IN-PACKAGE "COMMON-LISP")-1| > > #00Y(00 00 00 00 00 00 00 00 00 01 DA 31 E4 0F 01 19 01) Yes. This looks like pr_uint in io.d does not work. If you are already using the safety measures recommended for a new port at the end of clisp/unix/PLATFORMS (especially you are compiling with -DSAFETY=3), then the next thing to look at is whether the machine code generated for the pr_uint function is correct. You get this machine code by doing "make io.s". Bruno |
From: Helmut D. <de...@fh...> - 2005-03-01 16:41:48
|
On Mon, 28 Feb 2005, Bruno Haible wrote: > > > #00Y(00 00 00 00 00 00 00 00 00 01 DA 31 E4 0F 01 19 01) > > Yes. This looks like pr_uint in io.d does not work. If you are already > using the safety measures recommended for a new port at the end of > clisp/unix/PLATFORMS (especially you are compiling with -DSAFETY=3), then > the next thing to look at is whether the machine code generated for > the pr_uint function is correct. You get this machine code by doing "make io.s". > > Bruno > > Thanks a lot, it works now. I get a clean compile, make test reports no errors and some preliminary work with clisp seem to be ok. SAFETY=3 and turning off optimization as suggested in the PLATFORMS file had no effect. Since I didn't really want to dive into ARM-assembler I replaced the function pr_uint in io.d with the following c-code: local void pr_uint (const gcv_object_t* stream_, uintL x) { uintB ziffern[10],*z=ziffern; do{ *z++=x%10; x/=10; }while(x!=0); while(z>ziffern) write_ascii_char(stream_,'0' + *--z); } I hope there are no subtle problems associated with that, at least speed should not be much different to the assembler version. Anyway, thanks for the help (and of course for the great piece of software!) Regards Helmut Dersch |
From: Bruno H. <br...@cl...> - 2005-03-01 17:13:10
|
Helmut Dersch wrote: > Since I didn't really > want to dive into ARM-assembler I replaced the > function pr_uint in io.d with the following c-code: > > local void pr_uint (const gcv_object_t* stream_, uintL x) { > uintB ziffern[10],*z=ziffern; > do{ > *z++=x%10; > x/=10; > }while(x!=0); > while(z>ziffern) > write_ascii_char(stream_,'0' + *--z); > } Hmm. divu_3216_3216 is used at a couple of other places as well, so it would be better to fix the problem at its origin. Why does the Debian ARM build work, see http://buildd.debian.org/fetch.php?&pkg=clisp&ver=1%3A2.33.2-10&arch=arm&stamp=1109164597&file=log&as=raw ? Bruno |
From: Helmut D. <de...@fh...> - 2005-03-01 20:41:53
|
> > Hmm. divu_3216_3216 is used at a couple of other places as well, so it > would be better to fix the problem at its origin. > I don't think it is this function. SAFER=3 should have removed all assembler code, but the error remained. > Why does the Debian ARM build work, see > http://buildd.debian.org/fetch.php?&pkg=clisp&ver=1%3A2.33.2-10&arch=arm&stamp=1109164597&file=log&as=raw > ? > Countless possibilities: different ARM processors (mine is particularily crippled, i.e. no floating point etc), different Linux configuration, etc... Regards Helmut Dersch |
From: Sam S. <sd...@gn...> - 2005-03-02 14:51:00
|
> * Helmut Dersch <qrefpu@su-shegjnatra.qr> [2005-03-01 21:41:27 +0100]: > >> >> Hmm. divu_3216_3216 is used at a couple of other places as well, so it >> would be better to fix the problem at its origin. > I don't think it is this function. SAFER=3 should have > removed all assembler code, but the error remained. did you do "make clean"? (or at least "rm -f *.o") -- Sam Steingold (http://www.podval.org/~sds) running w2k <http://pmw.org.il/> <http://www.memri.org/> <http://www.honestreporting.com> <http://www.iris.org.il> <http://www.camera.org> <http://www.mideasttruth.com/> Yeah, yeah, I love cats too... wanna trade recipes? |
From: Bruno H. <br...@cl...> - 2005-03-02 12:55:59
|
Helmut Dersch wrote: > > Hmm. divu_3216_3216 is used at a couple of other places as well, so it > > would be better to fix the problem at its origin. > > I don't think it is this function. SAFER=3 should have > removed all assembler code, but the error remained. -DSAFETY=3 should have removed all inline assembler code. The code in ariarm.d still remains. If you had put -DSAFER=3, it had no effect. Bruno |
From: Helmut D. <de...@fh...> - 2005-03-02 14:16:36
|
On Wed, 2 Mar 2005, Bruno Haible wrote: > Helmut Dersch wrote: > > > Hmm. divu_3216_3216 is used at a couple of other places as well, so it > > > would be better to fix the problem at its origin. > > > > I don't think it is this function. SAFER=3 should have > > removed all assembler code, but the error remained. > > -DSAFETY=3 should have removed all inline assembler code. The code in ariarm.d > still remains. If you had put -DSAFER=3, it had no effect. > I see. It appears that the function divu_3216_1616_ indeed does not work on my system. I am getting errors in other places where this function is used, eg (log 3 10) = 1/2. I have now (hopefully) fixed it by replacing divu_3216_1616_ in arilev0.d with { q_zuweisung (x / y); r_zuweisung (x % y); } (was { q_zuweisung divu_3216_1616_(x,y); /* extern in Assembler */\ r_zuweisung divu_16_rest; \ } ) So far this has solved all errors. I still don't know what is wrong with the original code, but it seams to set divu_16_rest always to 0. Helmut Dersch |