Drobe :: The archives
About Drobe | Contact | RSS | Twitter | Tech docs | Downloads | BBC Micro

Imagining RISC OS and PMT

By Chris Williams. Published: 26th Jul 2003, 21:10:57 | Permalink | Printable

Wimp2 illustrates what it'd be like [Updated]

Editorial Recent discussion in the drobe.co.uk comments and forums has resulted in recurring calls for RISC OS to gain fundamental operating system features enjoyed by other platforms, notably pre-emptive multitasking (PMT) and full memory protection. Whilst the RISC OS desktop is a cooperative multitasking (CMT) affair, a PMT solution does exist in the form of Niall Douglas' Wimp2 which we'll look at in a moment.

Firstly, we'll briefly explain the differences between PMT and CMT. The RISC OS desktop is a multitasking one as it allows many applications to seemingly run at the same time, from the user's point of view. The computer's processor can execute only one program at a time but the operating system can step in so a given program executes for a while before another program gets time with the processor. This sharing of processor time among programs creates the illusion that multiple programs are running simultaneously.

CMT and PMT are merely different ways of going about and both methods have their advantages and disadvantages. With cooperative multitasking (CMT), individual applications determine how much processor time they receive. Once an application has finished responding to an event, such as a mouse click, or when the application feels it's had its fair share of the processor, the application tells the operating system to move onto the next program waiting for processor time. The OS then pauses that application and tells the processor to resume executing the next application. This passing of control is almost cyclic, as eventually the processor will return to continue executing the original application. The downside to CMT is that if an application crashes or gets greedy and doesn't allow other applications to have time with the processor, the desktop grinds to a halt and multitasking ceases - RISC OS users will be painfully aware of this.

On the other hand, in pre-emptive multitasking (PMT), it's the OS that decides when an application begins and ceases executing. Usually, the OS employs a hardware based timer to measure how much time an application has spent with the processor. When an application has been running for a defined amount of time, the operating system steps in to pause the application and resume the execution of another application. The benefit of PMT is that no application can hog the processor as each application is generally given an equal amount of processor time.

As previously stated, RISC OS uses CMT to acheive multitasking while other operating systems like Microsoft Windows and the Linux kernel use PMT. PMT does indeed appear to be far more beneficial than CMT and if RISC OS adopted a PMT environment, we would see the end to situations like !ChangeFSI hogging the processor whilst processing images.

Wimp2
So with that in mind, we gave Wimp2 a shot. Wimp2 is a module that works with RISC OS 2 to RISC OS 4 (it's not 32 bit yet) and it basically enables pre-emptive multitasking on RISC OS. Applications can either talk to Wimp2 to set themselves up to multitask pre-emptively or a supplied patch by Andrew Teirney can be run which transparently converts CMT based software to PMT on the fly. This means software like Oregano and StrongED can be made to multitask pre-emptively without any modifications.

Wimp2 has quite a history, which is worth reading. Its author, Niall Douglas, started development back in 1994 as part of his "regeneration of RISC OS" project called Tornado. Version 0.36, the latest version online, was completed in 1999.

Screenshot of Wimp2'ed apps in action
Photodesk running over Wimp2 and multitasking pre-emptively


The good news is that the sources to Wimp2 and the aforementioned patch are available and Wimp2 appears to be released under the GPL, so a 32 bit version is possible and it's also possible for people to improve it and fix it. The source came in handy when I tried running the patch on my RISC OS 4.36 RiscPC as I had to comment out the code that checks for the OS version.

Attempting to run Wimp2 from my boot sequence resulted in multiple aborts and crashes so I decided to play it safe and try it out once the desktop had been fully reached and set up. Once Wimp2 and Andrew's patch are running, CMT based applications can be filtered to be executed as PMT tasks when first run (see screenshot below), and your choices are saved to disc as appropriate if you don't wish to be asked again. Alternatively, application names can be manually added to a textfile to define behaviour like how much processor time each application should ideally be given or to exclude some applications from being run as PMT tasks. This is useful if a CMT based application crashes when forced to run as a PMT application although some applications refuse to be excluded from being run as PMT tasks which leads to problems.

Screenshot of Wimp2'ed apps in action
Would you like fries with that?


RISC OS 4 users may wish to exclude !Configure and its 'Generic plug-in' task from being executed as PMT tasks. To be honest, you will need to set aside some time to configure and set up the Wimp2 package to be just right, excluding software that crashes with Wimp2 and finding software that massively benefits from it. Any applications that use the Toolbox run in to problems, which includes OvationPro. It was beautiful, however, to see a ChangeFSI (running as a PMT task) processing a 1600x1200 32k colour spritefile whilst the rest of the desktop continued to multitask smoothly. Another processor hog tamed by PMT, Oregano formatted a huge HTML file whilst the rest of the desktop happily multitasked.

Toolbox issues aside, another problem was redraw. When a window in the RISC OS desktop needs updating or redrawing, the window manager orders the application, to which the window belongs, to find out which areas of its window need redrawing and to do the necessary graphics operations. Under CMT, the application would normally update its window and pass control to the next application. Under PMT with Wimp2, it would appear an application redrawing its window is being forced to multitask every so often when it should be redrawing. This reduces window redraw speed and also causes flickering. Scrolling this StrongED text window or dragging a window over an image being edited in Photodesk is slower than when the applications are running in CMT mode.

Despite these problems, Wimp2 is certainly entertaining to play with if you have the time and the sources are available if you want to improve the modules. The GPL nature of the module rules out any possibility of including the module code in RISC OS but Wimp2 does give a good indication of what RISC OS would be like if the OS were to adopt a PMT environment to replace the CMT system in place at the moment.

Update
Wimp2 author Niall Douglas kindly sent us these comments, regarding this article:

"Actually the redraws are slow because Wimp_UpdateWindow is used instead of Wimp_RedrawWindow plus the Wimp actually makes a special case with window redraw requests (it calls the app directly from the "move window" or "close window" implementation code).

"Wimp2 does nothing for redraw requests, just saves the area into a buffer which it then passes to the app when it's ready for it.

"I should mention that if you write your RO application to natively use Wimp2 then all the problems just go away. Flaky behaviour is 100% caused by the patch which has to do really nasty things under the bonnet. While I never actually wrote a large program using Wimp2, I did port RO2 Maestro to it and it ran very nicely indeed. Things like display redraw speed are much faster if your app is aware it's being preempted and you take the appropriate steps."


Niall also pointed out that only user level code can be pre-empted by Wimp2 and therefore operating system level code can't be. That is, when an application asks RISC OS to perform a lengthy task, like load a file from disc into memory, multitasking ceases until the operating system is done. Wimp2 does make an attempt to at least keep multitasking going when an application uses the OS provided OS_File SWI.

Links

Wimp2

Previous: Future ARM based processors for RISC OS?
Next: Repairing, restoring legacy Acorn kit

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

One of the main issues with using PMT under RISC OS is that so many applications assume that they're being co-operatively multitasked, which can screw what they do around message passing. :(

A solution to this might be that you could patch Wimp2 to swap to CMT when using message passing or issuing redraw requests.

What also might be interesting is to fiddle with Wimp2 to make it use Simtec's threading module, so you can take advantage of a Hydra if you have one. Don't know if it'd be possible, but it'd be fun. :)

 is a RISC OS Usernunfetishist on 27/7/03 7:20AM
[ Reply | Permalink | Report ]

Why does the GPL rule out the use of the code in RO? - a seperate license could be obtained couldn't it? Or the module could be supplied with it?

Was wimp2 designed as an interim stage to a fully PMT RO?

Does it in effect make all the PMT apps into one CMT process?

With a properly PMT RO would a CMT module running as a single PMT allow non PMT apps to run? -- Jess

 is a RISC OS Userjess on 27/7/03 9:34AM
[ Reply | Permalink | Report ]

If RISC OS applications weren't written by braindead authors in the first place, they'd cooperatively multitask properly and the desktop would never "lock up". It's easy to make CMT work well -- we developed a complete CMT mp4 media system at work with none of these issues that RISC OS desktop has - it just needs authors to stick to the rules.

CMT has plenty benefits over PMT, which Chris hasn't mentioned in the article, not least of which is much reduced complexity and no need to guard against threading, mutexes and all the nasty concurrency problems you get with a PMT system.

PMT is not the "big thing" that RISC OS lacks. Adding it will not make everything suddenly work better - even if you rewrite every application! All the article here has shown is that it works around a few poorly written programs.

 is a RISC OS Userimj on 27/7/03 10:50AM
[ Reply | Permalink | Report ]

One area where PMT could make a huge improvement is printing. Impression is about the only app I use which makes a half-hearted attempt to stop the desktop grinding to a halt whilst doing so. Chris, did you have any success with Wimp2 when printing from apps? -- Govind Kharbanda, Edinburgh

 is a RISC OS Usergovind on 27/7/03 11:06AM
[ Reply | Permalink | Report ]

People could get confuse with the initials "PMT" you know!

 is a RISC OS UserTimothy609 on 27/7/03 11:53AM
[ Reply | Permalink | Report ]

Good grief! I find myself agreeing with imj - better go and take an angry pill!!!

Neil

 is a RISC OS UserNeilWB on 27/7/03 12:33PM
[ Reply | Permalink | Report ]

"just needs authors to stick to the rules"

Which is hard when the market relies on conversions from platforms running PMT systems.

With a PMT system RISCOS dictates to programs what resouces it can have for a set period of time, not the other way around. It allows the OS to stay in control.

I would disagree that PMT is not important, if you've tried rendering big webpages and media, printing and networking under RISCOS it becomes annoying having to wait on applications to gain control of the desktop again.

A way forward for PMT with RISCOS would probably be nunf's suggestion of swapping to CMT when needed.

 is a RISC OS UserPlugwash on 27/7/03 12:35PM
[ Reply | Permalink | Report ]

I'm not sure that using CMT over PMT *does* reduce complexity at all. In fact, it can increase it. Writing a primitive, but still useful, PMT scheduler is not difficult, and isn't that much code. What it does do though, is make writing multitasking applications much easier - you don't *need* to think about things. At this point, using Wimp_Poll is just like using select() on a Unix to wait for something to happen that you're interested in. Mutexes, and other forms of syncronisation are easily avoided if you only want one thread per process, and you're not doing memory sharing of any type (and the only memory sharing that RISC OS applications commonly do only happens when doing Drag-n-Drop, and this can be easily guarded against to prevent problems.)

CMT is useful occationally - if you spend a lot of time getting everything perfect, you can get better throughput, but at the cost of developer time. Under certian circumstances, it can make creating a highly reliable system very difficult to make. If one of your processes go haywire, another "watchdog" program can't sort things out (for example).

Considering the number of OSes that were around at RISC OS' conception, it really should have had PMT from the start. (And they even tried doing it, on top of Mach later on, with the RISC OS Gold project.)

 is a RISC OS Usernunfetishist on 27/7/03 12:37PM
[ Reply | Permalink | Report ]

Impression is odd because it uses CC's multitasking printing system, not Acorn's. So Impression with Turbo drivers or LaserDirect works much better. Printing has 2 stages, creating the data and sending it to the printer. The sending part multitasks fine now with Print in Background enabled, the creation part reqires the app to call Wimp_Poll if it's taking too long.

It's not usually the apps taking ages I mind, it's things like failing to connect to network drives, CD reading etc which stop multitasking until they time out.

 is a RISC OS Usermavhc on 27/7/03 12:37PM
[ Reply | Permalink | Report ]

CMT versus PMT that old chestnut....

Oddly I find myself in agreement with imj on this. Good code will work correctly with CMT bad code won't.

Perhaps in addition to setting things like a WimpSlot on start up code could indicate a maximum time between poll calls and then if the code *doesn't* do a poll within that period the OS simply either terminates it (and cleans up) or at least asks the user if it should. What do you think ?

-- Annraoi McShane,

 is a RISC OS UserAMS on 27/7/03 2:01PM
[ Reply | Permalink | Report ]

cor another groovy article.

Quick illustration of when PMT can go glands up:

There is a piece of software we rely on at work which has its roots in Windows 3.1.

It uses a SQL4 database.

When it is "importing" (actually pkUnzip!) it behaves as if it is single tasking.

You cannot use the machine for anything else.

If you do and windows (presumably from what i've read above) passes some processor time to something else, you run the risk of data corruption.

Nice isn't it?

The screen redrw issues that Chris mentions above will also be familiar to windows users - how many times have you seen a window lose its contents while another app is hogging system resources.

OK my examples are due to pants (read lazy...) application coding and a pants OS , but, as has been said not every cloud will contain Ag...

 is a RISC OS Userepistaxsis_RISC OS on 27/7/03 2:29PM
[ Reply | Permalink | Report ]

AMS:

Perhaps a default pre-empt time could be defined in Configure which could be over-written by a command in the !Run file as you described (useful for development).

A problem might arise when a task is doing something whose timing is outside its control, such as saving a file. Possibly calls to SWIs to do such things could over-ride the pre-emption time and/or the application could call a SWI before doing such things which would temporarily extend the pre-emption time - possibly until the application next called Wimp_Poll.

Such a system could reduce instances of the machine totally hanging because an application had crashed. One for Select, perhaps.

Martyn

 is a RISC OS UserMartyn Fox on 27/7/03 3:01PM
[ Reply | Permalink | Report ]

imj> I fail to see how CMT can compete in the real world.

1) There will never be a 'perfect' written app. In RISC OS, if an app doesnt yeild and gets stuck in a loop then it will be alt-break, or reboot time. No app is perfect, and will have bugs. This is particularly useless or annoying if you are trying to remotely control a RISC OS box from 50 miles away, and an error dialog pops up on screen causing multitasking to stop. (ignoring the modules around that frig error dialogs to multitask)

2) Every *consumer* desktop OS (apart from RISC OS) has moved to a PMT model. The most recent case is Apple going from OS 9, to OS X. I fail to see a place for CMT when the rest of the world is using PMT and deals with threading, mutex and other such problems just fine.

 is a RISC OS Userpiemmm on 27/7/03 4:27PM
[ Reply | Permalink | Report ]

Thought I'd mention that there was a thread about the CMT/PMT issue on either IconBar or Acorn Arcade a while ago where some programmer (memory error) talked about writing multiplayer network games being "difficult" to say the least on CMT.

I agree that CMT has it's uses but there must be a reason why Windows and MacOS have moved to PMT and Linux/UNIX and BeOS were PMT from the start.

-- Gunnlaugur Jonsson, Copenhagen, Denmark

 is a RISC OS UserGulli on 27/7/03 6:23PM
[ Reply | Permalink | Report ]

I used Wimp2 for years, And I can say for several programs it was very damn useful, but for virtually everything that either didn't use up a lot of processor time or had issues when it was enabled I left it out.

Bigest annoyance was Draw, the redraw of the window caused the grid to go haiwire, a few programs didn't like it, but on the whole it was happy there for years until I decided It really wasn't woth the possible problems for the minor improvement.

PMT on RISC OS is possible as is memory protection, but boy is it going to break a lot of things along the way, would have been best if RO5 had the features from the start, then authors would have only had to fix once and carry on.

 is a RISC OS UserNoMercy on 27/7/03 7:22PM
[ Reply | Permalink | Report ]

NoMercy> PMT on RO5 select then?

;-)

 is a RISC OS Userepistaxsis_RISC OS on 27/7/03 7:24PM
[ Reply | Permalink | Report ]

Gulli> Writing multiplayer network games under co-operative versus pre-emptive multitasking is really no difference in complexity - if someone has a good reason to believe that that isn't the case then I'd really like to hear it.

Network games have to account for a number of 'features' of the network, one of which is the delay in message delivery. This delay is usually due to the time taken to trasfer the data from one machine to another. Part of that transfer process is that of buffering. The buffering in a CMT system is implicit within the applications being written. Therefore the only difference is that other applications can cause the transfers to take longer. A loaded PMT system can exhibit the same effects.

Since you have to take account of the possibility of this delay anyhow because you know for a fact that the network latency is not going to be constant and that there may be issues with certain connections, you're not adding any complexity at all for a CMT system over a PMT system.

All this applies to a game which requires messages to be delivered for 'frames' of the game (eg Doom). A game which includes prediction within its networking is explicitly coping with the delay in delivery.

A turn-based game should have no issues with the type of environment it is being run under because the messages are (usually) transfered using TCP (rather than the UDP which is assumed in the above comments) and the timing of their delivery is not critical anyhow.

I'm pretty sure that CMT introduces precisely zero complexity for a CMT environment over a PMT environment when it comes to network games.

Obviously my experience with network games comes to a limited selection - Doom, Heretic, Hexen, 0verkill for frame-based, and NetOXO, NetC4 for turn based. The former 3 are ports from single-tasking environments, 0verkill from a linux application, and the latter 2 are native. I've not written a native multi-player network game which has been seen by the outside world, so if anyone wants to shed any light on why that's any different I'd love to hear from them.

 is a RISC OS UserGerph on 27/7/03 9:25PM
[ Reply | Permalink | Report ]

Much as I hate to be a "me too", and much as I'd like to see PMT, I have to say that there is little requirement for it in GUI programs that are ported from other OSes. (I won't mention CLI programs/taskwindows, because that's another issue)

X Windows apps, SDL things, even MFC Windows apps (I can't speak for anything else) rely on polling of some kind simply to keep informed about what's going on from the OS.

Far more useful (but still an unusual requirement) for these apps is comprehensive threading support.

On the other hand, the above Win 3.1 Windows app is not a good example - I understand that there are certain classes of Win 3.1 applications that cannot be properly PMTed. This can be attributed to the design of Windows rather than anything else.

-- Peter, drobe.co.uk

 is a RISC OS Usermrchocky on 28/7/03 10:03AM
[ Reply | Permalink | Report ]

What exactly is threading support? If I understand correctly, threading means multitasking within one task? I.e. sharing variable/application space? Is it possible to implement that without implementing PMT? -- Jan-Jaap

 is a RISC OS Userjjvdgeer on 28/7/03 12:08PM
[ Reply | Permalink | Report ]

There are two kinds of threads, kernel level (KLT) and user level (ULT). KLT requires OS support (which almost all do, except RISC OS of course). The big advantages of KLT are: 1) Different threads can execute concurrently on a multi-processor machine. 2) If one thread blocks on a system call it will not block the other threads in the process. ULT's are implemented using a thread library (I think there are/were a few for RISC OS) and don't require any OS support. To answer your question, user level threads do not require the OS to support pre-emptive multitasking.

 is a RISC OS Userrob on 28/7/03 4:46PM
[ Reply | Permalink | Report ]

Threading is on a totally over-simplified level, splitting a program up into several sperate parts which can run at the same time, redrawing a window while sorting out a HTTP request for example, but both parts of the program share the same memory and other resources, Adds a whole new dimension to programming.

There's a few Thread-like things you can do under CMT, but to be done well it really needs PMT.

 is a RISC OS UserNoMercy on 28/7/03 5:01PM
[ Reply | Permalink | Report ]

Gerph:

I don't claim to know the first thing about writing multiplayer network games (other than that it's possible to do so), I was simply mentioning that a programmer had spoken about it being difficult. I think it was one of the VOTI team or developers of TEK (still not sure), the need was at least for a realtime game.

If it's as "easy" as you say it makes me wonder why TEK wasn't developed as a multiplayer game or hasn't been since.

(easy is within quotes because I doubt that it's in fact EASY to write any sort of a networked multiplayer game - on CMT or PMT)

-- Gunnlaugur Jonsson, Copenhagen, Denmark

 is a RISC OS UserGulli on 28/7/03 7:11PM
[ Reply | Permalink | Report ]

I imagine it's a matter of gameplay rather than technical difficulties. It's not the networking code that's tricky - multiplayer versions of normally two-player games are often quite different, either in rules or more fundlementally. Essentially, you often end up having to write two games - just two that share graphics and engine. This is quite a lot of work, and I imagine they skipped it so they could actually get Tek out of the door.

 is a RISC OS Usernunfetishist on 28/7/03 10:39PM
[ Reply | Permalink | Report ]

My point is that a lot of people forgot someting important : PMT eats CPU power (and CMT less). About 40% of an Amiga 1200 processing power, up to 100 MHz of CPU power on a real time PMT as the one included inside BeOS.

That's a lot. The idea to have PMT is good... Best idea would be to have a !Configure plugin for it, with an option to switch all PMT applications to CMT, when needed. When you use a higly integrated application alone, you'll be able to get the maximum processor power.

And RISC OS will keep also something that not a lot of OS have : flexibility (OK, Linux can also change of Scheduling model on the fly).

 is a RISC OS Userdfeugey on 29/7/03 10:29AM
[ Reply | Permalink | Report ]

PMT eats CPU time? What on earth are you on about? What part of of it eats the CPU time? It can't be the context switching - every multitasking OS does that - including RISC OS, and the overhead of catching a timed interrupt and doing the context switch there can be made very lightweight indeed. In most OSes, PMT increases throughput massively.

As for BeOS: 100MHz of *what* ? Just saying 100MHz is meaningless. And considering I've worked for real-time OS companies (QNX in this case) I can say for definate that real-time PMT schedulers are much easier to write than CMT ones, and are almost always significantly quicker.

 is a RISC OS Usernunfetishist on 29/7/03 12:48PM
[ Reply | Permalink | Report ]

I second nunfetishist on this one: there's no reason for PMT to make a machine significantly slower. You have to do almost exactly the same amount of work in switching between applicaitons - you have to save the old one, pick the next one, and then load it and run it (the only additional overhead is setting up the timer interrupt really).

The only overhead there may be is that you switch applications more often because some application using CMT isn't releasing very often. I.e., PMT has a more regemented set of switching routines. But most modern PMT systems switch in the order of 10 ms intervals (unless some I/O interrupt forces a change). That may seem a short time, but on a 400 MHz processor that's 40,000,000 instructions you get on each shot.

Personally I prefer PMT because I'm an OS purist - the only entity in a system that can really make a fair distribution of any resource is the system is the operating system, as only it has the complete picture. Obviously some apps may like more time than the OS gives them, but this is down to how the actual scheduler works rather than it being a PMT versus CMT. The other benefit of PMT is security. "braindead" programmers exist, as do "good old fashion honest mistakes", and under a CMT system you'll get fried.

Also PMT means never having to say "yield" ;)

Well, unless you really want to ;)

-- Dougal

 is a RISC OS UserDougal on 29/7/03 2:04PM
[ Reply | Permalink | Report ]

You cannot say that CMT as the same processing power needs as PMT... That's not true. Application switches when it decides to, so when there are less things to save on the stack. Application doesn't have to cope with a possible "unwanted" switch, so less code to implement...

With a PMT model, a switch at the wrong time can cost you a lot. If the stacks to save are too big... For example.

Sometimes CMT scheduling and interrupts are more efficient than a PMT solution, since you can determinate the exact time needed for a task and the exact processing power available for this task. This model is more "predictive" ; that's why Linux can use this type of scheduling in it's embedding form.

So to drop it would be an error... I prefer the "two engine" solution (I have nothing against PMT, but just against things or technologies that you cannot switch off when needed, that's why I love Wimp 2 :)

 is a RISC OS Userdfeugey on 29/7/03 5:05PM
[ Reply | Permalink | Report ]

Hang onto CMT for backwards compatability by all means, but no /modern/ OS server,desktop or embedded, lacks PMT these days, to the best of my knowledge. Even if PMT were slower, if I can continue to work while my machine is processing stuff the background it has to be a good thing. I find it fustrating at work when I have someone on the phone, and I have to wait for my Mac to load a file or something, it would be downright embarrasing if I had to wait for tasks to complete before I could do *anything* on my machine.

 is a RISC OS Userthegman on 29/7/03 5:38PM
[ Reply | Permalink | Report ]

dfeugey: You forget that a CMT context-switch still requires stacks to be saved. You also forget that you're moving the complexity by using PMT, not increasing it. While your scheduler has to to more work, your process has to do much less. An application shouldn't ever know, or care when it's been pre-empted. It doesn't *need* to have to cope with an "unwanted" switch, as you put it.

Please state an example of where switching at the wrong point costs you more than having to switch to something that's got a higher priority not happening. If you're playing a movie file, or something, that's the busy process. If something else needs to use the CPU, let it. It nothing needs it, the scheduler returns straight back to the movie player.

Linux has many scheduling schemes - the default is a "fairness" scheme, which is perfect for servers, but less so for desktops. But pre-emptable kernel patches, and pluggable schedulers in 2.6 fix all this.

The only problem with dropping CMT in RISC OS is so many applications make foolish assumptions, which would break.

Please, stop the PMT FUD. For almost all purposes, it's a far superior system, which most RISC OS users don't appear to fully understand. :(

(Example for how PMT can *vastly* improve things: Notice how Linux has roughly comparable throughput to RISC OS (in in some cases, more)? Then note that RISC OS is written in assembler, written by the people who designed the CPU. Linux is mostly C, and was never really designed to leave the world of the 80386.

RISC OS is drastically out-dated in many ways these days, compared to even AmigaOS in many ways. Let's not try to come up with silly reasons for not modernising it. Let's come up with real ones. (Like PMT would break too many apps, not because it's slower. :)

 is a RISC OS Usernunfetishist on 29/7/03 8:46PM
[ Reply | Permalink | Report ]

Nice one nunfetishist. I feel it's also worth pointing out that PMT is not some new-fangled technology, it was around a good few years before Acorn was founded.

 is a RISC OS Userrob on 29/7/03 9:52PM
[ Reply | Permalink | Report ]

>Please, stop the PMT FUD. For almost all purposes, it's a far superior > system, which most RISC OS users don't appear to fully understand. :(

I think, no offence, that you misunderstood my point. I just wanted to say that if Acorn did not choose this model it was probably because of the processing power overhead (too much probably to get the best of an ARM2).

Now if you want me to give my opinion for the future, that's clearly different. I don't want a "PMT only model" but a "multiple model". For example a PMT model for "desktop use" that can be blocked on the fly when you need more power for the only application you really use at that time (PAO, games, video). You can block it entirelly (fullscreen application) or just switch to CMT model (desktop application)... Of course for a multimedia API you could need also to have a RT model.

So keep and improve Wimp2 (for example with a function to stop all tasks, when a game is launched), rewrite desktop applications for it, integrate it in standard RISC OS Select or 5.0, but do not drop the CMT model. Just keep it for these specific applications (Ashiv or Pace ones). There is no overhead to have a an unused model inside the system. See the operating system as what it is : a toolbox, a massive API for applications. don't think, as Apple, that you can force people to adopt technologies... Just give choice.

Wimp2 is really the perfect idea IMHO (and I really wanted to have it by myself)... Don't make the Apple error : too much new technologies, too much processing power overhead and only 50% of users (and so developers) that switched to the new system (with 99% of them that switched back to MacOS 9 for games or emulation).

 is a RISC OS Userdfeugey on 30/07/03 09:17AM
[ Reply | Permalink | Report ]

Hello David, If PMT did slow down RISC OS then it might be a problem, but I really don't think it would, there are lots of fast, snappy Operating Systems with great, pre-emptive multi-tasking. I had a go of Wimp2, i think it's an incredible piece of work, but as it says in the article, low-level file access stuff is not made pre-emptive, which I think would need core RISC OS work to fix.

Apple did put a load of technologies into the Mac with the release of OS X, but as the stuff they added (Cocoa, Quartz,Objective C) are all utterly brilliant and light years ahead of RISC OS and the 'old' Mac, not that many people mind, I don't think. I don't agree with your assumption that because 50% of users did not switch (yet) that developers did not, on the Mac, developers are generally quite big companies, even the shareware ones often have offices and staff, and cannot afford *not* to switch. Also, 50% is not that bad a number, what percentage of RISC OS users have gone to RISC OS 5, Select or even RISC OS 4? I don't think it's 50% of all users (well I hope not, looking at sales of RO4/Select).

Anyway, despite all that, I'd still take an Iyonix over a Power Mac any day of the week (heart ruling my head).

On a different topic, any chance of your Linux boxes running RISC OS any time soon?

 is a RISC OS Userthegman on 30/07/03 11:11AM
[ Reply | Permalink | Report ]

"I just wanted to say that if Acorn did not choose this model it was probably because of the processing power overhead"

Almost certianly not. Arthur was fudged together because ARX (the OS that was meant to run on it, and had PMT) was woefully behind schedule. Then there was RISC iX. Acorn's UNIX, which had PMT. Then there was the failed attempt to create a RISC OS-like operating system ontop of the Mach microkernel (RISC OS Gold, whith PMT). The ARM even had an instruction added to it to allow easy implementation of mutexes and other synronisation techniques (SWP - don't use this unless you want a mutex - it's slow). Acorn clearly wanted PMT on their earlier machines, but kept failing trying. PMT has no noticable processing power overhead over CMT. In most cases, it provides a speedup. Please cease saying otherwise.

The multiple model of which you speak is a little pointless - that's exactly what priorities are for under PMT systems. (Or even dynamically adapting priorities, like Linux's)

Personally, when I'm running, say VMware on my Linux box fullscreen, I *don't* want everything running the background to stop. That'd just be irritating.

Select has provided a much richer API for programmers to enhance their software. And from what I can tell, very few people actually want to use them, because they don't want to tie their software to something that only a minority of RISC OS users have. Unlike Apple, they're not forcing people to adopt new "technologies", they're simply putting them there for people to use, and people deciding against it. Seems a bit of a shame, really. What I would have liked to seen is RISC OS Select do many under-the-bonet things and user-facing things that you can only get with Select, but distribute the API differences to run on earlier version of RISC OS. At least more people would use all of RISCOS Ltd.'s work that way, and people would still have reason to upgrade to Select if they wanted. (In other words, there's a lot more to a new version of a desktop OS than just a new API - you need all the funky toys, like the thumbnail viewer in the filer, and such.)

I'd just like to point out that Mac OS X's slowness is *not* because of it's use of PMT, or many new technologies. It's because it spends a huge amount of time and memory making it look pretty, and that it's based on Mach (which Acorn also found out wasn't worth the effort.)

 is a RISC OS Usernunfetishist on 30/07/03 11:19AM
[ Reply | Permalink | Report ]

This article is a few years old, but it highlights the advantages/disadvantages of PMT and CMT.

[link]

No mention of RISC OS I'm afraid....

 is a RISC OS UserWalks on 30/07/03 1:34PM
[ Reply | Permalink | Report ]

another interesting article: [link]

 is a RISC OS Useranon/80.181.158.218 on 30/07/03 1:57PM
[ Reply | Permalink | Report ]

The mackido site seems to confuse the issue: multi-threading *is* pre-emptive multitasking, just within the same process. Other than that, it seems to get things vaguely right, if for the wrong reasons and through over-simplifcation.

The linbury one points out many things that RISC OS users would rather ignore: That RISC OS is hopelessly ineffiecent. :)

 is a RISC OS Usernunfetishist on 30/07/03 3:00PM
[ Reply | Permalink | Report ]

> Acorn clearly wanted PMT on their earlier machines, but kept failing trying.

Ah, but in kernel land we have preemption and reentrency (just to prove it, even with a fully frozen desktop, network and disc drive still work). So Acorn manage to make kernel level things with PMT, but not user applications ? They manage to make RISC iX with PMt but not ROS ?

Perhaps after all...

> The multiple model of which you speak is a little pointless - that's > exactly what priorities are for under PMT systems. (Or even > dynamically adapting priorities, like Linux's)

Ah no, you cannot make a predictable system with PMT. At the best you'll make a soft or a hard RT system... That's not 100% predicatable. Why do you think Montavista tried to put different schedulers inside Linux kernel ? :)

 is a RISC OS Userdfeugey on 30/07/03 5:08PM
[ Reply | Permalink | Report ]

"Ah, but in kernel land we have preemption and reentrency (just to prove it, even with a fully frozen desktop, network and disc drive still work). So Acorn manage to make kernel level things with PMT, but not user applications ? They manage to make RISC iX with PMt but not ROS ?"

You're confusing modules (which work in the background, and are not PMTed as such - they're event driven CMTed) and processes. Much of RISC OS's kernel is not re-entrent at all. FileCore is one big irritating example, as are lots of other bits.

If, for example, you're in an OS_GBPB call to read in 2GB of data say, into one block (doesn't matter if this is actually possible or not, it's just an example.) pretty much the whole system stops until it's done. Under a pre-emptable, re-enterant kernel, other processes could still run happily, and use OS_GBPB themselves (perhaps even to read data from the same file.). It appears that you're confused on what kernel pre-emption is.

"Ah no, you cannot make a predictable system with PMT. At the best you'll make a soft or a hard RT system... That's not 100% predicatable. Why do you think Montavista tried to put different schedulers inside Linux kernel?"

Errr, I'm quite sure you're mad. Real Time operating systems are *all* about being predictable. If you think they're not predictable, that QNX installation at your local nuclear power plant, or WindRiver VxWorks in that cruise missile are in deep shit.

If what you mean is you can't predict what process is running at any given point, then that's true. It also doesn't matter. What predictability means in real-time scheduler terms is "when I wiggle this interrupt line into the CPU, this process will be swapped in within a certian number of microseconds to deal with it" *that's* predictability, and what is easily done with PMT, and a complete are to do with CMT.

Montavista specialise in embedding Linux. I certianly hope most people have learnt by now that Linux is utterly unsuitable for hard real time. But that's not the same as embedding.

 is a RISC OS Usernunfetishist on 30/07/03 8:30PM
[ Reply | Permalink | Report ]

> ARX (the OS that was meant to run on it, and had PMT) was woefully behind schedule. And was apparently slow.

> Then there was RISC iX. Acorn's UNIX, which had PMT Any was apparently slow.

 is a RISC OS Usermavhc on 31/07/03 08:31AM
[ Reply | Permalink | Report ]

I've never used ARX. But I can tell your RISC iX whipped RISC OS's arse on performance in every respect except GUI - and that was because it used X, and not because of PMT.

 is a RISC OS Usernunfetishist on 31/07/03 11:36AM
[ Reply | Permalink | Report ]

Perhas people should try think of it another way: would Windows NT (and derivatives) or Mac OS X have been as stable and secure without PMT?

 is a RISC OS UserDougal on 31/07/03 9:41PM
[ Reply | Permalink | Report ]

"Perhas people should try think of it another way: would Windows NT (and derivatives) or Mac OS X have been as stable and secure without PMT?"

This is not as much of an issue on RISC OS. For most users RISC OS appears very stable. This is probably due in part to us users weeding out apps that crash and take the system with it. It probably also due to programmers realising this and taking steps to make their apps more reliable. Either way, I can't remember my last crash on RISC OS. :-)

As for security, well, again this isn't a big issue for RISC OS users. You could argue that this is because security on RISC OS is pants, and you'd be right. RISC OS machines are rarely put in setuations where security is a concern exactly because of this.

If RISC OS was a player in the OS market then it would have to bite the bullet and add things such as PMT, better memory protection, real multi-user support, more security. But, it's not. tbh I'm still a little surprised that we got 32bit.

RISC OS - Love it for what it is

 is a RISC OS UserSpriteman on 01/08/03 10:54AM
[ Reply | Permalink | Report ]

Could Anyone tell me where i could get a copy of the Wimp2 Patch, as the link on the website doesn't exist?

Thanks Michael

 is a RISC OS Userem2ac on 01/08/03 2:38PM
[ Reply | Permalink | Report ]

I think that if RISC OS could choose between PMT and CMT when loading up applications, then it would on the whole make it a better operating system due to that fact.

 is a RISC OS Userem2ac on 01/08/03 2:40PM
[ Reply | Permalink | Report ]

Spriteman: 'either way, I can't remember my last crash on Risc OS' - ho hum...My VF/Kinetic crashes (i.e., requires a reboot) fairly regularly, so you're doing pretty well. Photodesk, RiScript and DialUp (posting news) are probably the most regular offenders with me. That said, the speed and ease of rebooting compensates to some degree.

If the Alt-Break procedure worked every time that would help too, but I find that some apps won't die but bring the system down with them. However, Windows NT wasn't bulletproof either: try putting a Mac format CD in an NT machine by mistake: the CD drive spins up and keeps running, the CD won't mount but you can't eject it - only way to get it back is to shut down....

 is a RISC OS Userbucksboy on 01/08/03 4:05PM
[ Reply | Permalink | Report ]

When I was still using RISC OS daily, my machine would crash at least once a day. More when I was developing software. Today, my Linux box boots faster than my RISC OS box ever did, thanks to fast hard discs and CPUs. Speed of booting's nolonger an argument. Yeah, sure, it boots damn quick without a boot scructure, but then the machine isn't actually all that useful.

 is a RISC OS Usernunfetishist on 01/08/03 5:18PM
[ Reply | Permalink | Report ]

Woudn't a combination be the best? CMT so applications don't use any more time than they need and PMT for applications that misbehave, ported applications and applications that work better with PMT.

A watchdog would already be a big improvement, if a aplication takes to long to return control to the OS the OS should just take it.

 is a RISC OS UserJaco on 01/08/03 6:30PM
[ Reply | Permalink | Report ]

Under PMT, no correctly written application uses more time than it needs, so that isn't a problem. (For example, under Unix, many applications use the "select" call to do nothing until something interesting happens - much like Wimp_Poll. The problem is what the program does *between* calls to select or Wimp_Poll).

Combinations of PMT and CMT rarely work: You have to stop PMTing the PMT processes when you swap in a CMT process. And if the CMT process blocks, you've lost the point of using PMT at all...

 is a RISC OS Usernunfetishist on 01/08/03 10:10PM
[ Reply | Permalink | Report ]

> Errr, I'm quite sure you're mad. Real Time operating systems are *all* > about being predictable. If you think they're not predictable, that QNX > installation at your local nuclear power plant, or WindRiver VxWorks > in that cruise missile are in deep s***.

Not in the way you think... Soft RT will try to execute the task in the given time "else" it will finish the execution later. Hard RT will try to execute the task in the given time "else" it will simply refuse to make it run.

Of course if you have a small (10 ms average execution time) task to execute in a quite long time (1 s), you don't need such predicatable features : with a simple PMT system (and only a few tasks running), your small task will ever be able to run in the given time.

But I really dont call this a fully predicatable system :) So perhaps I'm not mad... after all...

 is a RISC OS Userdfeugey on 02/08/03 10:04AM
[ Reply | Permalink | Report ]

'Not in the way you think... Soft RT will try to execute the task in the given time "else" it will finish the execution later. Hard RT will try to execute the task in the given time "else" it will simply refuse to make it run.'

No. You're exactly wrong. And I'll spend no futher time explaining things to you.

 is a RISC OS Usernunfetishist on 02/08/03 10:18AM
[ Reply | Permalink | Report ]

> When I was still using RISC OS daily, my machine would crash at least once a day. Should have probably fixed that then.

> More when I was developing software. That's the real problem.

> Today, my Linux box boots faster than my RISC OS box ever did, thanks to fast hard discs and CPUs. Race it against an Iyonix for a fair comparison.

> Speed of booting's no longer an argument. Yeah, sure, it boots damn quick without a boot scructure, but then the machine isn't actually all that useful It's 437.9 times more useful than every other OS without a booting harddisc. Shift boot, find !System, Scrap, drag a MDF to the monitor icon and you're done. Run the same configure program and use the same filer to fix the problem. Or just play a game.

 is a RISC OS Usermavhc on 02/08/03 10:57AM
[ Reply | Permalink | Report ]

"Should have probably fixed that then."

Yeah - the traditional way of doing it is to pop Linux on the box.

"Race it against an Iyonix for a fair comparison."

It boots in around 10 seconds, including starting NFS and Print servers, a commerical web server, X Windows, and loads of stuff extra. If I removed lots of stuff from it so it were functionally identical, such as cron, sshd and such, it'd prolly boot in 4 or 5, and most of that is the BIOS and X starting. Using another GUI system, like Fresco, would yeild another startup.

The Iyonix's boot time is only "quick" because it loads so little, because of the lack of modern features in the OS. (It'd boot even quicker if the OS did proper caching and buffering.)

"It's 437.9 times more useful than every other OS without a booting harddisc."

Not only have you made the number up, you've made the entire 'fact' up. I like that. :) (I have a Linux box downstairs with no hard disc, just ROM. It boots into X, has Mozilla, Dia, and Vim on it. [A browser, graphics tool, text editor] And the possibility of running other applications available on other UNIX boxes as if they were running locally.

mavhc in trolling and completely wrong unshocker!

 is a RISC OS Usernunfetishist on 02/08/03 11:22AM
[ Reply | Permalink | Report ]

s/startup/speedup/

 is a RISC OS Usernunfetishist on 02/08/03 11:31AM
[ Reply | Permalink | Report ]

When Replay3 used to work on my RISC PC, it used to impress friends that I could multi-task so much at one time. I had six movies running, !TechWriter and an Internet session on the go. Now if someone said to me which system would I prefer, PMT or CMT. I know which I would have chosen.

Although, I have to admit that there are other reasons why I prefer a RISC OS system.

 is a RISC OS UserMac9 on 02/08/03 12:11AM
[ Reply | Permalink | Report ]

To answer mr.Gulli regarding his remark on 27/7/03 6:23PM

The reason why MacOS and windows moved to PMT. Is quite simple. It's based on two things.

One is said in the article on top of the thread. CMT let's control from within the application while PMT let's control from whitin the OS (this is oversimplified, I know, but for a non-programmer this is understandable). So therefore PMT will undoubtly make the OS more complex. Also remember when the 1st Archimedes arrived. It had no proper OS and Acorn Ltd. had to speed things up. Obviously adding PMT would probably added considerable development time before launch of RISC OS 2 (which was the first full version of RISC OS AFIAK). I'm sure that many ppl where eagerly awaiting ROS 2 and really wanted to ditch Arthur. So I'm convinced that this is the prime reason why Acorn opted for CMT instead of PMT.

As for MAcOS X. DO NOT forget that Mac OS X is basicly a BSD-style Unix kernel with a MacOS UI on top of it. Unix is much older than RISC OS and is developped (or better suited) to mission critical environments while RISC OS is just a "consumer" OS.

As for Windows. Proper (decent) PMT didn't arrive until Windows NT. Basicly FAT-based windows environments use a DOS-based filing system with GUI bolted on. Even a MAC OS classic is better than that albeit also CMT (more or less).

I think that if you'd like something similar with a RISC OS feel then you better look at linux with the ROX-filer. This is an attempt at having a RISCOS-like UI on top of (a PMT) Linux. Though I'm not sure whether anyone has compiled ROX to a Linux variant on the RPC or other ARM machines. Maybe that is an interesting idea.....

ARM Linux, ROX and some emulator for "classic" apps. We might even call that combination "RISC OS X" :-)

 is a RISC OS Userepdm2be on 02/08/03 12:43AM
[ Reply | Permalink | Report ]

"Combinations of PMT and CMT rarely work" Why? All PMT does is starting the next process when the process runs out of it's slice time. CMT will do the same when the process does a OS call. If you combine them the PMT will be used only when the process doesn't return controll back to the OS before it runs out of time. So when a process is swaped in by CMT or PMT you start the timer and when the timer expires you do a PMT process swap.

What does select do? Most likely it will keep the process from being swapped in until there is a need but still uses any processor time left after the select call. (otherwise it would be CMT right?)

 is a RISC OS UserJaco on 02/08/03 2:18PM
[ Reply | Permalink | Report ]

Manu T:

RISC OS 2 was in fact the first full version of RISC OS

Yes, RISC OS was turned into a CMT because development time was getting out of hand with a PMT system, this was said by someone in the know quite a long time ago in some of the Acorn magazines, my memory totally betrays me on who it was and when. I do remember though that it was an interview and the author asked why RISC OS wasn't PMT. It's very likely that this was in an Acorn Computing/Micro User issue.

Thanks for the "history lesson" on the MacOS and Windows platforms - even though I already knew this (my original remark was "semi-sarcastic") there are probably some that gained from it.

I personally don't see ROX doing RISC OS justice, X-Windows is different from RO and will never be the same as true RO.

 is a RISC OS UserGulli on 02/08/03 4:09PM
[ Reply | Permalink | Report ]

> > "Should have probably fixed that then." > Yeah - the traditional way of doing it is to pop Linux on the box. Funny how most people don't have that problem.

> > "Race it against an Iyonix for a fair comparison." > It boots in around 10 seconds, including starting NFS and Print servers, a commerical web server, X Windows, and loads of stuff extra. If I removed lots of stuff from it so it were functionally identical, such as cron, sshd and such, it'd prolly boot in 4 or 5, and most of that is the BIOS and X starting. Using another GUI system, like Fresco, would yeild another startup.

> The Iyonix's boot time is only "quick" because it loads so little, because of the lack of modern features in the OS. (It'd boot even quicker if the OS did proper caching and buffering.)

It does the bios thing, the GUI thing, file sharing, filer, task manager, app launcher, editor, display manager, in about the same time.

> > "It's 437.9 times more useful than every other OS without a booting harddisc."

> Not only have you made the number up, you've made the entire 'fact' up. Well duh, obviously. > I like that. Good. > (I have a Linux box downstairs with no hard disc, just ROM. It boots into X, has Mozilla, Dia, and Vim on it. [A browser, graphics tool, text editor] And the possibility of running other applications available on other UNIX boxes as if they were running locally. Not without a network cable.

I have an A7000 with no hard disc, just ROM. It boots into a GUI and runs everything over the network, what's the big deal? Been doing that kind of thing for about 20 years.

> mavhc in trolling and completely wrong unshocker! Who's on the RISC OS site saying RISC OS sucks?

 is a RISC OS Usermavhc on 02/08/03 4:55PM
[ Reply | Permalink | Report ]

again does anyone know where i could get the patcher from?

 is a RISC OS Userem2ac on 05/08/03 2:33PM
[ Reply | Permalink | Report ]

[link] seems to works for me, as linked to from the wimp2 page

 is a RISC OS Usermavhc on 05/08/03 3:03PM
[ Reply | Permalink | Report ]

Bingo, Cheers i wanted to ry it but the links didnt work on the page!

Thanks again Michael

 is a RISC OS Userem2ac on 05/08/03 6:24PM
[ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Search the archives

Today's featured article

  • A9home: two years on
    We review the machine in its current state
     15 comments, latest by hzn on 7/1/08 10:50AM. Published: 4 Dec 2007

  • Random article

  • Software news
    APDL 32bit more, DOS games, updates and more
     18 comments, latest by imj on 11/3/04 10:50PM. Published: 8 Mar 2004

  • Useful links

    News and media:
    IconbarMyRISCOSArcSiteRISCOScodeANSC.S.A.AnnounceArchiveQercusRiscWorldDrag'n'DropGAG-News

    Top developers:
    RISCOS LtdRISC OS OpenMW SoftwareR-CompAdvantage SixVirtualAcorn

    Dealers:
    CJE MicrosAPDLCastlea4X-AmpleLiquid SiliconWebmonster

    Usergroups:
    WROCCRONENKACCIRUGSASAUGROUGOLRONWUGMUGWAUGGAGRISCOS.be

    Useful:
    RISCOS.org.ukRISCOS.orgRISCOS.infoFilebaseChris Why's Acorn/RISC OS collectionNetSurf

    Non-RISC OS:
    The RegisterThe InquirerApple InsiderBBC NewsSky NewsGoogle Newsxkcddiodesign


    © 1999-2009 The Drobe Team. Some rights reserved, click here for more information
    Powered by MiniDrobeCMS, based on J4U | Statistics
    "Drobe is just cheap British press"
    Page generated in 0.22 seconds.