Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!usc!apple!agate!shelby!msi.umn.edu!noc.MR.NET!nic.stolaf.edu!thor.acc.stolaf.edu!henning
From: henning@thor.acc.stolaf.edu
Newsgroups: comp.sys.amiga.tech
Subject: 3000 memory map causes problem.  need advice.
Message-ID: <1990Dec3.041120.1142@acc.stolaf.edu>
Date: 3 Dec 90 04:11:20 GMT
Sender: news@acc.stolaf.edu
Reply-To: henning@thor.acc.stolaf.edu ()
Organization: St. Olaf College; Northfield, MN
Lines: 61

Ok, as of December first, I know what has been causing GNU Emacs to
crash on amiga 3000's.  The only problem is that I am not sure how to
fix the problem.

This is the scoop.  Since all unix systems are remaped by mmu's all
programs start at a virtual address of zero.  Richard Stallman ( or
someone in his employ) decided that noone in his or her right mind
would ever edit files over sixteen megabytes large.  Therefore they
thought that leaving 24 bits for pointers would be sufficient.

They then used the top eight bits for typecast information in their
lisp object scheme.  Well.  That causes a big problem in that the main
memory of amiga 3000s starts at the seventeenth magabyte page.
Therefore, any pointer stored as a lisp object was corrupted when it
was stored.

The obvious fix was to replace all the storage macros ( yes, Mr.
Stallman hd the forsight to use macros rather than store things
hardcoded.) with ones that used a structure such as
struct Lisp_Object{
int val;
char type;
};
Which on the surface looks good.  However, once the compiler starts
chugging away, it finds that many of these structures are then
declared as register variables ( all well and good for the original
definitions which are all 32 bits long, even the union setup. )

I have spent about two hours puting in statemnts like
#ifdef NEED_ALL_BITS
   Lisp_Object foo;
#else
   register Lisp_Object foo;
#endif
when I come to the problem that often these structures are returned as
the value pof a function.  This is much more difficult to fix.

Musing to myself, I come across an idea.  All3000s are 68030 machines.
This means that they have an mmu embeded within them.
Would it be possible to write a loader which wuold set up the mmu to
relocat memory for the single porcess of emacs?  

As I am unfamiliar with 680551 machine calls, I am not sure how this
wuold be done.

Please send me some suggestions.  I am giving up on my former idea of
just restructuring the Lisp_object.

BTW.  Emacs 0.9 coming out soon.

				-henning
henning@stolaf.edu
henning@stolaf.UUCP

 

--
---------------------------------------------
All opinions are my own, as are the spellings
any deviation from the norm is just an effect
of my deviance.