🚀 go-pugleaf

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...........