RISC OS; Pros and Cons

[DavidS]

RISC OS has its pros and cons, there is no question about this.

I am going to attempt to hilight some of the pros and cons of RISC OS, in the interest of allowing people to figure out if they feel that RISC OS is a viable option for them. This post includes some things related to education as well as software development, as these are tha target audience of the RPi.

I feel that this is needed as there seem to be many unknowns, and questions in the forums that would be helped along by a quick view of the Pros and Cons of RISC OS. Also it may be helpful to software developers to have an idea what needs to be improved in RISC OS and programs for it on the RPi.

There will be 3 subsections to this post section 1 will cover general stuff about RISC OS, section 2 will lookat it from a more technical view, and section 3 will look at the current state of kinds of applications that may interest people.

NOTE: This list is just a quick overview and should not be considered exaustive in any way.

NOTE2: This list is made with out any direct comparison to other OSes.

*** SECTION 1 : General RISC OS Pros and Cons ***
Pros:

• *) RISC OS is quite fast.
  *) Almost Universal drag and drop for file save, file load, copy/cut/paste and much more.
  *) Very consistant User interface.
  *) Very easy to learn even for a new user.
  *) A structured BASIC inturpreter is standard in the OS.

Cons:

• *) USB support is still a bit buggy (Tempory Con).
  *) 802.11* support is not present at all, and looks like it will be a while before we get it.
  *) The screen driver on the RPi does not yet support HW acceleration.
  *) For uers that are accustomed to the odities of other OSes it can take a few minutes to get used to.

*** SECTION 2 : Technical Pros and Cons ***
Pros:

• *) The ability to Single task.
  *) RISC OS has a very clean implementation of the BSD Sockets library.
  *) RISC OS is very easy to extend by writing modules.
  *) Preemptive multitasking is possible for apps that are written for it, thanks to extension modules.
  *) The WIMP (RISC OSes GUI) is very easy to program for.
  *) The API is extremely simple, to the point that if a person so wished they could learn it in its entirety.
  *) On the RPi there are at least two modules available to simplify access to the GPIO pins, and PWM.

Cons:

• *) There is not yet any way to have system wide Preemptive Multitasking.
  *) There is not yet a good clean way to do multithreading. Though there are programmers working
  | on fixing this.
  *) The sound system can be a bit diffucult to work with, when programming.

*** SECTION 3 : Pros and Cons for Kinds of Software Available ***
Pros:

• *) There is a lot of educational software for children that is easy to use, even for a person that has
  | never touched a computer before.
  *) There are many available compilers including though not limitd to GCC, Pascal, and Charm.
  *) There are many interpreters inluding though not limited to BBC BASIC and LUA.
  *) There are two web browsers; FireFox 2, and Netsurf.
  *) There are a couple of good Video players available.
  *) There are many good DTP packages available.
  *) There is a reasonable selection of games, both the good old ones and many newer titles.

Cons:

• *) Web Browsers: FireFox is a very old version, and NetSurf still has a ways to go before it will
  | completely replace FireFox.

[DavidS]

If there is anything that you think is important to those that are new to RISC OS please add it.

[mahjongg]

IMHO there are only pro's in the sense that it offers an additional option that isn't like all the unix derivatives the PI already supports!
I like that:

• It isn't Linux (or BSD) or another Unix work alike for a change
• *Its an OS that turns my PI into something I long coveted, ever since I laid eye on an Acorn Archimedes but could not afford it
• Its much more transparent and simple than most other OS, its possible to understand all aspects of it
• Its not in the way when you do very timing critical things with it
• The nostalgia factor, and its links with BASIC and the BBC
• Its the canonical OS for an ARM microprocessor
• Its light and fast

[adlambert]

Pros
If an OS was designed today for the Pi it would be like RISC OS.

Cons
Support for printers is patchy, and other peripheral devices where a driver is required to fully utilise is even worse.

[AMcS]

Pro's would be:
Fast modular OS that (given it's links to the ARM) gives potentially the best performance on that platform.

The OS has a relatively small footprint, and many of the (full) applications are (in Windows or Linux terms) tiny. This means that (i). Load times - particularly over USB2 are faster than they would otherwise be and (ii). The smaller code has a better chance of fitting into the ARM's cache thus further improving performance.

Nice structured version of BASIC (BBC BASIC V) - written fully in ARM code, fits in the processor cache and gives impressive performance for an Interpreted language. It also doubles as a pretty effective ARM Assembler (you can even include BASIC functions *in* the assembly code - for example MOV R0,#ASC("A") // Would store the ASCII code for "A" (65) in Register 0...)

OS can be extended either by hooking into Software Vectors or supplying supplemental or replacement Relocatable Modules.

The OS source is now available (so this opens up possibilities for people wanting to contribute to the further development of the OS).

This OS has been here before. It comes to Pi with an assortment of programming languages, applications and a lot of information that already exists on the Interweb. For use in an education related sphere it is nigh on ideal....

And now the CONS:

Limited number of Active developers (although with a little luck/exposure on PI perhaps that will change).

The ARM platform is a "moving target", although ARM was the original processor for which RISC OS was based it has changed several times creating subtle (and sometimes not so subtle) issues. The biggest one to date being the switch from 26bit to 32bit Program Counter - the longer term introduction of ARM v8 (64 bit) and other changes may also create problems. Being written in assembler makes it fast BUT it also is difficult to shift if there are fundamental changes to the CPU it's written for.

Support for hardware developed after RISC OS peaked is still problematic (largely down to a shortage of information/developers).

Multithreading and support for Multiple processors (the latter not an issue for Pi as it's ARM is single core - but might be when RISC OS is ported to things like Exynios 5).

Probably the biggest issue isn't a technical one at all - and that is awareness. Many people never had a chance to use RISC OS and might "dismiss" it - or be unaware of it's benefits. I remember reading one magazine article (in the late 1980's) that reviewed the Archimedes a machine that was 15 times faster than the *average* PC and twice as fast as the fastest 386 of it's day (and at only half the price) and yet all the magazine basically said was "it's not PC compatible...".

Hopefully people are more open minded now and maybe - at long last - RISC OS can finally step out of the shadows....

[pygmy_giant]

Who cares - their loss.

[Burngate]

Who cares - their loss.

Ah but also ours. As with many things, the community is a big part of this

[NigelJK]

I cannot understand why people insist that the lack of threading is an issue. You have multi-tasking via co-operative and if you want to hog the machine just don't release the wimp_poll, it's just not 'the windows way' or 'the cuddly penguin way'

The Risc PC was a multi-processor design as were previous designs of Acorn machines and of course there was the Hydra board) so it should be possible to re-code the module that made it possible as both of these were standard podules.

[DavidS]

Personaly I agree with the phlosophy that we should stick with Cooperative multitasking. There are just so many that insist on Preemptive Multitasking and multithreading, so I work on my code to give them what they wish. Besides once I have something stable it will make me some money.


As to support of multiple cores, it would be easy enough to write a module that allows a task to add a another task on a seperate CPU/Core if available. Perhaps even as an extension to the existing WIMP module (thee is still one unused SWI in the WIMPs SWI pool).

[KeithSloan]

it's just not 'the windows way' or 'the cuddly penguin way'

That is the problem. If a windows or Linux application uses threads you cannot just recompile it to run cooperative multi tasking. The implementation has to be totally different.

Plus it only takes one bad application to upset the cart.

Most modern processors are multicore. To fully exploit multicore you need multitasking i.e. (The system plus user processes)

There are a number of people who are cooperative multi tasking apologists, but for me its the Achilles heal of RISC OS and one of the reasons its never going to go anywhere.

Just look at the number of appends to RISC OS forum compared to Raspbian its about a tenth.

[rurwin]

I cannot understand why people insist that the lack of threading is an issue. You have multi-tasking via co-operative and if you want to hog the machine just don't release the wimp_poll, it's just not 'the windows way' or 'the cuddly penguin way'

It is the Windows way. It was the Windows way all the way up to version 3.11, IIRC, maybe 98SE.

Cooperative multi-tasking can get a lot more done in the same time. Manchester University had 16-user timesharing on a PDP11/23 (1MHz instruction cycle) with 64k RAM. But preoption allows you to run multiple programs and not be dependant on how well-behaved they all are. You can have a real-time process running, and it doesn't stop running when the user moves a window or runs a processor-hogging app. Cooperation is more efficient, simpler to code and simpler to code for, but it works best with a dedicated application or a well-controlled application suite. It does not scale well into multiple users or a mixed application suite where applications may have different optimisation aims or be written by incompetent authors.

[DavidS]

Cooperative vs Preemptive. I think that this needs to be looked at with out the negitive view of portin between the two.

Cooperative Multitasking.

• *How many usefull aplications can go very long wit out making a system call?
  * Now what happens if you add a moule to RISC OS that performs a Wimp_Poll on behalf of the current task afer each system call that it is safe to so do. This is how some cooperative multitasking systems already work (o though not RISC OS).
  * How do you insure that one task does not bring down the system (there are many posible answeres to this one).

Preemptive Multitasking.

• * One word: heinsenbug. The kind tha arises as a result of preemptive multithreading. You know aquiring a circular series of mutex that lock out, or simular.
  * Memory management, and we wonder why modern memory managers are way out of reasonable?
  * Quallity of Service, Good luck in a preemptive OS.
  * Hard real time, I think not. There is a good reason that many Hard Real Time systems are cooperative multitasking.

[DavidS]

it's just not 'the windows way' or 'the cuddly penguin way'

That is the problem. If a windows or Linux application uses threads you cannot just recompile it to run cooperative multi tasking. The implementation has to be totally different.

Plus it only takes one bad application to upset the cart.

Most modern processors are multicore. To fully exploit multicore you need multitasking i.e. (The system plus user processes)

It is definitely possible to do a very good job of handling multiple processors on a cooperative multitaskig system.

This is an area that I have been studying for some time, do to the idea of the "Many Core" CPU. There have been attempts to do it many different ways, and the ways that seem to work the best require a coopeative multitasking system. The system that I play on for this is a 64 CPU ARMv5 80MIPS per CPU qube layout (4*4*4 grid) archetucture with direct communication bewen each CPU and its 6 neighbors (wrapping around the edges [left around to right, top aoun to bottom etc]), left, right, beore, after, above, bellow. And the OS that I have had the most success with, thus far, is a cooperative multitasking system modeled largely after RISC OS. It does have the limit of having only 64 parallel tasks, though so would a preemptive system. Using cooperative multitasking gives the needed level of control to get something donein multiprcessing.

There are a number of people who are cooperative multi tasking apologists, but for me its the Achilles heal of RISC OS and one of the reasons its never going to go anywhere.

Just look at the number of appends to RISC OS forum compared to Raspbian its about a tenth.

I am no apologist, cooperative multitasking is he future of computingthanks to the multiprocessing paridigm of the future. The next step being researched by most of the big boys is what they call "Many Core Archetechure", this is to say more than 32 Processor Cores per device.

[rurwin]

Preemptive Multitasking.

• * One word: heinsenbug. The kind tha arises as a result of preemptive multithreading. You know aquiring a circular series of mutex that lock out, or simular.
  * Memory management, and we wonder why modern memory managers are way out of reasonable?
  * Quallity of Service, Good luck in a preemptive OS.
  * Hard real time, I think not. There is a good reason that many Hard Real Time systems are cooperative multitasking.

Mutex deadlocks are a feature of all OS's, even RiscOS. Memory management has nothing to do with the scheduling model. Windows moved away from a shared memory model for a good reason: too many applications and drivers were stamping on other applications' data. Quality of Service -- good luck in a cooperative OS. Only the very hardest of hard-real-time OSs use cooperative multi-tasking, and for those jobs even RiscOS is not suitable unless you strip it down to the bare bones.

[KeithSloan]

if you add a module to RISC OS that performs a Wimp_Poll on behalf of the current task after each system call that it is safe to so do.

Not sure about the latest version of RISC OS, but I remember writing a test program that I ran on an Archimedes 410 way back that basically just did wimp_polls. The result was very unimpressive i.e. the cost of context switching on RISC OS was very high.

Also a problem you will hit with your new version of Wimp2, is that of re-entrancy. Applications can do what they like between system calls. If an application does change things between system calls then these are the applications that break Wimp2.

I think RISC OS would have a problem with running on a multiprocessor because although applications are cooperative the system is not and certainly used not to be re-entrant ( but that might have changed )

[nr.]

Errr, aren't we forgetting somewhat that this is RISC OS on the Pi, and as such, multi-processor support probably isn't too much of an issue

[DavidS]

I think RISC OS would have a problem with running on a multiprocessor because although applications are cooperative the system is not and certainly used not to be re-entrant ( but that might have changed )

Yes it is true that most of the OS is not reentrant. beleive it or not it does not have to be for multiprocessing. The system components on all but one CPU are just thin wrapers (ok there is a small bit of local functionality) and they pass on system calls to another set of wrappers on the main CPU, that then makes sure not to inturupt a non reentrant system call. Of cource there will always be programs that just will not work with premptive multitasking, these are the reason that my multitasker will give the option to drop outside of the preemptive envirement for those applications that will always break in a preemptive enviroment.

I still prefer cooperative multitasking.

Errr, aren't we forgetting somewhat that this is RISC OS on the Pi, and as such, multi-processor support probably isn't too much of an issue

yes this forum is on the RPi site. and there is only one ARM on the RPi . Though I have thought about creating a rig to wire together a few RPi's and do multiprocesing on them under RISC OS .

[KeithSloan]

The system components on all but one CPU are just thin wrapers (ok there is a small bit of local functionality) and they pass on system calls to another set of wrappers on the main CPU

But then you are just creating a bottleneck of one CPU. Your not going to get a lot of parallelism.

But as said not relevant to Pi. But maybe a future Pi will be multicore in which case Linux will have a big advantage,

[KeithSloan]

Another problem of the way RISC OS does cooperative multitasking is with I/O.
When RISC OS renders some text in a window, it goes to the Font system which may have to do I/O to disk. It does not allow another process to run whilst it is doing that I/O. Where as in Linux when a process does some I/O and is waiting for the interrupt back from the disk, another process can run.

Lets say an average I/O takes 10ms then around 100 I/O per second is your maximum. Okay even if its 5ms is still only 200 I/O per second. Your not going to be able to run heavy MySQL applications in such an environment.

For a desktop system this may not be a problem and that is the sort of system RISC OS was intended for. But you are not going to see server farms running RISC OS.

[pygmy_giant]

If RISC OS goes pre-emptive I will stop using it.

Being co-operative is its usp.

I don't want my Pi to run more than one application at a time.

I want it to focus - its only got a diddy cpu.

[KeithSloan]

Deleted

[KeithSloan]

If RISC OS goes pre-emptive I will stop using it.

I would not worry, personally I don't think is will ever happen.

But bare in mind that a browser probably would like to use more than one thread, even if its only one application to you.

[jojopi]

Errr, aren't we forgetting somewhat that this is RISC OS on the Pi, and as such, multi-processor support probably isn't too much of an issue

Nevertheless, this is perhaps RISC OS' biggest weakness. The Pi is one of the last general-purpose computers not to be multi-core. How can RISC OS survive into a future where ARM is heavily multi-core, Thumb2-only, or 64-bit?

[DavidS]

The system components on all but one CPU are just thin wrapers (ok there is a small bit of local functionality) and they pass on system calls to another set of wrappers on the main CPU

But then you are just creating a bottleneck of one CPU. Your not going to get a lot of parallelism.

Depends on what you are doing. If you are spending most of your time in the OS then yes it would limit the parallelism, if you are actualy doing something intensive (which is where Parallelism pays for it self any way) then you will see much more benifit than you do from any preemptive multitasking OS. Do remember there is not a good way to get around IO botlenecks for multiple tasks that do a lot of IO as they will likely have to share resources on a single processor that controlls the IO device. Especialy on a workstation, you usualy would not want to have a seperate display, kb, etc for each of poentially hundreds of tasks. For my testing I run between 128 and 1024 tasks on 64 CPUs.

But as said not relevant to Pi. But maybe a future Pi will be multicore in which case Linux will have a big advantage,

LOL have you ever attempted Linux to cooperate on more thatn 8 CPUs on a single system now there is a bottleneck.


Though I can see a future in which the RPi takes advantage of the simplicity of the ARM core and runs on a 32 to 128 core "Many Core" device that is cheaper (both in transistor count and price) than using a traditional SoC though provides much more procesing power than what we currently have.

Another problem of the way RISC OS does cooperative multitasking is with I/O.
When RISC OS renders some text in a window, it goes to the Font system which may have to do I/O to disk. It does not allow another process to run whilst it is doing that I/O. Where as in Linux when a process does some I/O and is waiting for the interrupt back from the disk, another process can run.

Lets say an average I/O takes 10ms then around 10 I/O per second is your maximum. Okay even if its 5ms is still only 20 I/O per second. Your not going to be able to run heavy MySQL applications in such an environment.

Four things to say to this:

• 1: Most tasks on RISC OS do not require that much DISK IO.
  2: I have been using a diskspeed module that I wrote since 1998. This module use some fancy footwork to allow disk access to proceed while another task gets time unles all tasks are waiting for a disk operation.
  3: Database stuff should learn to cache stuff in RAM, MySQL has always ben a terible example.
  4: for rendering to windows this is an advantage, it allows the system to be responcive. Have you ever had a heavy load on a Linux system with X and wondered why it took more than 1 second to draw all of the pixals of a single charactor, because the font manager whas not getting enough CPU time?

For a desktop system this may not be a problem and that is the sort of system RISC OS was intended for. But you are not going to see server farms running RISC OS.

Who cares. If you want a server farm use MiNIX, or simular. You will still only have less than 8 CPUs per system so it will serve you well.

[rurwin]

CPUs these days are hitting a clock-speed limit. I expect processor cores to multiply by two every eighteen months from now on. My work laptop already admits to having 8 cores (half of them virtual), the next will probably admit to 32. By 2020 or thereabouts, the average desktop computer will have the 64 cores that your experimental beast has. To use those cores effectively will require some significant changes in how we write applications, and how we write operating systems. Having the OS running on a single core will be a distinct disadvantage.

The RaspPi of course is already heavily multi-core; it's just that we can't see most of them.