From: Dan Nicolaescu <dann@ics.uci.edu>
To: Ulrich Mueller <ulm@gentoo.org>
Cc: sh@gentoo.org, emacs@gentoo.org, emacs-devel@gnu.org
Subject: Re: SuperH port
Date: Wed, 8 Oct 2008 07:31:56 -0700 (PDT) [thread overview]
Message-ID: <200810081431.m98EVuUJ011805@mothra.ics.uci.edu> (raw)
In-Reply-To: <18668.31387.21197.719443@a1ihome1.kph.uni-mainz.de> (Ulrich Mueller's message of "Wed, 8 Oct 2008 11:17:15 +0200")
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.
next prev parent reply other threads:[~2008-10-08 14:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-08 9:17 SuperH port Ulrich Mueller
2008-10-08 10:37 ` Ulrich Mueller
2008-10-08 14:31 ` Dan Nicolaescu [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810081431.m98EVuUJ011805@mothra.ics.uci.edu \
--to=dann@ics.uci.edu \
--cc=emacs-devel@gnu.org \
--cc=emacs@gentoo.org \
--cc=sh@gentoo.org \
--cc=ulm@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.