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

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")  ;-)