Subject: [clisp-list] hppa64 build fix

From: Will Newton <[email-masked]>
Date: Tue Jun 25 18:37:02 2002

This patch enables avcall support for hppa 64bit architectures.
Only in clisp-2.28.old/ffcall/autoconf: .aclocal.m4.swp
diff -ru clisp-2.28.old/ffcall/autoconf/aclocal.m4 clisp-2.28/ffcall/autoconf/aclocal.m4
--- clisp-2.28.old/ffcall/autoconf/aclocal.m4	Thu Mar 21 13:25:08 2002
+++ clisp-2.28/ffcall/autoconf/aclocal.m4	Wed Jun 26 02:34:06 2002
@@ -318,7 +318,7 @@
   alphaev[4-8] | alphaev56 | alphapca5[67] | alphaev6[78] )
     host_cpu=alpha
     ;;
-  hppa1.0 | hppa1.1 | hppa2.0 )
+  hppa1.0 | hppa1.1 | hppa2.0 | hppa64 )
     host_cpu=hppa
     ;;
   powerpc )
diff -ru clisp-2.28.old/src/autoconf/aclocal.m4 clisp-2.28/src/autoconf/aclocal.m4
--- clisp-2.28.old/src/autoconf/aclocal.m4	Thu Mar 21 13:15:45 2002
+++ clisp-2.28/src/autoconf/aclocal.m4	Wed Jun 26 02:33:37 2002
@@ -691,7 +691,7 @@
   alphaev[4-8] | alphaev56 | alphapca5[67] | alphaev6[78] )
     host_cpu=alpha
     ;;
-  hppa1.0 | hppa1.1 | hppa2.0 )
+  hppa1.0 | hppa1.1 | hppa2.0 | hppa64 )
     host_cpu=hppa
     ;;
   powerpc )

---

From: Sam Steingold <[email-masked]>
Date: Wed Jun 26 05:35:03 2002

> * In message <[email-masked]>
> * On the subject of "[clisp-list] hppa64 build fix"
> * Sent on Wed, 26 Jun 2002 02:39:27 +0100
> * Honorable Will Newton <[email-masked]> writes:
>

why are you modifying only one of CL_CANONICAL_HOST_CPU and
CL_CANONICAL_HOST_CPU_FOR_FFCALL? 

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
It's not just a language, it's an adventure.  Common Lisp.

---

From: Will Newton <[email-masked]>
Date: Wed Jun 26 06:27:04 2002

> CL_CANONICAL_HOST_CPU_FOR_FFCALL?

Oops. Sorry. Amended patch attached. Should be right this time.

+++ clisp-2.28/src/autoconf/aclocal.m4	Wed Jun 26 14:23:22 2002
@@ -754,7 +754,7 @@

---

From: Sam Steingold <[email-masked]>
Date: Wed Jun 26 06:59:05 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] hppa64 build fix"
> * Sent on Wed, 26 Jun 2002 14:29:10 +0100

actually, both aclocal.m4 have both CL_CANONICAL_HOST_CPU_FOR_FFCALL &
CL_CANONICAL_HOST_CPU.  :-)
Never mind: these files are generated anyway (from src/m4/general.m4).
I put the patch in.
Thanks.

