Path: utzoo!attcan!uunet!cbmvax!daveh From: daveh@cbmvax.commodore.com (Dave Haynie) Newsgroups: comp.sys.amiga.tech Subject: Re: 3000 memory map causes problem. need advice. Message-ID: <16326@cbmvax.commodore.com> Date: 5 Dec 90 20:29:08 GMT References: <1990Dec3.041120.1142@acc.stolaf.edu> Reply-To: daveh@cbmvax.commodore.com (Dave Haynie) Organization: Commodore, West Chester, PA Lines: 78 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...........