c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) (05/03/89)
MMUs on Amigas? Somehow that seems farther into the future than the end of the year... Unless this is Dave's new project? :-) In article <11486@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > [ I've been kvetching lately about how none of the Intuition gadget >manipulation function parameters are consistent, which makes it hard for me >to remember what they are. ] Gawd yes, it's really terrible. Why are they this way, anyway? -=============================================- David Navas c60c-1ea@WEB.Berkeley.Edu Ideas, what ideas? If I had any idea I'd have an idea, I wouldn't have posted all of this nonsense -=============================================-
daveh@cbmvax.UUCP (Dave Haynie) (05/03/89)
in article <23912@agate.BERKELEY.EDU>, c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) says: > MMUs on Amigas? Somehow that seems farther into the future than the end of the > year... > Unless this is Dave's new project? :-) Well, no, that's my old project. The A2620 has an MMU. Currently the only way I know to take advantage of this MMU is with the SetCPU program I wrote, which does much to speed up the system, but little to protect or virtualize your system. But heck, that's only spare-time hacking on my part, and by a mainly-hardware guy too. One of the reasons I made the source to SetCPU V1.4 public domain was to show everyone how easy playing MMU games can be. Apparently at least one group has taken the bait, my sources tell me. And I wasn't the first to start MMU hacking under AmigaOS.... > David Navas c60c-1ea@WEB.Berkeley.Edu -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
elg@killer.Dallas.TX.US (Eric Green) (05/03/89)
in article <23912@agate.BERKELEY.EDU>, c60c-1ea@web-1c.berkeley.edu (Yen Yuanchi Hsieh) says: > MMUs on Amigas? Somehow that seems farther into the future than the end of the > year... > > Unless this is Dave's new project? :-) No, Dave's old project. The A2620 (the 68020 card) has a MMU on it (intended for running Unix, but can be used for other things too -- currently, he's using it to put Kickstart into 32-bit RAM to speed things up tremendously). And all 68030 cards come with a MMU by definition (the 68030 has one on-board). 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. (But does the MMU support making pages execute-only? If so, at least process A can be kept from tromping on process B's code). -- | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | | // Join the Church of HAL, in worship of all computers with | |\X/ three-character names (e.g. IBM and DEC). White lab coats optional. |
daveh@cbmvax.UUCP (Dave Haynie) (05/04/89)
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. I think the best way for this to work would be to have PUBLIC and PRIVATE memory in different physical locations. When a task got swapped in, it would have it's table for PRIVATE memory replace that of the prior task, while PUBLIC would be the same for all tasks. This would still be a linear address space, and would count on program's properly allocating this PUBLIC and PRIVATE memory (eg, I doubt that MEMF_PUBLIC is respected well enough for that to be sufficient). In any case, it's MUCH more complicated than just adding virtual memory, as you stated. UNIX makes the job of protection much easier by generally not having shared memory, having each task start at the same logical memory location, and having all memory allocations for each task contiguous. > (But does the MMU support making pages execute-only? If so, at > least process A can be kept from tromping on process B's code). Pages can be read-only; not sure if there's a way to make them execute-only. As far as the MMU in the 68030, or the 68851 MMU go, they're about as flexible as a paging MMU gets. UNIX happens to work very well with paging MMUs, but that's doesn't imply that these MMUs are only suitable or decent for UNIX. Though as I said before, I suspect anything like protection will require OS support to work well at all. > | // Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 | > | // ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg (318)989-9849 | > | // Join the Church of HAL, in worship of all computers with | > |\X/ three-character names (e.g. IBM and DEC). White lab coats optional. | -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession
ugkamins@sunybcs.uucp (John Kaminski) (05/07/89)
In article <6752@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes:
=>... This would still be a linear address space, and would count
=>on program's properly allocating this PUBLIC and PRIVATE memory (eg, I
=>doubt that MEMF_PUBLIC is respected well enough for that to be sufficient).
The whole idea of this task protection stuff is to save the rest of the system
from the laziness/flakeyness/viciousness of other tasks. Right there you seem
to defeat yourself. You can't count on a task to properly do anything.
The only two ways I know to provide true protection of
something from everything else are: 1.) special hardware that limits one task's
access to everything on the system, except maybe itself, or 2.) create your
own virtual machine--if you wanted to, you could model the 680x0 in software,
with additional code thrown in to maintain control. #2 is really just a
software solution of #1. In other words, if you emulate a processor, or just
simply make up your own, you have total control of what goes on; if you don't
want something in a particular address to be there, you simply make it
impossible for it to happen. This is something akin to being a microcode
programmer.
---
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
a-WYSIWYG, a-WYSIWIG
In the jungle
The silicon jungle
The process sleeps tonight