henning@thor.acc.stolaf.edu (12/03/90)
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.daveh@cbmvax.commodore.com (Dave Haynie) (12/06/90)
In article <1990Dec3.041120.1142@acc.stolaf.edu> henning@thor.acc.stolaf.edu () writes: >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. And there are the guys who are constantly yelling about how they only write code for real computer? Shame on them! Apparently, they have finally enountered their first Real Computer, and only thought they had been dealing with real computers until now. >The obvious fix was to replace all the storage macros ( yes, Mr. >Stallman hd the forsight to use macros rather than store things >hardcoded.) Fixing the Emacs code does seem to be the proper approach.... >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. That would be uglier, though at least in some cases, Lattice can return 64 bit objects as functional values. It certainly deals with doubles OK. So there has to be some way to get this working without adding indirection everywhere or changing functional returns to parameters, both of which would be ugly. If the macros provide for both storage and access of the pointer and tag fields, you can make typedef Lisp_object as a double, and then cast it to something like: struct Real_Lisp_object { char *address; char tag; char pad[3]; } when you're in the accessor functions. Too bad it wasn't written in good C++. >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? No. For several reasons: 1) The Amiga OS currently doesn't support task-specific MMU setups; they MMU setup is global, if there at all. 2) Application programs aren't permitted to make MMU calls. Currently, in some situations, they physically can, but you can expect this to break at some point. 3) Your MMU table would have to do something with 1.75 Gigabyte expansion bus space as well, all of which _could_ have RAM in it. 4) The problem is with GNU Emacs, not with the A3000. I always find I sleep better at night when I fix the actual problem, not kludge around it. 5) Currently, DMA driven device drivers will have a real problem with physical addresses != virtual addresses, since they don't know how to ask the OS for a virtual to physical translation. So at best, you'll trash your hard disk performance (by restricting access to the slower memory physically in the 24 bit address space), at worst you'll trash you hard disk itself. 6) Who's to say we won't some day build a 32 bit machine with an '020 or EC030 (eg, 32 bit addressing but no MMU). >BTW. Emacs 0.9 coming out soon. I'm not jumping on you, they made the mistakes. And I'm really hungry for real Emacs on my Amigas. I haven't managed to track down 0.8 yet, but these pissant little uEmacsen are for A500s, not loaded A2500s or A3000s. > -henning -- Dave Haynie Commodore-Amiga (Amiga 3000) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Wheeeeeeeeeeeeeeee...........
jesup@cbmvax.commodore.com (Randell Jesup) (12/19/90)
In article <1990Dec3.041120.1142@acc.stolaf.edu> henning@thor.acc.stolaf.edu () writes: >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. Ah yes, the wonders of Stallman "he-man" C/Lisp code. >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. Much better solution: let the optimizer do it's job, and add a -Dregister to the flags in the makefile. Also, modern compilers allow structure assignments and returns. >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? No. (Dave gave a reasonable explanation, not including the fact that A3000's already use the MMU.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)