unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Ken Raeburn <raeburn@raeburn.org>
Subject: start_of_data and RISCOS
Date: Sun, 21 Jul 2002 15:31:51 -0400	[thread overview]
Message-ID: <E17WMQp-00074O-00@kal-el.raeburn.org> (raw)

Currently the preference order for defining start_of_data is to use
the address of "etext" if BSD_SYSTEM is defined and DATA_SEG_BITS is
not, regardless of whether DATA_START is defined.

Since defining DATA_SEG_BITS also turns on the inclusive-or every time
a Lisp_Object handle is turned into a pointer, I'd like to reverse
that -- use DATA_START for start_of_data if it's defined, otherwise
consider doing the etext bit.  On a platform like the Alpha, where
DATA_START is some large constant but all the DATA_SEG_BITS are
allowed in the value of a Lisp_Object, it's a waste of cycles.

The question is, are there any configurations that will break because
of this?  They'd have to be ones defining BSD_SYSTEM and DATA_START
but not DATA_SEG_BITS.  Perhaps an OS configuration simply leaves out
an "#undef DATA_START" because it just worked to let BSD_SYSTEM
dominate, and the DATA_START references in unexalpha.c and unexmips.c
weren't used?

Very few configurations define DATA_START but not DATA_SEG_BITS:
  m/intel386.h, if WINDOWSNT is defined
  m/mips.h, if not __linux__
  m/windowsnt.h

I hardly expect the Windows configuration to define BSD_SYSTEM, but
the wide variety of MIPS operating systems does include some BSD-like
ones.  I've done some poking around at the config files, and it looks
like MIPS running RISCOS 4 or 5 in BSD mode is the interesting case.
Other MIPS configurations don't define BSD_SYSTEM, or they use a
different m/ file which defines DATA_SEG_BITS or doesn't define
DATA_START.  But under RISCOS, it may be the case that DATA_START and
BSD_SYSTEM are defined and DATA_SEG_BITS is not, so that it might be
using "&etext" for start_of_data even though DATA_START is 0x800000.

Does anyone have access to a RISCOS system who could check this, and
see if my patch below will break things?  If it does break things,
it might be sufficient to #undef DATA_START on RISCOS, but that may
break unexmips.c....

Ken



Index: mem-limits.h
===================================================================
RCS file: /cvsroot/emacs/emacs/src/mem-limits.h,v
retrieving revision 1.29
diff -p -u -r1.29 mem-limits.h
--- mem-limits.h	11 Dec 2001 22:18:16 -0000	1.29
+++ mem-limits.h	21 Jul 2002 18:33:44 -0000
@@ -79,10 +79,16 @@ extern POINTER start_of_data ();
 #define EXCEEDS_LISP_PTR(ptr) ((EMACS_UINT) (ptr) >> VALBITS)
 #endif
 
+#ifdef DATA_START
+#define start_of_data() ((char *)DATA_START)
+#endif
+
 #ifdef BSD_SYSTEM
 #ifndef DATA_SEG_BITS
+#ifndef DATA_START
 extern char etext;
 #define start_of_data() &etext
+#endif
 #endif
 #endif
 
Index: sysdep.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/sysdep.c,v
retrieving revision 1.241
diff -p -u -r1.241 sysdep.c
--- sysdep.c	21 Jul 2002 14:17:19 -0000	1.241
+++ sysdep.c	21 Jul 2002 18:33:44 -0000
@@ -2237,6 +2237,7 @@ start_of_text ()
  *
  */
  
+#ifndef start_of_data
 char *
 start_of_data ()
 {
@@ -2259,6 +2260,7 @@ start_of_data ()
 #endif /* ORDINARY_LINK */
 #endif /* DATA_START */
 }
+#endif /* start_of_data */
 #endif /* NEED_STARTS (not CANNOT_DUMP or not SYSTEM_MALLOC) */
 \f
 /* init_system_name sets up the string for the Lisp function

             reply	other threads:[~2002-07-21 19:31 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-21 19:31 Ken Raeburn [this message]
2002-07-22 15:19 ` start_of_data and RISCOS Richard Stallman

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

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E17WMQp-00074O-00@kal-el.raeburn.org \
    --to=raeburn@raeburn.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 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).