🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #12862

Re: Virtual Memory

#12862
From: Mark Huth
Date: Thu, 25 May 1989 19:47
43 lines
2152 bytes
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
Technical Details
Message-ID: <10956@behemoth.phx.mcd.mot.com>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!ncar!noao!asuvax!behemoth!mph
References: <8905222150.AA05890@jade.berkeley.edu> <10949@behemoth.phx.mcd.mot.com> <6969@cbmvax.UUCP>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!unmvax!ncar!noao!asuvax!behemoth!mph
From: mph@behemoth.phx.mcd.mot.com (Mark Huth)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory
Message-ID: <10956@behemoth.phx.mcd.mot.com>
Date: 25 May 89 19:47:40 GMT
References: <8905222150.AA05890@jade.berkeley.edu> <10949@behemoth.phx.mcd.mot.com> <6969@cbmvax.UUCP>
Reply-To: mph@behemoth.UUCP (Mark Huth)
Organization: Motorola Microcomputer Division, Tempe, Az.
Lines: 43