usenet@cps3xx.UUCP (Usenet file owner) (05/08/89)
In article <6752@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <7989@killer.Dallas.TX.US>, elg@killer.Dallas.TX.US (Eric Green) says: > >> But don't expect miracles. As I said, the MMU was intended for running >> Unix. As such, it's just fine for doing virtual memory, and if I had a >> 2620, I'd be working on hacking it this very moment (;-). But it was >> not intended for AmigaDOS. AmigaDOS assumes one big shared address >> space, with all the processes living in peace together in that big >> shared address space. The MMU can make that big address space even >> bigger. But it still can't keep process A from tromping on process B's >> data, at least not without a big horrendous slow kludge. > >Well, I'm not sure how horribly kludgy it would get or not. In order for per- >task protection to work, you'd have to have an MMU table, or at least a part >of one, added on to the context information for each task. ... > [stuff deleted] Aside from the trivialities of adding resource tracking/cleanup [ :-) ] to the OS, wouldn't it be fairly simple to make new loader hunktypes that (or protect bits) say that this program knows about AmigaDos Protectedmode, and then set up MMU context stuff for it. Then, existing program would still be able to scribble all over memory (except areas specifically declared private by protected mode programs) just as they do now. This should avoid most incompatibility problems. Eventually, all programs will run in protected mode, and you can make a user setable switch to allow/disallow non-protected mode programs. Or, better yet, for developing software for the current amiga environment, implement a Virtualy Machine system, which would allow you to run several VirtualAmigas on the same hardware, and allows you to select which one gets to use the IO hardware. IBM360/370 VM style.