[Gcl-devel] Progress...

[Camm Maguire]

Greetings!  Well, we can now add m68k to arm and i386 to our list of
successful builds.  All of these work with the bfd relocations, so I
think this is going to help (2.5.0).

Alas, there are other porting issues beside relocations which have
appeared in this exercise.  And unfortunately, these appear to still
prevent completely successful *maxima* builds on arm and m68k.  The
typical behavior is that after successfully building and compiling a
few files, gcl stops parsing the lisp correctly, typically reporting
"Dots appeared illegally" at some point.  My guess is that this has
nothing to do with the loading, but with the gc kicking in, but I have
not yet confirmed this.

One patch I had to make to get m68k working has made me begin to
reconsider our current course.  Our 'priority list' aims at getting
basically the current code working on as many arches first before
doing serious cleaning.  But here is (a piece of) the patch which was
needed for m68k:

===================================================================
RCS file: /cvsroot/gcl/gcl/o/funlink.c,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 funlink.c
--- o/funlink.c 6 Dec 1999 22:44:11 -0000       1.1.1.1
+++ o/funlink.c 10 Jan 2002 22:08:56 -0000
@@ -229,208 +229,208 @@
 c_apply_n(fn,n,x)
      object *x;
      int n;
-     object (*fn)();
+     int (*fn)();
 {object res;
  switch(n){
-    case 0:  res=(*fn)();break;
-    case 1:  res=(*fn)(x[0]);break;
-    case 2:  res=(*fn)(x[0],x[1]);break;
-    case 3:  res=(*fn)(x[0],x[1],x[2]);break;
-    case 4:  res=(*fn)(x[0],x[1],x[2],x[3]);break;
-    case 5:  res=(*fn)(x[0],x[1],x[2],x[3],x[4]);break;
-    case 6:  res=(*fn)(x[0],x[1],x[2],x[3],x[4],x[5]);break;
-    case 7:  res=(*fn)(x[0],x[1],x[2],x[3],x[4],x[5],x[6]);break;
-    case 8:  res=(*fn)(x[0],x[1],x[2],x[3],x[4],x[5],x[6],x[7]);break;
-    case 9:  res=(*fn)(x[0],x[1],x[2],x[3],x[4],x[5],x[6],x[7],
+    case 0:  res=(object)(*fn)();break;
+    case 1:  res=(object)(*fn)(x[0]);break;
+    case 2:  res=(object)(*fn)(x[0],x[1]);break;
+    case 3:  res=(object)(*fn)(x[0],x[1],x[2]);break;
+    case 4:  res=(object)(*fn)(x[0],x[1],x[2],x[3]);break;
+    case 5:  res=(object)(*fn)(x[0],x[1],x[2],x[3],x[4]);break;
+    case 6:  res=(object)(*fn)(x[0],x[1],x[2],x[3],x[4],x[5]);break;
+    case 7:  res=(object)(*fn)(x[0],x[1],x[2],x[3],x[4],x[5],x[6]);break;
+    case 8:  res=(object)(*fn)(x[0],x[1],x[2],x[3],x[4],x[5],x[6],x[7]);break;
...
=============================================================================

In short, the implicit casts which are used throughout the code, and
which don't appear as compiler warnings both due to the absence of
prototypes and the lack of e.g. -Wall in the flags caused a serious
malfunction on this platform due to the high loading address of DBEGIN
(it appears).  

I'm just reporting this for two reasons:

1) To let you all know to watch for this in your own porting work.
2) To indicate that we might need to start the long, tedious, but
straightforward process of debugging with -Wall soon.  

Take care,


-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah