[Mac OS X] LP64 support for Mac OS X 10.4 + G5.

[Mac OS X] LP64 support for Mac OS X 10.4 + G5.

[Nozomu Ando]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

Hello all,

The attached patch is for LP64 support of Emacs CVS HEAD
 on Mac OS X 10.4 + G5.
(But it does not support neither Carbon nor X11 (terminal only)).

Before compiling emacs, you need libncurses for ppc64 architecture:

1. get source files ncurses-15.tar.gz from darwin site and extract it.
	$ curl -O http://www.opensource.apple.com/darwinsource/tarballs/other/ncurses-15.tar.gz
	$ tar xfz ncurses-15.tar.gz

2. make it.
	$ cd ncurses-15
	$ env SRCROOT=`pwd` make

3. copy ppc64 part of libncurses to /usr/lib/libncurses.5.4.dylib
	$ cd /tmp/ncurses/Build/lib
	$ lipo -extract ppc64 libncurses.5.4.dylib -output libncurses.5.4.ppc64
	$ lipo -create /usr/lib/libncurses.5.4.dylib libncurses.5.4.ppc64 -output libncurses.5.4.fat
	$ sudo mv /usr/lib/libncurses.5.4.dylib /usr/lib/libncurses.5.4.dylib.orig && sudo cp -p libncurses.5.4.fat /usr/lib/libncurses.5.4.dylib


Then you can compile emacs:

4. cd .../emacs ; patch -p0 < darwin_lp64_patch.txt

5. ./configure --without-x --without-carbon CC='cc -arch ppc64'

6. make bootstrap


Best Regards,
Nozomu Ando


[-- Attachment #2: darwin_lp64_patch.txt.gz --]
[-- Type: application/octet-stream, Size: 4654 bytes --]

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: [Mac OS X] LP64 support for Mac OS X 10.4 + G5.

[YAMAMOTO Mitsuharu]

Could someone take a look at the following src/alloc.c part of the
LP64 support on Mac OS X 10.4 + G5 by Nozomu Ando?
http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00547.html
(src/unexmacosx.c part is already installed.)

FYI, jmp_buf in this platform is not defined in terms of array of
`long's, but that of `int's.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/alloc.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/alloc.c,v
retrieving revision 1.368
diff -u -r1.368 alloc.c
--- src/alloc.c	20 Apr 2005 07:50:08 -0000	1.368
+++ src/alloc.c	12 May 2005 23:37:51 -0000
@@ -434,7 +434,7 @@
 static int live_float_p P_ ((struct mem_node *, void *));
 static int live_misc_p P_ ((struct mem_node *, void *));
 static void mark_maybe_object P_ ((Lisp_Object));
-static void mark_memory P_ ((void *, void *));
+static void mark_memory P_ ((void *, void *, int));
 static void mem_init P_ ((void));
 static struct mem_node *mem_insert P_ ((void *, void *, enum mem_type));
 static void mem_insert_fixup P_ ((struct mem_node *));
@@ -4139,11 +4139,13 @@
 }
 
 
-/* Mark Lisp objects referenced from the address range START..END.  */
+/* Mark Lisp objects referenced from the address range START+OFFSET..END
+   or END+OFFSET..START. */
 
 static void
-mark_memory (start, end)
+mark_memory (start, end, offset)
      void *start, *end;
+     int offset;
 {
   Lisp_Object *p;
   void **pp;
@@ -4162,7 +4164,7 @@
     }
 
   /* Mark Lisp_Objects.  */
-  for (p = (Lisp_Object *) start; (void *) p < end; ++p)
+  for (p = (Lisp_Object *) ((char *) start + offset); (void *) p < end; ++p)
     mark_maybe_object (*p);
 
   /* Mark Lisp data pointed to.  This is necessary because, in some
@@ -4362,7 +4364,11 @@
 mark_stack ()
 {
   int i;
-  jmp_buf j;
+  /* jmp_buf may not be aligned enough on darwin-ppc64 */
+  union aligned_jmpbuf {
+    Lisp_Object o;
+    jmp_buf j;
+  } j;
   volatile int stack_grows_down_p = (char *) &j > (char *) stack_base;
   void *end;
 
@@ -4393,7 +4399,7 @@
     }
 #endif /* GC_SETJMP_WORKS */
 
-  setjmp (j);
+  setjmp (j.j);
   end = stack_grows_down_p ? (char *) &j + sizeof j : (char *) &j;
 #endif /* not GC_SAVE_REGISTERS_ON_STACK */
 
