djhr@crosfield.co.uk (dave redman) (06/25/91)
About Virtual Memory, I actually wrote some code ( C and assembler ) that enables page swapping to and from memory to harddisc. I wrote to Acorn asking about how to hook it into riscos and was told in NO uncertain terms that riscos CAN NOT use virtual memory. It appears that this is because any page swap that occurs in supervisor mode will corrupt the supervisor return link, thus the code cannot re-start after the page fault. The only cure to this is to save the return link on entry to every supervisor mode subroutine that MAY get swapped. I managed to get BASIC to read and write to virtual memory including swapping, but I effectively reduced the amount of memory available for swapping by marking VIDEO (obviously), RMA and sub 8000 address space as NON mobile. I eventually gave up after getting the DATA-ABORT routine, and half the PREFETCH-ABORT working because I discovered that page faults that occur on instruction fetchs at a page boundary do funny things and needs extra code to fix it. I couldn't be bothered to work it out and after Acorn said they wouldn't tell me how to hook it into riscos anyway I just gave up. Anyway if you want to talk over my approach etc e-mail me. Actually, does anyone out there in netland know how I can convince the harddisc controller that the disc is partitioned ? ( means convincing riscos too ). I ask because the current version uses direct disc address writes for speed ( but via adfs ) but if the disc was compacted or the file ( that I use as swap space ) is not contigous then the disc gets trashed !!!! Having the ability to write to different partitions would solve this.. Ideas and sugestions will be gratefully accepted.. and I know it is possible because riscix MUST use partitions. Acorn - a chance at last for you to redeem yourself in my eyes !! dave. djhr@crosfield.co.uk
Gavin.Flower@comp.vuw.ac.nz (Gavin Flower) (06/26/91)
Looking at the market that Acorn is addressing the Archimedes/Risc-Os to, I think that virtual memory is inappropiate at this stage. When hard discs become standard on almost all Arcs, and certainly all new Arcs, then it might become a desirable option. If you really need virtual memory you should be looking at a "real" operating system like UNIX! Be careful of trying to force Acorn to make Risc-Os too complex, and difficult to configure, for the bulk of the users! I think a new entry level machine which starts at 4 Meg, upgradeable to 16, might be more appropiate. :-> what about me with my 1 Meg A310, groan... <-: -Gavin. -- The main "user" of well brought up, and educated, children is the community at large. So if you really believe in "user pays", charge the correct users - stop overloading parents with financial penalties. ******* These comments have no known correlation with dept. policy! *******
john@acorn.co.uk (John Bowler) (06/27/91)
In article <10396@suns502.crosfield.co.uk> djhr@crosfield.co.uk (dave redman) writes: >About Virtual Memory, > > I actually wrote some code ( C and assembler ) that enables page >swapping to and from memory to harddisc. I wrote to Acorn asking about how >to hook it into riscos and was told in NO uncertain terms that riscos CAN >NOT use virtual memory. > > It appears that this is because any page swap that occurs in supervisor >mode will corrupt the supervisor return link, thus the code cannot re-start >after the page fault. The only cure to this is to save the return link on >entry to every supervisor mode subroutine that MAY get swapped. Yes - this is the primary problem. There is more than one cure; the one used in RISC iX is to ensure that code which executes in supervisor mode (the kernel) never page faults - to do this the SVC mode code accesses addresses passed (via SWIs) from user mode using routines which ensure the virtual address validity before reading or writing. Because RISC OS doesn't do this, and does rely on R14 not being corrupted by LDR or STR, you cannot have a system which may invalidate addresses which *should* be valid (ie set up in memory controller). So there are two effects:- 1) In practice you cannot dynamically page SVC mode code in any operating system. Fixing this requires either at least one extra processor mode for address exceptions which is entered on the appropriate aborts and shadows (at least) R14, or that the SVC mode code not use R14. 2) SVC mode code which accesses (user mode accessible) pages which may be swapped out has to do something special. RISC iX guarantees (2), RISC OS guarantees neither. > I managed to get BASIC to read and write to virtual memory including >swapping, but I effectively reduced the amount of memory available for >swapping by marking VIDEO (obviously), RMA and sub 8000 address space as >NON mobile. Yes, you must do this - it really is a consequence of the hardware design, not the operating system. After all the trap vectors which are used by the CPU to tell it what code to execute on traps such as address exceptions are located in the *VIRTUAL* address space, not the physical address space. If you invalidate page 0 (addresses 0-0x7fff) the CPU can no longer handle address exceptions! > I eventually gave up after getting the DATA-ABORT routine, and half the >PREFETCH-ABORT working because I discovered that page faults that occur on >instruction fetchs at a page boundary do funny things and needs extra code >to fix it. I couldn't be bothered to work it out and after Acorn said they >wouldn't tell me how to hook it into riscos anyway I just gave up. LDM/STM cause obvious problems if they go from a valid page (address) to an invalid one. The PC value relative to the actual address of the faulting instruction is different with prefetch aborts to the relative value with data aborts. The code is tricky but probably no more tricky than it is on most other CPUs - if you want to give yourself nightmares try writing the corresponding code for the i860. Anyway, the point is that you *can't* hook it in without rewriting RISC OS. On the other hand swapping, rather than paging, could be implemented with less work. With swapping whole (RISC OS) tasks would be swapped to and from RAM when the current task changes; the current task is always completely present. Page faults are then only possible if some part of the system knows where a task other than the current task is. In RISC OS the wimp manages (indeed, implements) tasks, and only the wimp knows about tasks other than the current task - to implement swapping all you have to do is rewrite the wimp :-). You might even be able to do it by fooling the wimp into believing that there is more memory available than there really is and by intercepting attempts by the wimp to map that (non-existent) memory into the virtual address space, on balance, though, it is probably easier to change the wimp ;-). Given the limitations RISC OS imposes on the size of a task, the size of the MEMC pages, and the granularity of task swapping in RISC OS, the traditional advantages of paging over swapping are considerably lessened anyway. > Actually, does anyone out there in netland know how I can convince the >harddisc controller that the disc is partitioned ? ( means convincing >riscos too ). I ask because the current version uses direct disc address >writes for speed ( but via adfs ) but if the disc was compacted or the file >( that I use as swap space ) is not contigous then the disc gets trashed !!!! >Having the ability to write to different partitions would solve this.. > > Ideas and sugestions will be gratefully accepted.. and I know it is >possible because riscix MUST use partitions. If you have an Acorn SCSI disc system SCSIDM allows the partition sizes to be set. You have the option of making the disc into a single RISC OS partition or of allocating RISC iX partitions as well - however, once you've done this to access the non-RISC OS partitions from RISC OS you have to go directly to the SCSI driver. If you have an ST506 drive you can convince RISC OS that the drive is smaller by appropriate changes to the formatter; I believe that ADFS retains all the disc sizing information on the disc itself. Again you have to go directly to the device to access the parts ADFS cannot see (I don't know how difficult this is under RISC OS). John Bowler (jbowler@acorn.co.uk)
) (06/27/91)
Gavin Flower writes: > > Looking at the market that Acorn is addressing the Archimedes/Risc-Os to, > I think that virtual memory is inappropiate at this stage. When hard discs > become standard on almost all Arcs, and certainly all new Arcs, then it > might become a desirable option. I disagree. Acorn is targeting a very similar market with the Archimedes to Apple with the Macintosh. System 7 now includes virtual memory. I think virtual memory is now almost essential for the Archimedes. The top line models all sell with Hard Drives now. > If you really need virtual memory you should be looking at a "real" > operating system like UNIX! Hmm. Unix has a lot of problems. Firstly, *which* Unix? This is a 20-year old operating system... I prefer OS/2 myself. Still, cooperative scheduling seems to be the way to go for event-driven architectures. The overhead involved with task switching is so much lower. This is why I find running RiscOS on my 305 faster than OpenWindows on a Sun. > Be careful of trying to force Acorn to make Risc-Os too complex, and > difficult to configure, for the bulk of the users! You get that with any complex system. Do you want a toy, or a real computer? But adding virtual memory wouldn't make things much more complex - it's done reasonably well with Microsoft Windows 3. > I think a new entry level machine which starts at 4 Meg, > upgradeable to 16, might be more appropiate. > :-> what about me with my 1 Meg A310, groan... <-: Know the feeling... I run a 305 expanded to 2 MBytes with 2 floppies. I can't afford a hard drive, sob sob. Ug!
nbvs@cl.cam.ac.uk (Nicko van Someren) (06/30/91)
Back when RISC OS first came out there was very little need for VM on the
Archimedes simply because there was very little software around to run. Now
that users have a large software base at their disposal they are tempted to use
it and use up memory in the process. As far as I can see there are two main
problems involved in giving RISC OS virtual memory. Firstly the kernel and
modules of the OS do not cope well with data aborts and secondly not every one
has a fast 'swap device' to use as the backing store.
The first problem is in fact not as bad is it might be. In RISC OS tasks only
ever get switched during a WIMP poll. If we made the provisions that a) the
memory in the RMA, screen (naturally) and system areas never got swapped out
and b) No task could have a WIMP slot bigger that the physical memory size then
we could forego true VM for paged applications. A task could ask for a slot
of any size as long as it was capable of fitting in memory in one go and then
all or part of the WIMP slot could be stored to disk when the task was not
the active one. While this has many drawbacks, for instance the system does
not know when a page has been touched so it must save any page it wants to
swap out, it does give a workable VM system as far as the user is concerned and
further more the only changes to code that need to be made are rewrites of the
WIMP paging code and the WIMP call that fetches memory from another tasks work
space.
The second problem, that not all users have a fat paging device, is in my
opinion not a reason not to do the job. RISC OS file switch is fast enough
that the WIMP could be made to page to a file, the size of which could be set
by the user. Since any application that is paged in is always all in memory
when it is running, and since the filer application is in the RMA, you could
even set up to page to an 800K file on a floppy on an A3000 and file switch
and ADFS would prompt you to change discs at the right moment. Users of
bigger machines could use there hard discs and if you have eco/ether net then
the paging could happen there.
Acorn have, in the recent past, declared that they are a 'Market driven
company'. We, the users of usenet, are your market Acorn. SO GET ON WITH IT!
Nicko
+-----------------------------------------------------------------------------+
| Nicko van Someren, nbvs@cl.cam.ac.uk, (44) 223 358707 or (44) 860 498903 |
+-----------------------------------------------------------------------------+