unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* SuperH port
@ 2008-10-08  9:17 Ulrich Mueller
  2008-10-08 10:37 ` Ulrich Mueller
  2008-10-08 14:31 ` Dan Nicolaescu
  0 siblings, 2 replies; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-08  9:17 UTC (permalink / raw)
  To: emacs-devel; +Cc: sh, emacs

Hello,

please find below a patch that ports Emacs to SuperH running GNU/Linux.
(Thanks to the Gentoo SuperH architecture team, especially Raúl Porcel
for his help with testing.)

I've also restored the two alternatives in configure.in for
shle-*-netbsd and sh-*-openbsd which were deleted in the recent
"desupport old platforms" campaign.

Ulrich


emacs/ChangeLog entry:

2008-10-01  Ulrich Mueller  <ulm@gentoo.org>

	* configure.in: Add support for GNU/Linux on SuperH.
	Restore deleted shle-*-netbsd and sh-*-openbsd alternatives.

emacs/etc/ChangeLog entry:

2008-10-01  Ulrich Mueller  <ulm@gentoo.org>

	* MACHINES: Add section for SuperH.

emacs/src/ChangeLog entry:

2008-10-01  Ulrich Mueller  <ulm@gentoo.org>

	* m/sh3el.h: Restore deleted file for SuperH support.
	(WORD_MACHINE, NO_UNION_TYPE): Remove obsolete definitions.
	* m/sh3eb.h: New file.


--- emacs-orig/configure.in	2008-08-28 22:31:27.000000000 +0200
+++ emacs/configure.in	2008-10-01 07:21:49.000000000 +0200
@@ -335,6 +335,7 @@
       arm-*-netbsd*)	machine=arm ;;
       x86_64-*-netbsd*)	machine=amdx86-64 ;;
       hppa-*-netbsd*)	machine=hp800 ;;
+      shle-*-netbsd*)	machine=sh3el ;;
     esac
   ;;
 
@@ -346,6 +347,7 @@
       arm-*-openbsd*)          machine=arm ;;
       i386-*-openbsd*)         machine=intel386 ;;
       powerpc-*-openbsd*)      machine=macppc ;;
+      sh-*-openbsd*)           machine=sh3el ;;
       sparc*-*-openbsd*)       machine=sparc ;;
       vax-*-openbsd*)          machine=vax ;;
       x86_64-*-openbsd*)       machine=amdx86-64 ;;
@@ -540,6 +542,16 @@
     machine=xtensa opsys=gnu-linux
     ;;
 
+  ## SuperH (little endian) Linux-based GNU system
+  sh[34]-*-linux-gnu* )
+    machine=sh3el opsys=gnu-linux
+  ;;
+
+  ## SuperH (big endian) Linux-based GNU system
+  sh[34]eb-*-linux-gnu* )
+    machine=sh3eb opsys=gnu-linux
+  ;;
+
   * )
     unported=yes
   ;;
--- emacs-orig/etc/MACHINES	2008-08-01 23:44:40.000000000 +0200
+++ emacs/etc/MACHINES	2008-10-01 07:22:52.000000000 +0200
@@ -426,6 +426,14 @@
   (now remapped as part of the text).  These are never
   swapped in.
 
+SuperH (sh*-*-linux-gnu, shle-*-netbsd, sh-*-openbsd)
+
+  Emacs 23.0.60 was reported to work on GNU/Linux (October 2008).
+  Tested on a little-endian sh4 system (cpu type SH7751R) running
+  Gentoo Linux 2008.0.
+
+  Status of SuperH support on NetBSD and OpenBSD is unknown.
+
 Tadpole 68K (m68k-tadpole-sysv)
 
   Changes merged in 19.1.
@@ -575,7 +581,6 @@
   PFU A-series (m/pfa50.h)
   Plexus running System V.2 (m/plexus.h)
   pyramid. (m/pyramid.h)
-  sh3el (m/sh3el.h)
   Bull SPS-7 (m/sps7.h)
   Hitachi SR2001/SR2201 (m/sr2k.h)
   Stride (m/stride.h)
--- emacs-orig/src/m/sh3eb.h	1970-01-01 01:00:00.000000000 +0100
+++ emacs/src/m/sh3eb.h	2008-10-01 07:20:54.000000000 +0200
@@ -0,0 +1,7 @@
+/* machine description file for big-endian SuperH. */
+
+#include "sh3el.h"
+#define WORDS_BIG_ENDIAN
+
+/* arch-tag: 86a90028-8f70-11dd-ac16-0012f098dd76
+   (do not change this comment) */
--- emacs-orig/src/m/sh3el.h	1970-01-01 01:00:00.000000000 +0100
+++ emacs/src/m/sh3el.h	2008-10-01 07:20:41.000000000 +0200
@@ -0,0 +1,92 @@
+/* machine description file for little-endian SuperH.
+   Copyright (C) 1985, 1986, 2006, 2007, 2008  Free Software Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
+
+
+/* The following line tells the configuration script what sort of
+   operating system this machine is likely to run.
+   USUAL-OPSYS="<name of system .h file here, without the s- or .h>"  */
+
+/* Define WORDS_BIG_ENDIAN if lowest-numbered byte in a word
+   is the most significant byte.  */
+
+#undef WORDS_BIG_ENDIAN
+
+/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
+ * group of arguments and treat it as an array of the arguments.  */
+
+#define NO_ARG_ARRAY
+
+/* Now define a symbol for the cpu type, if your compiler
+   does not define it automatically.  */
+
+/* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend
+   the 24-bit bit field into an int.  In other words, if bit fields
+   are always unsigned.
+
+   This flag only matters if you use USE_LISP_UNION_TYPE.  */
+
+#define EXPLICIT_SIGN_EXTEND
+
+/* Data type of load average, as read out of kmem.  */
+
+#define LOAD_AVE_TYPE long
+
+/* Convert that into an integer that is 100 for a load average of 1.0  */
+
+#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE)
+
+/* Define CANNOT_DUMP on machines where unexec does not work.
+   Then the function dump-emacs will not be defined
+   and temacs will do (load "loadup") automatically unless told otherwise.  */
+
+#undef CANNOT_DUMP
+
+/* Define VIRT_ADDR_VARIES if the virtual addresses of
+   pure and impure space as loaded can vary, and even their
+   relative order cannot be relied on.
+
+   Otherwise Emacs assumes that text space precedes data space,
+   numerically.  */
+
+#define VIRT_ADDR_VARIES
+
+/* Define HAVE_ALLOCA to say that the system provides a properly
+   working alloca function and it should be used.
+   Undefine it if an assembler-language alloca
+   in the file alloca.s should be used.  */
+
+#define HAVE_ALLOCA
+
+/* Define NO_REMAP if memory segmentation makes it not work well
+   to change the boundary between the text section and data section
+   when Emacs is dumped.  If you define this, the preloaded Lisp
+   code will not be sharable; but that's better than failing completely.  */
+
+#define NO_REMAP
+
+/* After adding support for a new system, modify the large case
+   statement in the `configure' script to recognize reasonable
+   configuration names, and add a description of the system to
+   `etc/MACHINES'.
+
+   If you've just fixed a problem in an existing configuration file,
+   you should also check `etc/MACHINES' to make sure its descriptions
+   of known problems in that configuration should be updated.  */
+
+/* arch-tag: ee325990-6f40-47a2-b9df-60ecf3599899
+   (do not change this comment) */




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-08  9:17 SuperH port Ulrich Mueller
@ 2008-10-08 10:37 ` Ulrich Mueller
  2008-10-08 14:31 ` Dan Nicolaescu
  1 sibling, 0 replies; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-08 10:37 UTC (permalink / raw)
  To: emacs-devel

>>>>> I wrote:

> please find below a patch that ports Emacs to SuperH running GNU/Linux.

I forgot to mention, for the new sh3eb.h file I've generated an
arch-tag myself (using uuidgen). I hope this is O.K.

Ulrich




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-08  9:17 SuperH port Ulrich Mueller
  2008-10-08 10:37 ` Ulrich Mueller
@ 2008-10-08 14:31 ` Dan Nicolaescu
  2008-10-08 18:22   ` Ulrich Mueller
  2008-10-09 10:24   ` Ulrich Mueller
  1 sibling, 2 replies; 17+ messages in thread
From: Dan Nicolaescu @ 2008-10-08 14:31 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: sh, emacs, emacs-devel

Ulrich Mueller <ulm@gentoo.org> writes:

  > Hello,
  > 
  > please find below a patch that ports Emacs to SuperH running GNU/Linux.
  > (Thanks to the Gentoo SuperH architecture team, especially Raúl Porcel
  > for his help with testing.)
  > 
  > I've also restored the two alternatives in configure.in for
  > shle-*-netbsd and sh-*-openbsd which were deleted in the recent
  > "desupport old platforms" campaign.

Given this from your patch:

  > +  Status of SuperH support on NetBSD and OpenBSD is unknown.
  > +

Please do not wily nilly add them back, removing stuff is not something
we take lightly, so we should not be adding back things that are not
known to work, nor were requested by actual users.

  > +  ## SuperH (little endian) Linux-based GNU system
  > +  sh[34]-*-linux-gnu* )
  > +    machine=sh3el opsys=gnu-linux
  > +  ;;
  > +
  > +  ## SuperH (big endian) Linux-based GNU system
  > +  sh[34]eb-*-linux-gnu* )
  > +    machine=sh3eb opsys=gnu-linux
  > +  ;;

Were both endian versions tested?
Why have two files, only a single macro should be different between
them, and it can be conditionally defined.

Simply adding the file back is not OK, work has been done to clean up
and simplify these files.

  > +/* Define WORDS_BIG_ENDIAN if lowest-numbered byte in a word
  > +   is the most significant byte.  */
  > +
  > +#undef WORDS_BIG_ENDIAN

This should be conditionally defined.


  > +
  > +/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
  > + * group of arguments and treat it as an array of the arguments.  */
  > +
  > +#define NO_ARG_ARRAY
  > +
  > +/* Now define a symbol for the cpu type, if your compiler
  > +   does not define it automatically.  */
  > +
  > +/* Define EXPLICIT_SIGN_EXTEND if XINT must explicitly sign-extend
  > +   the 24-bit bit field into an int.  In other words, if bit fields
  > +   are always unsigned.
  > +
  > +   This flag only matters if you use USE_LISP_UNION_TYPE.  */
  > +
  > +#define EXPLICIT_SIGN_EXTEND

Is this needed?  Please test without it.


  > +/* Data type of load average, as read out of kmem.  */
  > +
  > +#define LOAD_AVE_TYPE long
  > +
  > +/* Convert that into an integer that is 100 for a load average of 1.0  */
  > +
  > +#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE)

These are not needed for GNU/Linux, remove them.

  > +/* Define CANNOT_DUMP on machines where unexec does not work.
  > +   Then the function dump-emacs will not be defined
  > +   and temacs will do (load "loadup") automatically unless told otherwise.  */
  > +
  > +#undef CANNOT_DUMP

Not needed.

  > +/* Define VIRT_ADDR_VARIES if the virtual addresses of
  > +   pure and impure space as loaded can vary, and even their
  > +   relative order cannot be relied on.
  > +
  > +   Otherwise Emacs assumes that text space precedes data space,
  > +   numerically.  */
  > +
  > +#define VIRT_ADDR_VARIES

Is this needed?  Please test without it.



  > +/* Define HAVE_ALLOCA to say that the system provides a properly
  > +   working alloca function and it should be used.
  > +   Undefine it if an assembler-language alloca
  > +   in the file alloca.s should be used.  */
  > +
  > +#define HAVE_ALLOCA


Remove.

  > +/* Define NO_REMAP if memory segmentation makes it not work well
  > +   to change the boundary between the text section and data section
  > +   when Emacs is dumped.  If you define this, the preloaded Lisp
  > +   code will not be sharable; but that's better than failing completely.  */
  > +
  > +#define NO_REMAP

This is not needed.




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-08 14:31 ` Dan Nicolaescu
@ 2008-10-08 18:22   ` Ulrich Mueller
  2008-10-08 18:47     ` Stefan Monnier
  2008-10-09 10:24   ` Ulrich Mueller
  1 sibling, 1 reply; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-08 18:22 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: sh, emacs-devel, emacs

>>>>> On Wed, 8 Oct 2008, Dan Nicolaescu wrote:

> Given this from your patch:

>> +  Status of SuperH support on NetBSD and OpenBSD is unknown.

> Please do not wily nilly add them back, removing stuff is not something
> we take lightly, so we should not be adding back things that are not
> known to work, nor were requested by actual users.

These are just alternatives in case statements (two lines). No problem
to remove them, but OTOH I think they cannot do any harm.

Also, support for BSD on SuperH had been added less then two years
ago, so why would you expect it to be broken? Especially, since apart
from configure and the machine definition, nothing else is affected.

2006-12-22  Mark Davies  <mark@mcs.vuw.ac.nz>

	* configure.in: Add support for NetBSD on x86-64, hp800 and sh3el.

>> +  ## SuperH (little endian) Linux-based GNU system
>> +  sh[34]-*-linux-gnu* )
>> +    machine=sh3el opsys=gnu-linux
>> +  ;;
>> +
>> +  ## SuperH (big endian) Linux-based GNU system
>> +  sh[34]eb-*-linux-gnu* )
>> +    machine=sh3eb opsys=gnu-linux
>> +  ;;

> Were both endian versions tested?
> Why have two files, only a single macro should be different between
> them, and it can be conditionally defined.

No other machine file does this. But maybe it is a good idea to get
rid of WORDS_BIG_ENDIAN in general, given the following comment in
configure.in:

dnl This could be used for targets which can have both byte sexes.
dnl We could presumably replace the hardwired WORDS_BIG_ENDIAN generally.
dnl AC_C_BIGENDIAN

> Simply adding the file back is not OK, work has been done to clean up
> and simplify these files.

<rant> That work would have been better invested to get rid of the
antediluvian build system with its hardwired config files. </rant>

And if you had done a diff to the file in the CVS attic, then you
would have noticed that I already did some cleanup to bring the file
in line with the changes in the other machine files. Of course it is
possible that I've missed something.

>> +#define LOAD_AVE_TYPE long
>> +#define LOAD_AVE_CVT(x) (int) (((double) (x)) * 100.0 / FSCALE)

> These are not needed for GNU/Linux, remove them.

As far as I understand it, the m/*.h files are supposed to be OS
independent?

Concerning EXPLICIT_SIGN_EXTEND, CANNOT_DUMP, VIRT_ADDR_VARIES,
HAVE_ALLOCA, and NO_REMAP, I'll remove the corresponding lines and
have it tested again.

However, from your rather discouraging reply I have the impression
that this port is not wanted?

Best regards
Ulrich




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-08 18:22   ` Ulrich Mueller
@ 2008-10-08 18:47     ` Stefan Monnier
  2008-10-15 21:16       ` Ulrich Mueller
  0 siblings, 1 reply; 17+ messages in thread
From: Stefan Monnier @ 2008-10-08 18:47 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: emacs, sh, Dan Nicolaescu, emacs-devel

> dnl This could be used for targets which can have both byte sexes.
> dnl We could presumably replace the hardwired WORDS_BIG_ENDIAN generally.
> dnl AC_C_BIGENDIAN

This would be a welcome change, indeed.

> However, from your rather discouraging reply I have the impression
> that this port is not wanted?

This port is wanted.  Thank you for your effort to bring it back to
life.  Could someone install his change (and clean it up where
appropriate)?


        Stefan





^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-08 14:31 ` Dan Nicolaescu
  2008-10-08 18:22   ` Ulrich Mueller
@ 2008-10-09 10:24   ` Ulrich Mueller
  1 sibling, 0 replies; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-09 10:24 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: sh, emacs, emacs-devel

>>>>> On Wed, 8 Oct 2008, Dan Nicolaescu wrote:

>> +#define EXPLICIT_SIGN_EXTEND
> Is this needed?  Please test without it.

>> +#define VIRT_ADDR_VARIES
> Is this needed?  Please test without it.

Tested again, and it also works with both lines changed to #undef.

Ulrich




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-08 18:47     ` Stefan Monnier
@ 2008-10-15 21:16       ` Ulrich Mueller
  2008-10-15 21:36         ` Dan Nicolaescu
  0 siblings, 1 reply; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-15 21:16 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs, sh, Dan Nicolaescu, emacs-devel

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 916 bytes --]

>>>>> On Wed, 08 Oct 2008, Stefan Monnier wrote:

> This port is wanted.  Thank you for your effort to bring it back to
> life.  Could someone install his change (and clean it up where
> appropriate)?

Please find an updated patch below, addressing most of Dan's
criticism:

- Support for NetBSD and OpenBSD has been removed since its status is
  unknown.
- Definitions of EXPLICIT_SIGN_EXTEND, VIRT_ADDR_VARIES and other
  unneccessary macros have been deleted.

However, I've left both files m/sh3el.h and m/sh3eb.h in for now,
since conditional definition of WORDS_BIG_ENDIAN would probably
require an autoconf test for endian.h. And then it's IMHO preferable
to use AC_C_BIGENDIAN instead.

>> dnl This could be used for targets which can have both byte sexes.
>> dnl We could presumably replace the hardwired WORDS_BIG_ENDIAN generally.
>> dnl AC_C_BIGENDIAN

> This would be a welcome change, indeed.

Ulrich


[-- Attachment #2: emacs-cvs-sh.patch --]
[-- Type: text/plain, Size: 3380 bytes --]

emacs/ChangeLog entry:

2008-10-15  Ulrich Mueller  <ulm@gentoo.org>

	* configure.in: Add support for GNU/Linux on SuperH.

emacs/etc/ChangeLog entry:

2008-10-15  Ulrich Mueller  <ulm@gentoo.org>

	* MACHINES: Add section for SuperH.

emacs/src/ChangeLog entry:

2008-10-15  Ulrich Mueller  <ulm@gentoo.org>

	* m/sh3el.h: Restore deleted file for SuperH support.
	(WORD_MACHINE, NO_UNION_TYPE, EXPLICIT_SIGN_EXTEND)
	(LOAD_AVE_TYPE, LOAD_AVE_CVT, CANNOT_DUMP, VIRT_ADDR_VARIES)
	(HAVE_ALLOCA, NO_REMAP): Remove obsolete or unneeded definitions.
	* m/sh3eb.h: New file.


--- emacs-orig/configure.in	2008-08-28 22:31:27.000000000 +0200
+++ emacs/configure.in	2008-10-01 07:21:49.000000000 +0200
@@ -540,6 +540,16 @@
     machine=xtensa opsys=gnu-linux
     ;;
 
+  ## SuperH (little endian) Linux-based GNU system
+  sh[34]-*-linux-gnu* )
+    machine=sh3el opsys=gnu-linux
+  ;;
+
+  ## SuperH (big endian) Linux-based GNU system
+  sh[34]eb-*-linux-gnu* )
+    machine=sh3eb opsys=gnu-linux
+  ;;
+
   * )
     unported=yes
   ;;
--- emacs-orig/etc/MACHINES	2008-08-01 23:44:40.000000000 +0200
+++ emacs/etc/MACHINES	2008-10-01 07:22:52.000000000 +0200
@@ -426,6 +426,12 @@
   (now remapped as part of the text).  These are never
   swapped in.
 
+SuperH (sh[34]*-*-linux-gnu)
+
+  Emacs 23.0.60 was reported to work on GNU/Linux (October 2008).
+  Tested on a little-endian sh4 system (cpu type SH7751R) running
+  Gentoo Linux 2008.0.
+
 Tadpole 68K (m68k-tadpole-sysv)
 
   Changes merged in 19.1.
@@ -575,7 +581,6 @@
   PFU A-series (m/pfa50.h)
   Plexus running System V.2 (m/plexus.h)
   pyramid. (m/pyramid.h)
-  sh3el (m/sh3el.h)
   Bull SPS-7 (m/sps7.h)
   Hitachi SR2001/SR2201 (m/sr2k.h)
   Stride (m/stride.h)
--- emacs-orig/src/m/sh3eb.h	1970-01-01 01:00:00.000000000 +0100
+++ emacs/src/m/sh3eb.h	2008-10-01 07:20:54.000000000 +0200
@@ -0,0 +1,7 @@
+/* machine description file for big-endian SuperH. */
+
+#include "sh3el.h"
+#define WORDS_BIG_ENDIAN
+
+/* arch-tag: 86a90028-8f70-11dd-ac16-0012f098dd76
+   (do not change this comment) */
--- emacs-orig/src/m/sh3el.h	1970-01-01 01:00:00.000000000 +0100
+++ emacs/src/m/sh3el.h	2008-10-01 07:20:41.000000000 +0200
@@ -0,0 +1,31 @@
+/* machine description file for little-endian SuperH.
+   Copyright (C) 1985, 1986, 2006, 2007, 2008  Free Software Foundation, Inc.
+
+This file is part of GNU Emacs.
+
+GNU Emacs is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+GNU Emacs is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
+
+
+/* Define WORDS_BIG_ENDIAN if lowest-numbered byte in a word
+   is the most significant byte.  */
+
+#undef WORDS_BIG_ENDIAN
+
+/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
+ * group of arguments and treat it as an array of the arguments.  */
+
+#define NO_ARG_ARRAY
+
+/* arch-tag: ee325990-6f40-47a2-b9df-60ecf3599899
+   (do not change this comment) */

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-15 21:16       ` Ulrich Mueller
@ 2008-10-15 21:36         ` Dan Nicolaescu
  2008-10-16 16:04           ` Ulrich Mueller
  0 siblings, 1 reply; 17+ messages in thread
From: Dan Nicolaescu @ 2008-10-15 21:36 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: sh, emacs, Stefan Monnier, emacs-devel

Ulrich Mueller <ulm@gentoo.org> writes:

  > >>>>> On Wed, 08 Oct 2008, Stefan Monnier wrote:
  > 
  > > This port is wanted.  Thank you for your effort to bring it back to
  > > life.  Could someone install his change (and clean it up where
  > > appropriate)?
  > 
  > Please find an updated patch below, addressing most of Dan's
  > criticism:
  > 
  > - Support for NetBSD and OpenBSD has been removed since its status is
  >   unknown.
  > - Definitions of EXPLICIT_SIGN_EXTEND, VIRT_ADDR_VARIES and other
  >   unneccessary macros have been deleted.
  > 
  > However, I've left both files m/sh3el.h and m/sh3eb.h in for now,

Please don't, we already have a precedent on how to do this, inventing
yet another style just creates more work for when things are going to be
cleaned up later to use an autoconf test.

Isn't there a symbol that the compiler defines differently for
big/little endian?  See what mips.h does:

#if ! (defined (__MIPSEL__) || defined (MIPSEL) || defined (_MIPSEL))
#define WORDS_BIG_ENDIAN
#endif


  > +SuperH (sh[34]*-*-linux-gnu)
  > +
  > +  Emacs 23.0.60 was reported to work on GNU/Linux (October 2008).
  > +  Tested on a little-endian sh4 system (cpu type SH7751R) running
  > +  Gentoo Linux 2008.0.

No big endian testing?

  > --- emacs-orig/src/m/sh3el.h	1970-01-01 01:00:00.000000000 +0100
  > +++ emacs/src/m/sh3el.h	2008-10-01 07:20:41.000000000 +0200
  > @@ -0,0 +1,31 @@
  > +/* machine description file for little-endian SuperH.
  > +   Copyright (C) 1985, 1986, 2006, 2007, 2008  Free Software Foundation, Inc.
  > +
  > +This file is part of GNU Emacs.
  > +
  > +GNU Emacs is free software: you can redistribute it and/or modify
  > +it under the terms of the GNU General Public License as published by
  > +the Free Software Foundation, either version 3 of the License, or
  > +(at your option) any later version.
  > +
  > +GNU Emacs is distributed in the hope that it will be useful,
  > +but WITHOUT ANY WARRANTY; without even the implied warranty of
  > +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  > +GNU General Public License for more details.
  > +
  > +You should have received a copy of the GNU General Public License
  > +along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */

No need for the copyright notice, the file is just 2 lines of code, it
would become 4 with the endianess test.




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-15 21:36         ` Dan Nicolaescu
@ 2008-10-16 16:04           ` Ulrich Mueller
  2008-10-17  6:04             ` Dan Nicolaescu
  0 siblings, 1 reply; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-16 16:04 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: sh, emacs, Stefan Monnier, emacs-devel

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 437 bytes --]

>>>>> On Wed, 15 Oct 2008, Dan Nicolaescu wrote:

> Isn't there a symbol that the compiler defines differently for
> big/little endian?

I don't know about the compiler, but glibc's header files define
__BYTE_ORDER. I've attached a solution that was tested on GNU/Linux,
but should also work on BSD.

> No big endian testing?

Not yet.

> No need for the copyright notice,

O.K.

"Take 3" of the patch is attached.

Best regards
Ulrich


[-- Attachment #2: emacs-cvs-sh.patch --]
[-- Type: text/plain, Size: 2087 bytes --]

emacs/ChangeLog entry:

2008-10-16  Ulrich Mueller  <ulm@gentoo.org>

	* configure.in: Add support for GNU/Linux on SuperH.

emacs/etc/ChangeLog entry:

2008-10-16  Ulrich Mueller  <ulm@gentoo.org>

	* MACHINES: Add section for SuperH.

emacs/src/ChangeLog entry:

2008-10-16  Ulrich Mueller  <ulm@gentoo.org>

	* m/sh3.h: New file, machine description for SuperH.


--- emacs-orig/configure.in	2008-08-28 22:31:27.000000000 +0200
+++ emacs/configure.in	2008-10-16 17:27:37.000000000 +0200
@@ -540,6 +540,11 @@
     machine=xtensa opsys=gnu-linux
     ;;
 
+  ## SuperH Linux-based GNU system
+  sh[34]*-*-linux-gnu* )
+    machine=sh3 opsys=gnu-linux
+  ;;
+
   * )
     unported=yes
   ;;
--- emacs-orig/etc/MACHINES	2008-08-01 23:44:40.000000000 +0200
+++ emacs/etc/MACHINES	2008-10-16 17:27:37.000000000 +0200
@@ -426,6 +426,12 @@
   (now remapped as part of the text).  These are never
   swapped in.
 
+SuperH (sh[34]*-*-linux-gnu)
+
+  Emacs 23.0.60 was reported to work on GNU/Linux (October 2008).
+  Tested on a little-endian sh4 system (cpu type SH7751R) running
+  Gentoo Linux 2008.0.
+
 Tadpole 68K (m68k-tadpole-sysv)
 
   Changes merged in 19.1.
--- emacs-orig/src/m/sh3.h	1970-01-01 01:00:00.000000000 +0100
+++ emacs/src/m/sh3.h	2008-10-16 17:27:37.000000000 +0200
@@ -0,0 +1,24 @@
+/* Machine description file for SuperH. */
+
+#include <sys/param.h>
+
+/* Define WORDS_BIG_ENDIAN if lowest-numbered byte in a word
+   is the most significant byte.  */
+
+#if (defined (__BYTE_ORDER) && __BYTE_ORDER == __LITTLE_ENDIAN) \
+  || (defined (BYTE_ORDER) && BYTE_ORDER == LITTLE_ENDIAN)
+# undef WORDS_BIG_ENDIAN
+#elif (defined (__BYTE_ORDER) && __BYTE_ORDER == __BIG_ENDIAN) \
+  || (defined (BYTE_ORDER) && BYTE_ORDER == BIG_ENDIAN)
+# define WORDS_BIG_ENDIAN
+#else
+# error "cannot determine byte sex"
+#endif
+
+/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
+   group of arguments and treat it as an array of the arguments.  */
+
+#define NO_ARG_ARRAY
+
+/* arch-tag: c997297c-9b92-11dd-b25e-0012f098dd76
+   (do not change this comment) */

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-16 16:04           ` Ulrich Mueller
@ 2008-10-17  6:04             ` Dan Nicolaescu
  2008-10-17 20:26               ` Ulrich Mueller
  0 siblings, 1 reply; 17+ messages in thread
From: Dan Nicolaescu @ 2008-10-17  6:04 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: sh, emacs, Stefan Monnier, emacs-devel

Ulrich Mueller <ulm@gentoo.org> writes:

  > >>>>> On Wed, 15 Oct 2008, Dan Nicolaescu wrote:
  > 
  > > Isn't there a symbol that the compiler defines differently for
  > > big/little endian?
  > 
  > I don't know about the compiler, but glibc's header files define
  > __BYTE_ORDER. I've attached a solution that was tested on GNU/Linux,
  > but should also work on BSD.

I would not be so sure without checking.
Do you have access to compilers for both big and little endian? 
If yes, you can look at the difference between the output of:

gcc -xc -E -dM /dev/null

On all the machines that I am aware off that support both big and little
endian the compiler predefines a symbol to distinguish between them.

I'll install this when the endianess issue gets resolved.




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-17  6:04             ` Dan Nicolaescu
@ 2008-10-17 20:26               ` Ulrich Mueller
  2008-10-17 22:25                 ` Andreas Schwab
  2008-10-18  8:12                 ` Dan Nicolaescu
  0 siblings, 2 replies; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-17 20:26 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: sh, emacs, Stefan Monnier, emacs-devel

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 816 bytes --]

>>>>> On Thu, 16 Oct 2008, Dan Nicolaescu wrote:

> On all the machines that I am aware off that support both big and
> little endian the compiler predefines a symbol to distinguish
> between them.

It turns out that gcc defines __LITTLE_ENDIAN__ and __BIG_ENDIAN__,
respectively:

   $ echo | sh4-gentoo-linux-uclibc-gcc -nostdinc -dM -E - | grep ENDIAN
   __LITTLE_ENDIAN__

(To add some confusion, endian.h then also defines _all_ four of
__LITTLE_ENDIAN, LITTLE_ENDIAN, __BIG_ENDIAN, and BIG_ENDIAN,
regardless of the machine's byte sex. Go figure.)

> I'll install this when the endianess issue gets resolved.

I still think that my previous approach (include sys/param.h and
test for __BYTE_ORDER) was cleaner. But if you absolutely want a
compiler-defined symbol, an updated patch is included below.

Ulrich


[-- Attachment #2: emacs-cvs-sh.patch --]
[-- Type: text/plain, Size: 1937 bytes --]

emacs/ChangeLog entry:

2008-10-16  Ulrich Mueller  <ulm@gentoo.org>

	* configure.in: Add support for GNU/Linux on SuperH.

emacs/etc/ChangeLog entry:

2008-10-16  Ulrich Mueller  <ulm@gentoo.org>

	* MACHINES: Add section for SuperH.

emacs/src/ChangeLog entry:

2008-10-16  Ulrich Mueller  <ulm@gentoo.org>

	* m/sh3.h: New file, machine description for SuperH.


--- emacs-orig/configure.in	2008-08-28 22:31:27.000000000 +0200
+++ emacs/configure.in	2008-10-16 17:27:37.000000000 +0200
@@ -540,6 +540,11 @@
     machine=xtensa opsys=gnu-linux
     ;;
 
+  ## SuperH Linux-based GNU system
+  sh[34]*-*-linux-gnu* )
+    machine=sh3 opsys=gnu-linux
+  ;;
+
   * )
     unported=yes
   ;;
--- emacs-orig/etc/MACHINES	2008-08-01 23:44:40.000000000 +0200
+++ emacs/etc/MACHINES	2008-10-16 17:27:37.000000000 +0200
@@ -426,6 +426,12 @@
   (now remapped as part of the text).  These are never
   swapped in.
 
+SuperH (sh[34]*-*-linux-gnu)
+
+  Emacs 23.0.60 was reported to work on GNU/Linux (October 2008).
+  Tested on a little-endian sh4 system (cpu type SH7751R) running
+  Gentoo Linux 2008.0.
+
 Tadpole 68K (m68k-tadpole-sysv)
 
   Changes merged in 19.1.
--- emacs-orig/src/m/sh3.h	1970-01-01 01:00:00.000000000 +0100
+++ emacs/src/m/sh3.h	2008-10-16 17:27:37.000000000 +0200
@@ -0,0 +1,20 @@
+/* Machine description file for SuperH. */
+
+/* Define WORDS_BIG_ENDIAN if lowest-numbered byte in a word
+   is the most significant byte.  */
+
+#if defined (__LITTLE_ENDIAN__) && !defined (__BIG_ENDIAN__)
+# undef WORDS_BIG_ENDIAN
+#elif defined (__BIG_ENDIAN__) && !defined (__LITTLE_ENDIAN__)
+# define WORDS_BIG_ENDIAN
+#else
+# error "cannot determine byte sex"
+#endif
+
+/* Define NO_ARG_ARRAY if you cannot take the address of the first of a
+   group of arguments and treat it as an array of the arguments.  */
+
+#define NO_ARG_ARRAY
+
+/* arch-tag: c997297c-9b92-11dd-b25e-0012f098dd76
+   (do not change this comment) */

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-17 20:26               ` Ulrich Mueller
@ 2008-10-17 22:25                 ` Andreas Schwab
  2008-10-17 22:56                   ` Ulrich Mueller
  2008-10-18  8:39                   ` Ulrich Mueller
  2008-10-18  8:12                 ` Dan Nicolaescu
  1 sibling, 2 replies; 17+ messages in thread
From: Andreas Schwab @ 2008-10-17 22:25 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: sh, Dan Nicolaescu, emacs-devel, Stefan Monnier, emacs

Ulrich Mueller <ulm@gentoo.org> writes:

> (To add some confusion, endian.h then also defines _all_ four of
> __LITTLE_ENDIAN, LITTLE_ENDIAN, __BIG_ENDIAN, and BIG_ENDIAN,
> regardless of the machine's byte sex. Go figure.)

There is nothing wrong with that.  They define the valid values for
BYTE_ORDER.

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."




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-17 22:25                 ` Andreas Schwab
@ 2008-10-17 22:56                   ` Ulrich Mueller
  2008-10-18  8:39                   ` Ulrich Mueller
  1 sibling, 0 replies; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-17 22:56 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: sh, Dan Nicolaescu, emacs-devel, Stefan Monnier, emacs

>>>>> On Sat, 18 Oct 2008, Andreas Schwab wrote:

>> (To add some confusion, endian.h then also defines _all_ four of
>> __LITTLE_ENDIAN, LITTLE_ENDIAN, __BIG_ENDIAN, and BIG_ENDIAN,
>> regardless of the machine's byte sex. Go figure.)

> There is nothing wrong with that. They define the valid values for
> BYTE_ORDER.

Of course there's nothing wrong. But I think it's a bit awkward that
the same names are used for different purposes.

<offtopic>
On Powerpc, it's a complete mess: gcc defines both __BIG_ENDIAN__ and
_BIG_ENDIAN, and endian.h defines the four above-mentioned macros. ;-)
</offtopic>

Ulrich




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-17 20:26               ` Ulrich Mueller
  2008-10-17 22:25                 ` Andreas Schwab
@ 2008-10-18  8:12                 ` Dan Nicolaescu
  2008-12-11  7:20                   ` Ulrich Mueller
  1 sibling, 1 reply; 17+ messages in thread
From: Dan Nicolaescu @ 2008-10-18  8:12 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: sh, emacs, Stefan Monnier, emacs-devel

Ulrich Mueller <ulm@gentoo.org> writes:

  > emacs/ChangeLog entry:
  > 
  > 2008-10-16  Ulrich Mueller  <ulm@gentoo.org>
  > 
  > 	* configure.in: Add support for GNU/Linux on SuperH.
  > 
  > emacs/etc/ChangeLog entry:
  > 
  > 2008-10-16  Ulrich Mueller  <ulm@gentoo.org>
  > 
  > 	* MACHINES: Add section for SuperH.
  > 
  > emacs/src/ChangeLog entry:
  > 
  > 2008-10-16  Ulrich Mueller  <ulm@gentoo.org>
  > 
  > 	* m/sh3.h: New file, machine description for SuperH.

Thank you, I checked in a slightly simplified version of this.




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-17 22:25                 ` Andreas Schwab
  2008-10-17 22:56                   ` Ulrich Mueller
@ 2008-10-18  8:39                   ` Ulrich Mueller
  1 sibling, 0 replies; 17+ messages in thread
From: Ulrich Mueller @ 2008-10-18  8:39 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: sh, Dan Nicolaescu, emacs-devel, Stefan Monnier, emacs

>>>>> On Sat, 18 Oct 2008, Andreas Schwab wrote:

>> (To add some confusion, endian.h then also defines _all_ four of
>> __LITTLE_ENDIAN, LITTLE_ENDIAN, __BIG_ENDIAN, and BIG_ENDIAN,
>> regardless of the machine's byte sex. Go figure.)

> There is nothing wrong with that.  They define the valid values for
> BYTE_ORDER.

I just noticed that m/xtensa.h is testing for __LITTLE_ENDIAN to
determine byte order. Either this is not right, or it's a
compiler-defined symbol there ...

Ulrich




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-10-18  8:12                 ` Dan Nicolaescu
@ 2008-12-11  7:20                   ` Ulrich Mueller
  2008-12-11  7:58                     ` Dan Nicolaescu
  0 siblings, 1 reply; 17+ messages in thread
From: Ulrich Mueller @ 2008-12-11  7:20 UTC (permalink / raw)
  To: Dan Nicolaescu; +Cc: emacs, Stefan Monnier, emacs-devel

>>>>> On Sat, 18 Oct 2008, Dan Nicolaescu wrote:

>> 2008-10-16  Ulrich Mueller  <ulm@gentoo.org>
>> 
>> * m/sh3.h: New file, machine description for SuperH.

> Thank you, I checked in a slightly simplified version of this.

I just noticed that etc/MACHINES still contains the following entry
under "Support for the following obsolete platforms was removed in
Emacs 23.1":

  sh3el (m/sh3el.h)

I wonder if this line should be removed, since sh3el is supported.
(The file sh3el.h was removed of course, or rather it has been
replaced by sh3.h.)

Ulrich




^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: SuperH port
  2008-12-11  7:20                   ` Ulrich Mueller
@ 2008-12-11  7:58                     ` Dan Nicolaescu
  0 siblings, 0 replies; 17+ messages in thread
From: Dan Nicolaescu @ 2008-12-11  7:58 UTC (permalink / raw)
  To: Ulrich Mueller; +Cc: emacs-devel, Stefan Monnier, emacs

Ulrich Mueller <ulm@gentoo.org> writes:

  > >>>>> On Sat, 18 Oct 2008, Dan Nicolaescu wrote:
  > 
  > >> 2008-10-16  Ulrich Mueller  <ulm@gentoo.org>
  > >> 
  > >> * m/sh3.h: New file, machine description for SuperH.
  > 
  > > Thank you, I checked in a slightly simplified version of this.
  > 
  > I just noticed that etc/MACHINES still contains the following entry
  > under "Support for the following obsolete platforms was removed in
  > Emacs 23.1":
  > 
  >   sh3el (m/sh3el.h)
  > 
  > I wonder if this line should be removed, since sh3el is supported.
 
Line removed.




^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2008-12-11  7:58 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-08  9:17 SuperH port Ulrich Mueller
2008-10-08 10:37 ` Ulrich Mueller
2008-10-08 14:31 ` Dan Nicolaescu
2008-10-08 18:22   ` Ulrich Mueller
2008-10-08 18:47     ` Stefan Monnier
2008-10-15 21:16       ` Ulrich Mueller
2008-10-15 21:36         ` Dan Nicolaescu
2008-10-16 16:04           ` Ulrich Mueller
2008-10-17  6:04             ` Dan Nicolaescu
2008-10-17 20:26               ` Ulrich Mueller
2008-10-17 22:25                 ` Andreas Schwab
2008-10-17 22:56                   ` Ulrich Mueller
2008-10-18  8:39                   ` Ulrich Mueller
2008-10-18  8:12                 ` Dan Nicolaescu
2008-12-11  7:20                   ` Ulrich Mueller
2008-12-11  7:58                     ` Dan Nicolaescu
2008-10-09 10:24   ` Ulrich Mueller

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).