@@ -4408,7 +4414,7 @@
 #endif
 #endif
   for (i = 0; i < sizeof (Lisp_Object); i += GC_LISP_OBJECT_ALIGNMENT)
-    mark_memory ((char *) stack_base + i, end);
+    mark_memory (stack_base, end, i);
   /* Allow for marking a secondary stack, like the register stack on the
      ia64.  */
 #ifdef GC_MARK_SECONDARY_STACK

Re: [Mac OS X] LP64 support for Mac OS X 10.4 + G5.

[Andreas Schwab]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Could someone take a look at the following src/alloc.c part of the
> LP64 support on Mac OS X 10.4 + G5 by Nozomu Ando?

This breaks hosts where GC_LISP_OBJECT_ALIGNMENT is less than sizeof
Lisp_Object.  Why is the change to make_memory necessary?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: [Mac OS X] LP64 support for Mac OS X 10.4 + G5.

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 11 Nov 2006 11:23:48 +0100, Andreas Schwab <schwab@suse.de> said:

>> Could someone take a look at the following src/alloc.c part of the
>> LP64 support on Mac OS X 10.4 + G5 by Nozomu Ando?

> This breaks hosts where GC_LISP_OBJECT_ALIGNMENT is less than sizeof
> Lisp_Object.  Why is the change to make_memory necessary?

I guess this is for the case that `start' and `end' are exchanged at
the beginning of mark_memory because the stack grows upward.  If that
is correct, maybe we need a similar change also for the second loop in
mark_memory.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: [Mac OS X] LP64 support for Mac OS X 10.4 + G5.

[Richard Stallman]

It looks correct to me.

Discussion of the following change?

[David Kastrup]

Hi,

I see in src/ChangeLog

2006-11-13  Nozomu Ando  <nand@mac.com>

	* alloc.c (mark_memory): New argument OFFSET.  All uses changed.
	Fix address calculations for case END < START.
	(mark_stack): Impose Lisp_Object alignment on jmp_buf.

Uh, this appears like a rather large cross-platform change to me.
Could somebody give me a message id where it had been discussed?  I
seem to have missed this.  Maybe it was under an incomspicuous subject
heading?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Discussion of the following change?

[Juanma Barranquero]

On 11/13/06, David Kastrup <dak@gnu.org> wrote:

> Could somebody give me a message id where it had been discussed?

http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00529.html

which point to this 1+ year old thread:

http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00547.html

                    /L/e/k/t/u

Re: Discussion of the following change?

[David Kastrup]

"Juanma Barranquero" <lekktu@gmail.com> writes:

> On 11/13/06, David Kastrup <dak@gnu.org> wrote:
>
>> Could somebody give me a message id where it had been discussed?
>
> http://lists.gnu.org/archive/html/emacs-devel/2006-11/msg00529.html
>
> which point to this 1+ year old thread:
>
> http://lists.gnu.org/archive/html/emacs-devel/2005-05/msg00547.html

Thanks.  From the title of the thread, I probably thought the patch to
be platform-specific, but it does look like it could affect operation
in general.

So Yamamoto Mitsuharu's request "Could someone take a look at the
following src/alloc.c part of the LP64 support on Mac OS X 10.4 + G5
by Nozomu Ando?" from the newer of the above messages sounds, uh,
quite desirable.

Has the followup question from Andreas Schwab been addressed?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Discussion of the following change?

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 13 Nov 2006 15:02:05 +0100, David Kastrup <dak@gnu.org> said:

> Has the followup question from Andreas Schwab been addressed?

I sent the following message in the thread in question:

>>>>> On Sat, 11 Nov 2006 20:01:28 +0900 (JST), YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>> Could someone take a look at the following src/alloc.c part of the
>>> LP64 support on Mac OS X 10.4 + G5 by Nozomu Ando?

>> This breaks hosts where GC_LISP_OBJECT_ALIGNMENT is less than
>> sizeof Lisp_Object.  Why is the change to make_memory necessary?

> I guess this is for the case that `start' and `end' are exchanged at
> the beginning of mark_memory because the stack grows upward.  If
> that is correct, maybe we need a similar change also for the second
> loop in mark_memory.

The sentences were not affirmative because I didn't confirm the
intention of the author as of the above message.  But with his private
mail, I could do after that.  The patch actually does not break the
case GC_LISP_OBJECT_ALIGNMENT < sizeof Lisp_Object, but fixes it when
the stack grows in the decreasing direction.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp