bradch@microsoft.UUCP (Bradford Christian ms1) (02/16/89)
Is anyone out there in net-land with a 2500 (or some expansion card with an MMU) working on virtual memory? The rom to ram thing sounds fun, but the real power of an mmu is preventing those nasty "Not enough memory" messages (or gurus :-(). I know at least one company is selling software for Macs with mmus to do this, and Apple's Gassee is quoted on the cover of the Jan 31 MacWeek saying "Apple will have virtual memory in 1989." I think we should beat them with a public domain virtual memory handler for properly equipped Amigas. I would be working on this right away, but have several other projects that need immediate attention. I also am a simple 68000 guy, whith no real knowledge of the additional features of the 68020 or the mmu for that matter (yet). So, once again, is there anybody out there woking on something like this? Does anyone know of any problems one might encounter doing this? Are supposed to access the mmu directly, or does C/A have some sort of software interface we should use? Am I babbling? Where did I learn how to spell? BradCh BTW: The Amiga 2500 is AWSOME!
mcr@julie.UUCP (Michael Richardson) (02/24/89)
Bradford Christian writes: >Is anyone out there in net-land with a 2500 (or some expansion card with >an MMU) working on virtual memory? The rom to ram thing sounds fun, but Thinking about it. I don't have 68020 on my Amiga to play with either. >I think we should beat them with a public domain virtual memory handler >for properly equipped Amigas. I would be working on this right away, It would be nice... >So, once again, is there anybody out there woking on something like this? >Does anyone know of any problems one might encounter doing this? The biggest problem that will occur is that Exec/AmigaDOS/Intuition seems to have these chains of pointers which tasks must access. What has occured to me is that one might be able to have Virtual Memory in the address space above 0xffffff (the highest 24 bit address) and leave the bottom 16meg that the standard 68000 can access unmapped. I'd like to put user stacks up there (where they can be expanded by page faults) and maybe resident commands too. (Copy on write would get rid of the problem with self modifying code and statically intialised variables.) >Are supposed to access the mmu directly, or does C/A have some sort of >software interface we should use? Am I babbling? Where did I learn I'd like to know that too. I suspect that standard 68020 MMU instructions would work. > BradCh -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ Alter @ 7:483/109.10
daly@hpdml93.HP.COM (John Daly) (03/10/89)
/ hpdml93:comp.sys.amiga.tech / bradch@microsoft.UUCP (Bradford Christian ms1) / 5:37 pm Feb 15, 1989 / Is anyone out there in net-land with a 2500 (or some expansion card with an MMU) working on virtual memory? The rom to ram thing sounds fun, but the real power of an mmu is preventing those nasty "Not enough memory" messages (or gurus :-(). I know at least one company is selling software for Macs with mmus to do this, and Apple's Gassee is quoted on the cover of the Jan 31 MacWeek saying "Apple will have virtual memory in 1989." I think we should beat them with a public domain virtual memory handler for properly equipped Amigas. I would be working on this right away, but have several other projects that need immediate attention. I also am a simple 68000 guy, whith no real knowledge of the additional features of the 68020 or the mmu for that matter (yet). So, once again, is there anybody out there woking on something like this? Does anyone know of any problems one might encounter doing this? Are supposed to access the mmu directly, or does C/A have some sort of software interface we should use? Am I babbling? Where did I learn how to spell? BradCh BTW: The Amiga 2500 is AWSOME! ----------
cg@myrias.UUCP (Chris Gray) (03/11/89)
In article <420003@hpdml93.HP.COM> daly@hpdml93.HP.COM (John Daly) writes: >Is anyone out there in net-land with a 2500 (or some expansion card with >an MMU) working on virtual memory? The rom to ram thing sounds fun, but >the real power of an mmu is preventing those nasty "Not enough memory" >messages (or gurus :-(). I know at least one company is selling software >for Macs with mmus to do this, and Apple's Gassee is quoted on the cover >of the Jan 31 MacWeek saying "Apple will have virtual memory in 1989." > >I think we should beat them with a public domain virtual memory handler >for properly equipped Amigas. I would be working on this right away, >but have several other projects that need immediate attention. I also >am a simple 68000 guy, whith no real knowledge of the additional features >of the 68020 or the mmu for that matter (yet). > >So, once again, is there anybody out there woking on something like this? >Does anyone know of any problems one might encounter doing this? >Are supposed to access the mmu directly, or does C/A have some sort of >software interface we should use? Am I babbling? Where did I learn >how to spell? Adding true virtual memory to an operating system not designed for it and still staying compatible with that operating system is probably impossible. In the case of AmigaDOS, which relies heavily on a shared address space, it most likely is. However... I DO have an A2500 (actually an upgraded A2000), so one day I might play around with this idea: (my 020/851/881 manuals haven't arrived yet) It may be possible to write a program (call it "protected") which will create a protected memory environment for a single program and run that program in that environment. It would have to produce page tables, etc. itself and then directly load the program, etc. into that space. It would have to trap all of the library calls and indirectly support several. (A good initial set would be the DOS library plus a bit of Exec, like AllocMem, Signal, etc.) It would use Exec's tc_Start and tc_Switch (or whatever they're called) task fields to enable/disable the MMU stuff as the task in question is scheduled by Exec. This sort of framework should be able to run programs ported over from Unix in such a way that they can't crash the system. Am *I* completely out to lunch on this one? (I haven't looked at it at all, other than some idle thought - I'm busy on my graphics D & D system now.) -- Chris Gray Myrias Research, Edmonton +1 403 428 1616 {uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg
daveh@cbmvax.UUCP (Dave Haynie) (03/11/89)
in article <420003@hpdml93.HP.COM>, daly@hpdml93.HP.COM (John Daly) says: > / hpdml93:comp.sys.amiga.tech / bradch@microsoft.UUCP (Bradford Christian ms1) / 5:37 pm Feb 15, 1989 / > Is anyone out there in net-land with a 2500 (or some expansion card with > an MMU) working on virtual memory? The rom to ram thing sounds fun, but > the real power of an mmu is preventing those nasty "Not enough memory" > messages (or gurus :-(). I know at least one company is selling software > for Macs with mmus to do this, and Apple's Gassee is quoted on the cover > of the Jan 31 MacWeek saying "Apple will have virtual memory in 1989." While you can't strictly use a Motorola MMU without some bit of memory protection, the issues of virtual memory and protected memory are not the same. You can have virtual memory implemented globally, as this Apple add-on apparently does, without any sort of task to task protection. And you can obviously have an MMU context attached to each task (not implying that it's easy, or that it's a drop in with the current OS, just that it can be done) without adding virtual memory. I'd like to see both on the Amiga, though I suspect that virtual memory would be easier to implement, by some degree, than real protection. Some people have looked into this; I personally haven't had the time (the ROM to RAM hack was a 2-niter; anything beyond that would take some real effort). > I think we should beat them with a public domain virtual memory handler > for properly equipped Amigas. That would be in the grand tradition; several commercial Mac Hacs have surfaced in equivalent form as PD/Shareware for the Amiga (VScreen, for example). > Are supposed to access the mmu directly, or does C/A have some sort of > software interface we should use? Am I babbling? Where did I learn > how to spell? Currently, you have to access the MMU directly, and you have to be the only one doing so. You also have to assume that it will unconditionally break as early as OS V1.4 time. The MMU must be arbitrated by the operating system, or an equivalent agent, to be used properly. However, a user program has no business even knowing about the MMU. Given that we don't have OS support, the only real thing that can be done is direct access. I was early on trying to get some support going for some kind of MMU.Library, that would be easy to translate on a function-call basis to whatever surfaces in terms of support for a future OS. Having since hacked a little MMU code, I'm on the way to believing that would be a mistake -- the OS should be the only agent that knows about the MMU. > BradCh > BTW: The Amiga 2500 is AWSOME! Gee, thanx! -- 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
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (05/13/89)
It would be intensely neat if someone would demonstrate an Amiga with 2620 running VM during the next DevCon. (Too bad I don't have a 2620 to play with.) Perhaps we can discuss any complications that might arise? Page faulting during Forbid()/Permit() might be acceptable, if the page fault handler doesn't modify any standard system structures, just the VM state stuff, which sounds reasonable. Disable()/Enable() may or may not be something else again. You know, folks, this could really be wonderful. -tom
rokicki@polya.Stanford.EDU (Tomas G. Rokicki) (05/13/89)
I write: > Page faulting during Forbid()/Permit() might be acceptable, if the > page fault handler doesn't modify any standard system structures, just Damn, what was I thinking? To do disk I/O, you'd need to modify lots of system structures, and even possibly put up error requestors and the like. (Unix machines *die* during swap errors---never thought much about it before.) But the changes may well be minimal---it would be interesting to try. In the meantime, I think we all had better be damned careful about where and how we use Forbid()/Permit() and Enable()/Disable(). I really think this could be hacked up in a week, if someone was willing to spend the time. (You'd have to know the MMU somewhat.) -tom
c60c-1ea@web-1g.berkeley.edu (Yen Yuanchi Hsieh) (05/13/89)
In article <9140@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >It would be intensely neat if someone would demonstrate an Amiga with >2620 running VM during the next DevCon. (Too bad I don't have a 2620 >to play with.) Perhaps we can discuss any complications that might >arise? Well, I won't be at DevCon -- so let's talk about some right now [which you go ahead and do anyway...] >Page faulting during Forbid()/Permit() might be acceptable, if the >page fault handler doesn't modify any standard system structures, just >the VM state stuff, which sounds reasonable. Disable()/Enable() may >or may not be something else again. Actually, I was thinking that one might be able to do Forbid()s merely by write-protecting the page-to-be-loaded. Then when a 'non-owner-of-this-page' occurs, have the interrupt handler check if the owner-of-this-page has Forbid()den, restart that task if it has (default error if it hasn't) and clear the write-protect on the page. Disable()s would need to be changed into Forbid()s, of course... It's not the best approach. If you Forbid on Exec structures -- exec structures that need to be read by Exec Switch(), that might cause problems. Any way to run Exec SU and avoid that situation? Also, you need to be careful coming out of all of this. I mean, someone could have Forbid(), mistakenly Wait()ed, and then have one of his pages readable that shouldn't have been. But this seems more reasonable if it's doable... >You know, folks, this could really be wonderful. I hope so... >-tom ----------------------------------------------- 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 this nonsense.
jesup@cbmvax.UUCP (Randell Jesup) (05/13/89)
In article <9140@polya.Stanford.EDU> rokicki@polya.Stanford.EDU (Tomas G. Rokicki) writes: >Page faulting during Forbid()/Permit() might be acceptable, if the >page fault handler doesn't modify any standard system structures, just >the VM state stuff, which sounds reasonable. Disable()/Enable() may >or may not be something else again. Not really: with that forbid broken (so the device driver task can run), anything else can get in and cause problems. For example, if you Forbid(), FreeMem(), page fault, and the driver AllocMem's, you're screwed. Hell, if you page fault during AllocMem(), which uses Forbid(), you have REAL problems. It can be done, in all likelyhood, but it's not going to be a slam- dunk. Much easier would be to allow _explicit_ requests for a virtual allocation, and put the proviso that it must never be accessed during forbid/ disable. This could be done by third parties.... :-) Gets you less (only programs written to use it get any benefit), but is a lot easier. Oh, one other proviso: no DMA to it, either (since there is no logical->physical translation call, and therefor the drivers don't use it). Mask (for FFS) will work fine here. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
page%swap@Sun.COM (Bob Page) (05/15/89)
>I really think this could be hacked up in a week
Is this a Rokicki week?
Hey, I just want my errant program to dump its core, not my machine.
I agree that standards for VM/protected mode programming should be
included in the 1.4 docs.
..bobdaveh@cbmvax.UUCP (Dave Haynie) (05/18/89)
in article <8905170500.AA25917@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) says: > Matt Dillon <dillon@postgres.berkeley.edu> writes in > Message-ID: <8905162209.AA20997@postgres.Berkeley.EDU> >> You are clearly missing the point. Certainly I would much rather >> have a MEMF_PHYSICAL flag instead of a MEMF_VIRTUAL flag, but it would break >> too many programs... more than too many, a *huge* number of programs. > Would you not rather break many programs today, when there are so few potential > A2500 owners and users of virtual memory, than three years from now when every > body will be having MMUs in their Amigas? Ordinarily it's very easy to decide whether a given application can legidimately break in a new OS release -- if the application does something unsupported (we can easily find out on our own if the developer won't own up) that makes it break, it should break. If it follows the rules, it should work. There weren't proper rules for VM available to software authors when all software was written, so the Right Thing To Do in such a case is usually to make sure that as much as possible works under such a system. However, given that VM will always be something that is set up at the user's option, at least as long as we have 68000 machines supported, that changed the rules for compatibility, IMHO. > Preposterous! Virtual memory can be written within a week by somebody who knows > what he is doing. A handler will be available by the end of the summer, I will > bet my iron ring on that. I could probably have something going with about 3 months of "Hazy-time" hacking, given what I know about the MMU and the Amiga system. I have at least one decent answer for each of the raised concerns about VM on the Amiga that have so far surfaced. I currently expect that some things would break, but not lots of things (hint -- I could make the Forbid()/Permit() and Disable()/Enable() calls do anything I like (includes "Informing the VM manager"), even though they are often macros. That's what Virtual Machines are for. Then again, there are far better and knowledgable programmers than I at least thinking about this, so I can't really comment on whether "a week" is outlandish or not. I do know that I currently don't have the time to work on this, though perhaps I will in the next several months. It certainly tops my list of "way-cool things that no-one's yet done". >> (4) it does not ease the way for eventual file mapping which is where UNIX is >> going these days. > Hmmm, you seem to have Unix etched in your head. Again, IMHO. You can never ignore what's being done in UNIX. Period. Even if some parts of UNIX aren't even close to the level of what's done daily in the Amiga OS, there are many lessons to be learned from UNIX. First of all, there are an amazing number of EXCELLENT folks working on solutions to the same kind of problems you'd like to solve for AmigaOS. Many of their clever solutions are applicable to AmigaOS, even if the specific form adpoted under UNIX seems BOGUS. There's also, plain and simple, more brain power at work there, solving real problems. It's not like trying to learn from MS-DOS, where the Big Problem is usually how to trick the OS into doing something cool, the latest method of TSR programming, how to really use that extra 1 meg you just added which is outside of 808x space, etc. UNIX and AmigaOS each have their good and bad points and we're in a good position -- AmigaOS can benefit from advances in UNIX theory; cool stuff we do in AmigaOS isn't yet likely to be noticed by the UNIX PTB. > Unix is slow, Unix is big, Unix is cumbersome. Yeah, compared to AmigaOS, UNIX is slow. One good reason is that it's not real time. A real-time OS make much more sense in a single user situation, methinks. Big, well, there are LOTS of standard UNIX tools which aren't available as AmigaOS standards. You can get most of them on Fish Disks or as part of your C Compiler package, though I still don't have anything as nice as Franz LISP on my Amiga. As far as what you need to run UNIX at all, it's not all that different from what you can run AmigaOS in. Certainly UNIX can run, rather comfortably (though perhaps not to Johann's speed standards) on a 3-meg Amiga with hard drive. It does need an MMU, so A2620s are idea for UNIX. AmigaOS is somewhat less memory hungry, but I find a minimum of 2 megs is needed before I have a real smooth AmigaOS system. I do lots of painful stuff, like compiling Lattice C++; a minimal Amiga system could live in less space than a minimal UNIX, but for approximately the same kind of usage, UNIX and AmigaOS are in the same ballpark, at least. The same cannot be said about OS/2. Apparently, MicroSoft hasn't learned from UNIX. > Valentin -- 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
darin@nova.laic.uucp (Darin Johnson) (05/19/89)
In article <6905@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>> it does not ease the way for eventual file mapping which is where UNIX is >>> going these days. >> Hmmm, you seem to have Unix etched in your head. >Again, IMHO. You can never ignore what's being done in UNIX. Period. Even if >some parts of UNIX aren't even close to the level of what's done daily in the >Amiga OS, there are many lessons to be learned from UNIX. > -- AmigaOS can benefit from advances in UNIX theory First off, I really like UNIX, but it is a bit annoying when people imply that feature X was invented by UNIX. File mapping is not a UNIX feature, other OSes have had it for some time (Multics is the biggest example, VMS is a common example). Same goes for shared libraries, paged kernels, etc. The point is some UNIX vendors realize the usefullness of these features and add them in, in the same way that other OSes borrow ideas from UNIX. What doesn't happen are photo- copies of features from other systems. A new feature has to fit in well with the underlying OS. I get the feeling that some people are saying "It's in UNIX, we have to put it into Amiga, if it doesn't mesh, we'll force it". (study the concept, not an implementation) People often describe the Amiga as "unix-like". To Amiga owners here at work, it is VMS-like. Other people have described it as a mixture of MS-DOS and Mac (the whole is greater than the sum of its parts). I'd like to see Amiga get its own personality. (Amiga personality would be making file mapping available as a device driver, etc.) >though I still don't have anything as nice as Franz LISP on my Amiga. Sigh... Someday. Darin Johnson (leadsv!laic!darin@pyramid.pyramid.com) We now return you to your regularly scheduled program.
451061@UOTTAWA.BITNET (Valentin Pepelea) (05/23/89)
This question is aimed at Dave Haynie.
In a previous message, you mentioned that you though about tricks for solving
the Forbid()/Disable() problem using virtual machine emulation. My question is,
how?
I though about this once again, and once again I came to the conclusion that
it does not matter wether you can trap the Forbid()/Disable calls, since the
problem is not that multitasking is disabled, but rather that we do not know
*why* it is disabled. Thus we do not know what reparative action to take, and
thus wether we are allowed to perform page swapping or not.
Valentin
_________________________________________________________________________
"An operating system without Name: Valentin Pepelea
virtual memory is an operating Phonet: (613) 231-7476 (New!)
system without virtue." Bitnet: 451061@Uottawa.bitnet
Usenet: Use cunyvm.cuny.edu gate
- Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CAdaveh@cbmvax.UUCP (Dave Haynie) (05/24/89)
in article <8905222150.AA05890@jade.berkeley.edu>, 451061@UOTTAWA.BITNET (Valentin Pepelea) says: > This question is aimed at Dave Haynie. > In a previous message, you mentioned that you though about tricks for solving > the Forbid()/Disable() problem using virtual machine emulation. My question is, > how? Without additional research, about all I know that's good for is letting your virtual manager know that you're supposed to be Disable()d. Forbid() actually just increments a counter in the current task structure, and the swapper only swaps if the counter is zero. Thus it's not necessary to trap Forbid()s (it would also be very difficult), since the virtual manager will be called up in the context of the forbidded task. > Thus we do not know what reparative action to take, and thus wether we > are allowed to perform page swapping or not. Knowing whether or not we're in a locking situation isn't a panacea, but it's going to be helpful. For instance, if I get calls to AllocMem() under a swap lock, the virtual manager can return a chunk of non-pagable memory. If I take a age fault while swap locked, I can set out an alert telling of such an occurance, allowing the user to let me go ahead or GURU (such page faults need only occur once -- if a page is faulted under a swap lock, that page should be locked in until fully freed). I have no doubts that some things will break under a virtual system, since we haven't had guidelines on what's proper virtual programming etiquette, or even full facility to deal with such guidelines, MEMF_PHYSICAL or MEMF_NONPAGED (they're different). But there's all kinds of stuff out there that doesn't count on walking damaged system lists while forbidden, so I expect I'll be about as happy with a virtual memory manager as I was when I got boatloads of fast memory and a few things broke because everything wasnt' MEMF_CHIP anymore. The nice thing is it can be switched on and off. > Valentin > "An operating system without virtual memory is an operating system > without virtue." - Ancient Inca Proverb Then again, I haven't found a way to use up 7 megabytes of physical memory yet, so I don't really suppose I have a need for virtual memory myself. Other than the fact it's way cool just to have it.... -- 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
mph@behemoth.phx.mcd.mot.com (Mark Huth) (05/24/89)
In article <8905222150.AA05890@jade.berkeley.edu> 451061@UOTTAWA.BITNET (Valentin Pepelea) writes: > >I though about this once again, and once again I came to the conclusion that >it does not matter wether you can trap the Forbid()/Disable calls, since the >problem is not that multitasking is disabled, but rather that we do not know >*why* it is disabled. Thus we do not know what reparative action to take, and >thus wether we are allowed to perform page swapping or not. Well, I'm not Dave, but I'll jump in here. Forbid in not too bad - just eats processor doing nothing while the page swap occurs. That is, we do not care why the task forbids, we simply comply by not scheduling another context. If a page fault occurs, swap a page. If it was the wrong page, then you'll get another page fault, so you swap that one in. Assuming you use something other than most-recently-used for the selection of targets for swapping, you'll eventually end up with the proper page set in memory and complete the critical region. Disable is another story, as you may well need interrupts for the page swapper. I would say that if you're in the area where interrupts really need to be disabled, then you're mucking with the hardware, and the code is probably not a good candidate for VM. I mean, at least some of the code will access physical registers. Normally, this code is inside the OS kernel and not run under VM. Mark Huth
karl@sugar.hackercorp.com (Karl Lehenbauer) (05/24/89)
In article <6959@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: > Then again, I haven't found a way to use up 7 megabytes of physical memory > yet, so I don't really suppose I have a need for virtual memory myself. Other > than the fact it's way cool just to have it.... Bingo....well, quasi-bingo. I agree that there isn't much yet to use up 7 meg. VM would presumably be more useful to people with only a couple meg. There are huge memory applications forthcoming, however. A 4000X4000 24-bit plane image (good enough to record with sub-film grain resolution onto 70 mm film, I believe) takes up 48 megabytes. Of course you'll want to keep it entirely in RAM -- accessing it via VM into a few meg would take an excruciatingly long time. You'll want an undo buffer, too. -- -- uunet!sugar!karl | "Woof!" -- free Usenet access: (713) 438-5018
limonce@pilot.njin.net (Tom Limoncelli) (05/24/89)
In article <6959@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >Then again, I haven't found a way to use up 7 megabytes of physical memory >yet, so I don't really suppose I have a need for virtual memory myself. Other >than the fact it's way cool just to have it.... The academic value is great, but I really want it to (1) reduce the problem of "out of memory" and having to exit certain programs, etc (2) being able to leave large applications running and not ever have to exit them. The ones I don't use will swap out; but will be ready when I really want them. Ok. I'm being lazy too. :-) > Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests -- Tom Limoncelli -- tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net Drew University -- Box 1060, Madison, NJ -- 201-408-5389 Standard Disclaimer: I am not the mouth-piece of Drew University
jesup@cbmvax.UUCP (Randell Jesup) (05/25/89)
In article <10949@behemoth.phx.mcd.mot.com> mph@behemoth.UUCP (Mark Huth) writes: >Well, I'm not Dave, but I'll jump in here. Forbid in not too bad - just eats >processor doing nothing while the page swap occurs. That is, we do not care why >the task forbids, we simply comply by not scheduling another context. If a >page fault occurs, swap a page. If it was the wrong page, then you'll get >another page fault, so you swap that one in. Sorry, but every disk driver I've seen uses tasks, and therefore you MUST break the forbid in order to page, which means a page fault while forbidden is disaster. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
new@udel.EDU (Darren New) (05/25/89)
In article <3866@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes: >In article <6959@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes: >> Then again, I haven't found a way to use up 7 megabytes of physical memory >> yet, so I don't really suppose I have a need for virtual memory myself. Other >There are huge memory applications forthcoming, however. A 4000X4000 24-bit I've been following this without saying much, but I think there may be a good interim solution. Just adding a bit to the load format headers that say this hunk is allowed to be in VM will help alot (pun intended). Also, allowing virtual memory allocation to be done explicitly would help "huge memory applications" of the future. However, to back-patch VM into current applications seems extremely difficult to get right. What about applications that use AvailMem to keep from allocating so much ram that requesters fail (is there a better way, BTW?)? What about programs like DPIII which could use VM for the images, but would really like to read-ahead the images during playback? What about a program running when your swap-disk has been ejected? I think explicit support is much easier to do than trying to guess what is safe on current applications. At least until CBM has had time to tell developers what VM will support in future releases. -- Darren (much better at finding problems than solutions) New
jimm@amiga.UUCP (Jim Mackraz) (05/25/89)
In article <6969@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes:
) Sorry, but every disk driver I've seen uses tasks, and therefore
)you MUST break the forbid in order to page, which means a page fault while
)forbidden is disaster.
It's not necessarily a disaster, it's only a disaster if that Forbid() was
protecting a critical operation on data that the disk driver will use.
Certain things will become non-pageable: drivers, their data structures, ...
In making them so, special arbitration can be installed which supplements and
does not depend on Forbid(). And this would by and large be only in "system"
software, which is going to need changes all around anyway.
Now if, on the other hand, that disk operation pops up an AutoRequester, ...
jimm
--
Jim Mackraz, I and I Computing "He's hidden now, but you can see
{cbmvax,well,oliveb}!amiga!jimm The bubbles where he breathes."
- Shriekback
Opinions are my own. Comments are not to be taken as Commodore official policy.aaron@madnix.UUCP (Aaron Avery) (05/25/89)
In article <3866@sugar.hackercorp.com> karl@sugar.hackercorp.com writes: >There are huge memory applications forthcoming, however. A 4000X4000 24-bit >plane image (good enough to record with sub-film grain resolution onto 70 mm >film, I believe) takes up 48 megabytes. Of course you'll want to keep it >entirely in RAM -- accessing it via VM into a few meg would take an >excruciatingly long time. You'll want an undo buffer, too. Waddaya mean, forthcoming? We've encountered this problem. That's why the next release of Professional ScanLab will have its own virtual memory support. And accessing those 48 Megs won't be too bad with 8 Megs of fast ram in the machine. For most people, they'll be doing smaller images (say 10 Megs), and two megs of memory would be sufficient. Even without VM, ScanLab is very useful for most standard printing applications (paper, not film) on a 9 Meg A2000. The biggest problem with demand paged VM on the Amiga currently is the Disable() problem. It would also make Forbid() even naughtier, since you could lock out other tasks (this includes things like timer.device) for an entire hard drive access. -- Aaron Avery, ASDG Inc. "A mime is a terrible thing to waste." -- Robin Williams ARPA: madnix!aaron@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!aaron
mph@behemoth.phx.mcd.mot.com (Mark Huth) (05/26/89)
In article <6969@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > > Sorry, but every disk driver I've seen uses tasks, and therefore >you MUST break the forbid in order to page, which means a page fault while >forbidden is disaster. Well, doctor, it hurts when I do this. Don't do that. In other words, don't run your buserr handler as a task! Actually, you probably want to be able to chose which way you go, depending on whether you are forbidden or not. There is no reason why the VM mechanism and associated disk driver cannot run out of the exception/ interrupt context rather than as a task. Does require special code for each controller, though, as the normal task oriented driver won't work. But the hardware interface should be the same - just the stuff around the edges dealing with resources and the like would change. Basic outline is: field exception determine that it's a page fault start the swap operation with the VMdisk driver if forbidden, save some context from the task and substitute a wait loop for the task code else just mark the task pending an event and set the context to the scheduler rte when the swap interrupt occurs, if forbidden, swap the task context back into place else unblock the task rte Using this control flow, the swapper runs out of exception contexts rather than out of a task context. Given some time, I think I could do this without the Exec source. Given the exec source, I should be able to add VM and protection. Might need some of the other OS code, though, depending on how layered the system really is. Mark Huth
lindwall@sdsu.UUCP (John Lindwall) (05/26/89)
In article <16173@louie.udel.EDU>, new@udel.EDU (Darren New) writes: > What about applications that use AvailMem to keep from allocating > so much ram that requesters fail (is there a better way, BTW?)? > What about programs like DPIII which could use VM for the images, but > would really like to read-ahead the images during playback? > What about a program running when your swap-disk has been ejected? And what about applications that use the ol' flush libs trick? You know, you attempt to AllocMem multi-megabytes of ram just before terminating so that any unused Libs and other resources get flushed. You expect the AllocMem to fail but by flushing all unused resources, the user will not be tricked into thinking the application ate the ram. With a VM system, the AllocMem will succeed! Oh well, I guess that won't be so bad. John Lindwall johnl@tw-rnd.SanDiego.NCR.COM
POSTMASTER@UNO.BITNET (05/26/89)
Randell Jesup <jesup@cbmvax.uucp> writes in Message-ID: <6969@cbmvax.UUCP>
- In article <10949@behemoth.phx.mcd.mot.com> mph@behemoth.UUCP (Mark Huth)
- writes:
- > Well, I'm not Dave, but I'll jump in here. Forbid in not too bad - just
- > eats processor doing nothing while the page swap occurs. That is, we do
- > not care why the task forbids, we simply comply by not scheduling another
- > context. If a page fault occurs, swap a page. If it was the wrong page,
- > then you'll get another page fault, so you swap that one in.
-
- Sorry, but every disk driver I've seen uses tasks, and therefore
- you MUST break the forbid in order to page, which means a page fault while
- forbidden is disaster.
Heh, a lot of people don't see the difference between the Amiga and another
computer such as the MacIntosh. The Amiga is a message-based multi-tasking
microcomputer. The keyword here is not only multi-tasking, but also message-
based. For any disk I/O which we want to perform, we have to send a message to
another task telling it to controll the disk. That means that if you have no
multi-tasking (we are in Forbid()/Disable() or in supervisor mode) we can not
pass any messages around.
On the MacIntosh, this would be no problem. Their disk handlers are not
separate tasks, but rather library routines executing under the context of the
task calling them.
Pop-quiz: On the MacIntosh, can you edit a file with WordPerfect while another
program is reading the disk under MultiFinger? Heh? Can a MacIntosh
multitask?
Valentin
_________________________________________________________________________
"An operating system without Name: Valentin Pepelea
virtual memory is an operating Phonet: (613) 231-7476 (New!)
system without virtue." Bitnet: 451061@Uottawa.bitnet
Usenet: Use cunyvm.cuny.edu gate
- Ancient Inca Proverb Planet: 451061@acadvm1.UOttawa.CAchk@dciem.dciem.dnd.ca (C. Harald Koch) (05/26/89)
In article <3818@sdsu.UUCP> lindwall@sdsu.UUCP (John Lindwall) writes: >And what about applications that use the ol' flush libs trick? You know, >you attempt to AllocMem multi-megabytes of ram just before terminating so >that any unused Libs and other resources get flushed. You expect the >AllocMem to fail but by flushing all unused resources, the user will not be >tricked into thinking the application ate the ram. With a VM system, the >AllocMem will succeed! You mean people don't write: char *cp; if (cp = AllocMem(0x7FFFFFFFL, 0L)) FreeMem(cp, 0x7FFFFFFFL); For this? Shame on them. -- Grandpa Charnock's Law: | C. Harald Koch NTT Systems, Inc., Toronto, Ontario You never really learn | chk@gpu.utcs.utoronto.ca (long-term address) to swear until you learn | chk@zorac.dciem.dnd.ca (my current job) to drive. | chk@chkent.UUCP (my AMIGA at home)
252u3130@fergvax.unl.edu (Phil Dietz) (10/10/90)
It's a pretty interesting idea though. The only way I could see this being done would be with a MMU. Theoretically it would be easy to emulate VM. Simply create a new Exec.library. All the subroutines that acces or create memory would have added commands and flags, such as a process id for each program and task. This task id would be held in a reserved area of memory in a memory map or hash section. Each task is alloted a certain amount of memory in each PAGE of memory. When the page is full, the underlying VM handler would swap pages, the program memory map areas would be found, and the memory program would run some more. The only problem is telling ALL software that all the memory is for private VM storage and that they should create memory VIA the nice exec methods. Other than this problem, vitual memory should be able to work with all programs. <will discuss more later> Phil Dietz <<<=================--------- Cheap Ad ---------===================<<< Phil Dietz SWL Lincoln 550 MEGS! 2 lines 252u3130@fergvax.unl.edu (402)421-1963 IBM, GIFS, MAC, AMIGA