[PS: when is 2.28 moving from `unstable' to `stable' on debian?]

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
What was the best thing before sliced bread?

---

From: Will Newton <[email-masked]>
Date: Wed Jun 26 07:41:04 2002

> Never mind: these files are generated anyway (from src/m4/general.m4).

I kinda lost touch with exactly how clisp does things in that area. Thanks.

> [PS: when is 2.28 moving from `unstable' to `stable' on debian?]

It would be possible to manually push it in - at the moment it is held up by 
the fact that the stable version builds on sparc and m68k and the unstable 
one doesn't. When I get clisp building on:

i386, alpha, powerpc, s390, (already built) hppa, mips, mipsel, arm (in need 
of tweaking)

or a decent subset thereof, I will make sure it goes in. Hopefully I can 
figure out the m68k/sparc crash before too long anyway.

---

From: Sam Steingold <[email-masked]>
Date: Wed Jun 26 08:08:05 2002

> * In message <[email-masked]>
> * Sent on Wed, 26 Jun 2002 15:43:50 +0100
> It would be possible to manually push it in - at the moment it is held
> up by the fact that the stable version builds on sparc and m68k and
> the unstable one doesn't. When I get clisp building on:
> 
> i386, alpha, powerpc, s390, (already built) hppa, mips, mipsel, arm
> (in need of tweaking)
> 
> or a decent subset thereof, I will make sure it goes in. Hopefully I
> can figure out the m68k/sparc crash before too long anyway.

interesting -- are you saying that there is a CLISP version that builds
on sparc/linux with glibc 2.2?!
I thought that all versions build with glibc 2.1 and none with glibc 2.2!

if this is indeed the case, you can do a binary search in the CVS to
pin-point the change that broke stuff.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Nostalgia isn't what it used to be.

---

From: Will Newton <[email-masked]>
Date: Wed Jun 26 08:30:10 2002

> on sparc/linux with glibc 2.2?!

No. Debian stable still runs 2.1. When the next stable Debian release occurs 
stable will have 2.27 and no sparc build.

---

From: Sam Steingold <[email-masked]>
Date: Wed Jun 26 12:03:45 2002

> can figure out the m68k/sparc crash before too long anyway.

I just built the current cvs clisp on the sourceforge compile farm
sparc/linux machine.  they do not have an m68k machine.

You need the following change (no patch yet! :-)
in lispbibl.d:

    # For pointers, the address takes the full word (with type info in the
    # lowest two bits). For immediate objects, we use 24 bits for the data
    # (but exclude the highest available bit, which is the garcol_bit).
    #if !((defined(MC680X0) && defined(UNIX_LINUX)) || (defined(I80386) && defined(UNIX_BEOS)) || (defined(SPARC) && defined(UNIX_LINUX)))
      #define oint_type_shift 0
      #define oint_type_len 8
      #define oint_type_mask 0x0000007FUL
      #define oint_data_shift 7
      #define oint_data_len 24
      #define oint_data_mask 0x7FFFFF80UL
      #define garcol_bit_o 31
    #elif defined(I80386) && defined(UNIX_BEOS)
      # On BeOS 5, malloc()ed addresses are of the form 0x80...... Bit 31
      # is therefore part of an address and cannot be used as garcol_bit.
      #define oint_type_shift 0
      #define oint_type_len 8
      #define oint_type_mask 0x0000003FUL
      #define oint_data_shift 6
      #define oint_data_len 24
      #define oint_data_mask 0x3FFFFFC0UL
      #define garcol_bit_o 30
    #elif (defined(MC680X0) && defined(UNIX_LINUX)) || (defined(SPARC) && defined(UNIX_LINUX))
      # On Sparc-Linux, malloc()ed addresses are of the form 0x0....... or
      # 0xe........ Bits 31..29 are therefore part of an address and cannot
      # be used as garcol_bit. We therefore choose bit 28 as garcol_bit.
      # Now, the 24 data bits of an immediate value must not intersect the
      # garcol_bit, so we use bits 27..4 for that (we could use bits 26..3
      # as well).
      # On m68k-Linux, malloc()ed addresses are of the form 0x80...... or
      # 0xc0....... Bits 31..30 are therefore part of an address and cannot
      # be used as garcol_bit. We therefore have three choices:
      #   data bits: bits 26..3, garcol_bit_o = 28/27
      #   data bits: bits 27..4, garcol_bit_o = 28/3
      #   data bits: bits 28..5, garcol_bit_o = 4/3
      #define oint_type_shift 0
      #define oint_type_len 32
      #define oint_type_mask 0xE000000FUL
      #define oint_data_shift 4
      #define oint_data_len 24
      #define oint_data_mask 0x0FFFFFF0UL
      #define garcol_bit_o 28
    #endif

__REMOVE__ the special case for SPARC (and probably MC680X0).
i.e., treat them just like all the other !TYPECODES !WIDE_HARD hosts.

The reason appears to be that now malloc does not touch the top 3 bits.
        (gdb) p malloc(1000)
        $1 = (void *) 0x3e8

Oh, yeah, and this:

# Immediate objects have a second type field.
  #if defined(SPARC) && defined(UNIX_LINUX)
    #define imm_type_shift  29
  #else
    #define imm_type_shift  3
  #endif

has to be scrapped too, of course!

Will, please try this on your sparc-linux and m68k-Linux boxes.
thanks.

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
To a Lisp hacker, XML is S-expressions with extra cruft.

---

From: Will Newton <[email-masked]>
Date: Wed Jun 26 17:12:11 2002

> Will, please try this on your sparc-linux and m68k-Linux boxes.

I don't have access to an m68k box directly either, but I will try this as 
soon as I can. I suspected it might have been that stanza of the file but I 
really don't have the understanding to delve in it. Thanks.

---

From: Will Newton <[email-masked]>
Date: Wed Jun 26 17:52:01 2002

> You need the following change (no patch yet! :-)

I made the change but still get the same crash on the Sourceforge Sparc/Linux 
machine. Is there something I'm missing? I have attached the diff I made.
--- lispbibl.d.old	Thu Jun 27 01:50:24 2002
+++ lispbibl.d	Thu Jun 27 01:52:47 2002
@@ -2356,7 +2354,7 @@
     # For pointers, the address takes the full word (with type info in the
     # lowest two bits). For immediate objects, we use 24 bits for the data
     # (but exclude the highest available bit, which is the garcol_bit).
-    #if !((defined(MC680X0) && defined(UNIX_LINUX)) || (defined(I80386) && defined(UNIX_BEOS)) || (defined(SPARC) && defined(UNIX_LINUX)))
+    #if !(defined(I80386) && defined(UNIX_BEOS))
       #define oint_type_shift 0
       #define oint_type_len 8
       #define oint_type_mask 0x0000007FUL
@@ -2374,26 +2372,6 @@
       #define oint_data_len 24
       #define oint_data_mask 0x3FFFFFC0UL
       #define garcol_bit_o 30
-    #elif (defined(MC680X0) && defined(UNIX_LINUX)) || (defined(SPARC) && defined(UNIX_LINUX))
-      # On Sparc-Linux, malloc()ed addresses are of the form 0x0....... or
-      # 0xe........ Bits 31..29 are therefore part of an address and cannot
-      # be used as garcol_bit. We therefore choose bit 28 as garcol_bit.
-      # Now, the 24 data bits of an immediate value must not intersect the
-      # garcol_bit, so we use bits 27..4 for that (we could use bits 26..3
-      # as well).
-      # On m68k-Linux, malloc()ed addresses are of the form 0x80...... or
-      # 0xc0....... Bits 31..30 are therefore part of an address and cannot
-      # be used as garcol_bit. We therefore have three choices:
-      #   data bits: bits 26..3, garcol_bit_o = 28/27
-      #   data bits: bits 27..4, garcol_bit_o = 28/3
-      #   data bits: bits 28..5, garcol_bit_o = 4/3
-      #define oint_type_shift 0
-      #define oint_type_len 32
-      #define oint_type_mask 0xE000000FUL
-      #define oint_data_shift 4
-      #define oint_data_len 24
-      #define oint_data_mask 0x0FFFFFF0UL
-      #define garcol_bit_o 28
     #endif
     #define oint_addr_shift 0
     #define oint_addr_len 32
@@ -2836,12 +2814,7 @@
   #define cons_bias       3  # mod 8
   #define immediate_bias  7  # mod 8
 
-# Immediate objects have a second type field.
-  #if defined(SPARC) && defined(UNIX_LINUX)
-    #define imm_type_shift  29
-  #else
-    #define imm_type_shift  3
-  #endif
+  #define imm_type_shift  3
 
 # The types of immediate objects.
   #define fixnum_type      ((0 << imm_type_shift) + immediate_bias)

---

From: Sam Steingold <[email-masked]>
Date: Thu Jun 27 07:48:11 2002

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-list] clisp & [sparc|m68k]-linux"
> * Sent on Thu, 27 Jun 2002 01:54:05 +0100

I appended the patch.

> I made the change but still get the same crash on the Sourceforge
> Sparc/Linux machine. Is there something I'm missing?

I guess the struggle is not over yet. :-(
CLISP _does_ build with the appended patch, but only --with-debug.
This setting turns off assembly and registers.
I.e., one has to figure out what registers are now grabbed by glibc on
sparc (and probably on m68k) and thus are unavailable...

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat7.2 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
In C you can make mistakes, while in C++ you can also inherit them!

--- lispbibl.d.~1.277.~	Wed Jun 26 13:59:20 2002
+++ lispbibl.d	Wed Jun 26 16:03:59 2002
@@ -2364,7 +2364,10 @@
     # For pointers, the address takes the full word (with type info in the
     # lowest two bits). For immediate objects, we use 24 bits for the data
     # (but exclude the highest available bit, which is the garcol_bit).
-    #if !((defined(MC680X0) && defined(UNIX_LINUX)) || (defined(I80386) && defined(UNIX_BEOS)) || (defined(SPARC) && defined(UNIX_LINUX)))
+    #if defined(SPARC) && defined(UNIX_LINUX) && (__GLIBC__ < 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ < 2))
+      #define LINUX_SPARC_OLD_GLIBC
+    #endif
+    #if !((defined(MC680X0) && defined(UNIX_LINUX)) || (defined(I80386) && defined(UNIX_BEOS)) || defined(LINUX_SPARC_OLD_GLIBC))
       #define oint_type_shift 0
       #define oint_type_len 8
       #define oint_type_mask 0x0000007FUL
@@ -2382,9 +2385,10 @@
       #define oint_data_len 24
       #define oint_data_mask 0x3FFFFFC0UL
       #define garcol_bit_o 30
-    #elif (defined(MC680X0) && defined(UNIX_LINUX)) || (defined(SPARC) && defined(UNIX_LINUX))
-      # On Sparc-Linux, malloc()ed addresses are of the form 0x0....... or
-      # 0xe........ Bits 31..29 are therefore part of an address and cannot
+    #elif (defined(MC680X0) && defined(UNIX_LINUX)) || defined(LINUX_SPARC_OLD_GLIBC))
+      # On Sparc-Linux with glibc 2.1 and older:
+      # malloc()ed addresses are of the form 0x0....... or 0xe........
+      # Bits 31..29 are therefore part of an address and cannot
       # be used as garcol_bit. We therefore choose bit 28 as garcol_bit.
       # Now, the 24 data bits of an immediate value must not intersect the
       # garcol_bit, so we use bits 27..4 for that (we could use bits 26..3
@@ -2850,7 +2854,7 @@
   #define immediate_bias  7  # mod 8
 
 # Immediate objects have a second type field.
-  #if defined(SPARC) && defined(UNIX_LINUX)
+  #if defined(LINUX_SPARC_OLD_GLIBC)
     #define imm_type_shift  29
   #else
     #define imm_type_shift  3

---

From: Will Newton <[email-masked]>
Date: Thu Jun 27 09:46:04 2002

> sparc (and probably on m68k) and thus are unavailable...

Looking at lispbibl.d:

  # Overview of use of registers in gcc terminology:
  # fixed: mentioned in FIXED_REGISTERS
  # used:  mentioned in CALL_USED_REGISTERS but not FIXED_REGISTERS
  #                     (i.e. caller-saved)
  # save:  otherwise (i.e. call-preserved, callee-saved)
  #
  #               STACK    mv_count  value1   subr_self
  # MC680X0       used
  # I80386        save
  # SPARC         fixed    fixed     fixed    used

But in the gcc sources it looks like they should be marked "save".
(gcc/gcc/config/sparc/sparc.h)

I'm going to look into how the other arches handle these things.

The comment reads:

/* 1 for registers that have pervasive standard uses
   and are not available for the register allocator.

   On non-v9 systems:
   g1 is free to use as temporary.
   g2-g4 are reserved for applications.  Gcc normally uses them as
   temporaries, but this can be disabled via the -mno-app-regs option.
   g5 through g7 are reserved for the operating system.

   On v9 systems:
   g1,g5 are free to use as temporaries, and are free to use between calls
   if the call is to an external function via the PLT.
   g4 is free to use as a temporary in the non-embedded case.
   g4 is reserved in the embedded case.
   g2-g3 are reserved for applications.  Gcc normally uses them as
   temporaries, but this can be disabled via the -mno-app-regs option.
   g6-g7 are reserved for the operating system (or application in
   embedded case).
   ??? Register 1 is used as a temporary by the 64 bit sethi pattern, so must
   currently be a fixed register until this pattern is rewritten.
   Register 1 is also used when restoring call-preserved registers in large
   stack frames.

---

From: Will Newton <[email-masked]>
Date: Fri Jun 28 03:58:02 2002

> sparc (and probably on m68k) and thus are unavailable...

I've tried playing with which registers are used, but not really got anywhere 
apart from getting the crash one function call later. This reference seems to 
imply there may be a problem using registers with later versions of gcc (and 
I believe the sparc string functions of glibc ):

http://isisesc.supelec.fr/list-egcs/archive/March2000/0055.html