) (06/28/91)
MUFTI writes: > Subjects: ... other Operation system as RISCOS > > Cause currently RISCOS has a lack of modern features ( all other > operation systems (accept the old operationsystems CPM,MSDOS,GEM and > AppleIIdos) are better in this cases ) like timesheduled multitasking and > we need a better Operationsystem ( or a rebuild of main parts of riscos to > allow such things ). > I think the very old UNIX version II (=MINIX) is such a operation system, > but is there still someone, who work to implement it ? > I heard nothing in last 2-3 month from Martin Patzel or from Albert Coelmans. As operating systems go, RiscOS ain't half bad. Okay, it doesn't support preemptive tasking, but then, that's not necessarily a problem. With an environment such as RiscOS, it provides all that's really necessary - interrupt driven routines for background operations, and cooperative tasking, which has lower overheads, and is generally more suitable to windowing software anyway. Threads (small processes) would be nice, but they could be supported within a single task (where you want them anyway) by an appropriate language. Modula-2 has coroutines, and you can also do them in C if you're really keen. Of course, there's no Modula-2 compiler for the Archimedes... come back Arthur! All is forgiven! I don't think demand paging is the way to go for virtual memory on the Archimedes (see previous comments) - task swapping (controlled by the scheduler) would be more appropriate, and in the Archimedes case (page size of 64K! Gak!) probably faster... sad fact of life. Unix version (release?) 2 = MINIX? Oh yeah, new one on me! Acorn already has a good implementation of Unix for the Archimedes architecture - RiscIX. I mean, it's POSIX compliant (so I've been told), BSD and System V compatible, and it runs Motif *fast* (on the R260 of course). Of course, Unix is 20 years old... so if you want a 'modern operation system', are you sure you want Unix? Ug!
as@prg.ox.ac.uk (Andrew Stevens) (06/28/91)
Ug! writes: >As operating systems go, RiscOS ain't half bad. Okay, it doesn't support >preemptive tasking, but then, that's not necessarily a problem. With an >environment such as RiscOS, it provides all that's really necessary - >interrupt driven routines for background operations, and cooperative tasking, >which has lower overheads, and is generally more suitable to windowing >software anyway. I agree in principle with with Ug's comments here but not in detail. Firstly, it is not at all clear that pre-emptive multi-tasking has higher overheads. It is harder to bolt onto an intially single-tasking substrate agreed, but not significantly harder to implement from the ground up. Existance proof: kernel of QL operating system, OS/9, etc etc.m Further I would say the overhead for RISC-OS's co-operative multi-tasking is high. Just try timing a few things with and without significant multi-tasking. UNIX (say) looks wonder-slick in comparison. That said, however, I suspect the much of the clamour for pre-emptive multi-tasking under RISC-OS would disappear if the co-operative multi-tasking was more sophisticated. E.g. 1. The current process scheduler seems minimal to say the least. It is hard to write programs that won't (unintentionally) either starve or hog the CPU. 2. There don't seem to be any easily accesible goodies to allow processes to tick away in the background when desired. E.g. something to trigger CPU release based on some *standard* scheduling interrupt. In effect: the functionality of the TASK module available when needed to any RISC-OS program. Workable threads under RISC-OS would be quite hopeless without refinements in this areas. Would you really always want a 3 thread program to get 3 times as much CPU as a 1 thread program? Also, the most useful application of threads tends to be to have something ticking away in the background whilst a foreground interaction thread grabs the CPU when it fancies it. >I don't think demand paging is the way to go for virtual memory on the >Archimedes (see previous comments) - task swapping (controlled by the > scheduler) would be more appropriate, and in the Archimedes case > (page size of 64K! Gak!) > probably faster... sad fact of life. This is almost certainly incorrect. Why swap in/out more than you have to? Few programs are smaller than 32K (max. MEMC1 page size). A lot are very much bigger. Even !Edit is 100 plus K bytes. I doubt it would even be that much easier to implement. All the fun of delivering interrupts etc to swapped programs would remain. I would agree that demand paging should not be compulsorary, but it would be damn nice if it were available when required. -- Andrew Stevens Programmming Research Group JANET: Andrew.Stevens@uk.ac.oxford.prg 11 Keble Road, Oxford, England UUCP: ...!uunet!mcvax!ukc!ox-prg!as OX1 3QD +44 0865 272563
) (07/01/91)
Andrew Stevens writes: > > Firstly, it is not at all clear that pre-emptive multi-tasking has > higher overheads. Size or time? There's a lot of support stuff, and arbitration mechanisms that aren't needed with a cooperative sheduler (semaphores, scheduling mechanisms, priorities, etc), and all that can take time. Also, a preemptive task generally needs more state. > It is harder to bolt onto an intially single-tasking > substrate agreed, but not significantly harder to implement from the > ground up. Existance proof: kernel of QL operating system, OS/9, etc. Yup! > Further I would say the overhead for RISC-OS's co-operative > multi-tasking is high. Just try timing a few things with and without > significant multi-tasking. UNIX (say) looks wonder-slick in comparison. Unix? You gotta be kidding! Unix is anything *but* real time. Of course, that does depend very much on the Kernel. And anything which needs real-time can still be done with RiscOS - just run it off an interrupt. > That said, however, I suspect the much of the clamour for pre-emptive > multi-tasking under RISC-OS would disappear if the co-operative > multi-tasking was more sophisticated. E.g. > > 1. The current process scheduler seems minimal to say the least. It is > hard to write programs that won't (unintentionally) either starve or hog > the CPU. Yeah - it's not the greatest, but it's better than many I've used. > 2. There don't seem to be any easily accesible goodies to allow > processes to tick away in the background when desired. E.g. something > to trigger CPU release based on some *standard* scheduling interrupt. > In effect: the functionality of the TASK module available when needed to > any RISC-OS program. That would be good - a generalised Background Task mechanism would be great. That sort of thing should be extended to nearly every resource, as in Apple Mac's system software. That has 'managers' for sound, timers, etc... > Workable threads under RISC-OS would be quite hopeless without > refinements in this areas. Would you really always want a 3 thread > program to get 3 times as much CPU as a 1 thread program? Also, the > most useful application of threads tends to be to have something ticking > away in the background whilst a foreground interaction thread grabs the > CPU when it fancies it. Three threads doesn't equate to three times the CPU time. > This is almost certainly incorrect. Why swap in/out more than you have > to? Few programs are smaller than 32K (max. MEMC1 page size). A lot > are very much bigger. Even !Edit is 100 plus K bytes. I doubt it > would even be that much easier to implement. All the fun of delivering > interrupts etc to swapped programs would remain. I would agree that > demand paging should not be compulsorary, but it would be damn nice > if it were available when required. I don't think so. Most WIMP tasks probably don't work directly with interrupts anyway - more likely to be a Module, which wouldn't be swapped. Also, just as in demand paging, you need not swap *everything*, only what's needed. Ug!