RISC OS

Introduction

It's a bad idea.  No, really. This suggestion comes up every few months, and the protagonists always seem to ignore the facts, or what's been said the last 10 times this suggestion came up. So I'd like to debunk this idea, again, and hope we can wash our hands of this silly mess.

The Myth

Porting RISC OS to x86 would enable use of much faster and cheaper hardware, and be relatively easy to do and open up the market for RISC OS.

The Problem

None of the issues I'm about to mention are technically insurmountable; they represent a great deal of work - sometimes a very large amount.  The logical mistake that people who propose the idea is that they think if they have a solution to one of these issues then that's it, and the problem is solved.

Effort

Moving RISC OS itself to x86 would be an enourmous amount of work.  Much of RISC OS is written in ARM assembler that would need to be converted to x86 assembler or C. In the latter case, there could well be a relative performance loss. Much of the rest of RISC OS (in C and BASIC) makes a considerable number of assumptions about running on an ARM architecture, especially the SWI interface. Such problems can be overcome if you're Apple (now having essentially completed their second architecture switch) with millions of dollars and thousands of programmers, but this is magnitudes more resources than RISC OS development has.

Even after you've done it, there's a maintenance issue.  It's not like Linux where almost all of it is in C, and therefore easily looked after for multiple architectures.  It's likely that legacy ARM hardware versions of RISC OS would need to be maintained, and that means all that existing code in ARM assembler needs to be looked after alongside the x86 or C equivalent. Which means lots of extra time and effort.

The applications

After you've done all that, most of the applications would really benefit since they would have to run under emulation anyway (being binaries with ARM code, etc).  Certainly BASIC would benefit, but most applications which would really benefit from faster hardware aren't written in it. The applications that would really benefit under RISC OS on x86 are graphics intensive ones - ArtWorks, Photodesk, OvationPro, etc. The first two contain significant amounts of assembler, so faces the same problem as RISC OS itself if you want a native version.  The last already has a Windows version, so there's arguably no real benefit there.

Yes, many C programs could "just" be recompiled.  But the situation is unlike the 32-bit conversion - new binaries won't run on legacy hardware.  Although in principle you could have both ARM and x86 code in a binary - this would of course double the size of binaries.  Irrespective of how it's done, this means lots more work for a limited number of RISC OS developers.

Drivers

Hardware for x86 is notorious for changing every few months.  For example, the Iyonix video card has gone through at least 4 revisions and its driver has had to be modified each time.  For most of the rest of the hardware in an Iyonix, it's not such an issue since there is a relatively static design, and RISC OS will need few or no changes if another hardware run is done.  Plus the supporting the huge range of PC-style hardware would be impossible, so it would be tied to a specific setup, meaning a potential strike against cheaper hardware.

Cost

The cost involved in developing such a thing should now be obvious.  There is no way such a solution could be cheaper than existing RISC OS hardware solutions - the time and effort would mean it would be very expensive indeed.  And the motiviation for doing this at all by a company - ultimately making money from this investment - has no clear path.  There's no way to make money out of x86 RISC OS in the same way that existing RISC OS can be applied to low power consumption solutions outside the enthusiast market.

Time

This would take several years to do - by then things would have moved on considerably: faster ARM processors for example and emulation techniques, as well as stagnation of other RISC OS developments by sapping the efforts of its few developers.  Certainly it would divert effort from things RISC OS really needs - better application support - which is the real problem with RISC OS, and other OS level things - shared libraries, PMT, etc.  All things which could be done with much less effort, and with relative transparency to most programs and developers.

"But it could run on an interface layer and talk to Linux drivers, etc"

Great. But the problem here is that no-one who's made this suggestion has been able to come up with an idea about how it would work, much less a concrete example - mostly it's been unfortunate hand-waving. If you're going to persue this argument, then please try and think hard about the issue before making your proposal.

Other Solutions

Apart from all the problems I've named above (and I don't think I've been comprehensive), there isn't a great deal that you would gain over existing solutions - solutions that are already available and work, and are much less effort to extend.  In particular, VirtualRiscPC and RISC OS emulation solutions.

VirtualRiscPC

Despite the long list of grievances I have against VRPC, it's already a working solution, able to run on arbitrary x86 hardware by leaving the drivers and hardware support to Windows.  For those who find the idea of running on top of Windows abhorrent, a MacOS version is in the pipeline, and although a commerical Linux version may not be immediately on the cards, it's no real technical challenge.

It's certainly plausible that modifications could be made for example to the RISC OS Wimp to fully integrate RISC OS applications into the Windows (or whatever) desktop.  There are many areas in RISC OS this could be done.  The effort involved is well within the capacity of a single person to do.

QEMU

I'm referring to the work mainly done by Nick Burrett with additons by myself.  This allows basic command line RISC OS applications to run directly under Linux via emulation. It's unlikely that you could ever run a broad range of RISC OS programs with this, however specific applications could be targetted and persuaded to run as "first class citizens" alongside native Linux applicastions.  There are obvious solutions for implementing WIMP SWIs by mapping for example to GTK.  Most of the work is implementing SWIs correctly. In some cases this could be a lot of work, but certainly in the grasp of a handful of developers. 

Unlike a native x86 RISC OS, it can be done incrementally and be useful all along, whereas a full solution would not be useful until the vast majority of work was done.  Comments here also apply to a similar program, robe.

Conclusion

There's no clear benefit in having a native RISC OS on x86 over other options, including what we already have on ARM platforms.  It would be very expensive, and take a long time and the tangible benefits would be marginal.

I hope that's the end of this.  If you're going to persist with the view that it's a good idea, I ask you to think very carefully about what you're proposing.  This is one instance where half-baked ideas just won't do.