start_of_data and RISCOS

start_of_data and RISCOS

[Ken Raeburn]

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

Re: start_of_data and RISCOS

[Richard Stallman]

    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.

Using DATA_START first is ok provided you check all the platforms
on which DATA_START is defined and verify this won't break them.
You have started doing that:

      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.

      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.

The next question is, does it actually make a difference if
start_of_data returns DATA_START instead of &etext?  Let's look at the
places that use start_of_data and see if this would matter.

start_of_data is used mainly in some unex*.c files, and unexmips.c
does not use it.  vm-limit.c is the only other use, and I think it
will be better off with a closer value of start_of_data.  So I
conclude that your change is safe.