RISCOS-x86?

Any chances of porting RISCOS to non-arm platforms? I really like philosophy behind this OS and would want to use it as my main OS. Unfortunately, getting ARM-based PC that isn’t underpowered POS like Pi is as you can imagine kinda hard. Any chances of porting RISCOS to x86 platform?

No, for two reasons:
1/ the license does not permit it
2/ too much ARM code in RISC OS

But there will be another solution: next gen 64bit ARM processors. Of course, RISC OS will not be adapted to these offer in one day, but it’ll be probably possible to use it under virtualisation.

Nota: the Pi is underpowered for Linux, not for RISC OS :)

Virtually no chance of RISC OS getting ported to a non-ARM platform, AFAIK; but if you want to use it on x86 there are several excellent emulators available. RPCEmu [http://www.marutan.net/rpcemu/] is free and works well, though network configuration is somewhat complex, and you can run all the major OS flavours (4.xx, 5.20 and 6.xx); Wintel is better supported than Mactel. VirtualAcorn [http://www.virtualacorn.co.uk/index2.htm] is a more polished commercial product, but you don’t have the option of running RO 5.20. On fast hardware either will compete with all but the fastest native hardware [see here https://www.riscosopen.org/forum/forums/5/topics/466
], plus you have access to javascript-capable and Flash-capable browsers, which RISC OS does not have at present.

You can already run RISCOS on x86 platform using one of the Emulators. (VRPC is very good).

The OS was designed by the same team which developed the ARM processor. They were made for each other. It is not at all suitable for any other processor.

The Pi and VRPC are actually very usable ways to run RISCOS.

Sorry folks, I took too long with my answer

I meant main OS as in booting right into it. Well, too bad. I guess I’ll have to settle for Haiku which has quite similar GUI philosophy, though would prefer RISCOS ui (pinboard, etc.) on my desktop.

Also isn’t RISCOS Open GPL’d?

No. To quote from the Home page of the ROOL site [https://www.riscosopen.org/content/]: “RISC OS is owned by Castle Technology Ltd.”

I guess I’ll have to settle for Haiku which has quite similar GUI philosophy, though would prefer RISCOS ui (pinboard, etc.) on my desktop.

That was the reasoning behind the work people did on ROX http://rox.sourceforge.net/desktop/

Also isn’t RISCOS Open GPL’d?

No, and not likely to be either. Virtually any other license model would please people more.

Remember Open Source does not require GPL

Any chances of porting RISCOS to non-arm platforms?

Just in case it hasn’t been made clear, RISC OS isn’t a case of simply “recompile the source for a new target”. The core is written in assembler. The filesystems are (mostly) written in assembler. The Desktop/Wimp is written in assembler. To give you an idea, I made an OvationPro (desktop publisher) document of the Wimp source code to print out and read through, make notes in. The text is 6 point, which is about the smallest it can be and still pass a printer without becoming a blurry smear. I never did print it, even at that size, it is 468 pages worth.
And that’s just the Wimp code.

It is, as a result of this, very tied to the hardware. The ARM has sixteen visible registers (R0 to R15). Some have defined purposes (R15 is the program counter, R14 is the return address in a subroutine. Some have conventional purposes (R13 is almost always a stack pointer). You can directly pass R0-R7 (eight 32 bit registers) to SWI calls (software interrupts) from most decent languages. [SWI is a bit like an x86 INT]
RISC OS might be able to be ported to an architecture that is similar to the ARM in this respect. Trying to implement RISC OS on x86 would be inviting a world of pain. You only have eight 32 bit registers in the basic x86 (IA-32) model. The first four claim to be general purpose, but the A, B, C, and D names actually mean things – Accumulator, Base, Counter, Data. The CISC nature of the x86 places constraints upon how registers are used. Especially if you want really compact and fast code that assumes that (E)AX is the output of mathematical operations; or looping instructions that assumes (E)CX holds the count.
This is not the case (usually) with the ARM, where an instruction like ADD Ra, Rb, Rc will perform Ra = Rb + Rc and the registers a,b,c can be any. Even the Program Counter! There is no “preferred” or “fast” implementation that treats one register as being more special than the others. This goes against the design principles behind the ARM.
The other four x86 registers are EBP, ESI, EDI, and ESP. Pointers and indexes, and hangovers from the days of segmented memory models. Oh, and EIP – the program counter.

So, then, you would need to try to work out how to get RISC OS which runs nicely on a processor with lots of registers (and an API that can often pass five or six values to one SWI) to work on an architecture with four registers that you can expect to make use of. Frankly, I’d rather be forced to listen to everything Justin Bloody Bieber has ever recorded, twice, than to even think about how much that would hurt. It’s much easier to run RISC OS on an emulator and let some clever code deal with the in-betweens.

This is why RISC OS is lean and fast. It is extremely specific to the hardware in question.

Unfortunately, getting ARM-based PC that isn’t underpowered POS like Pi is as you can imagine kinda hard.

Well, I have two observations here.

Firstly, the Pi isn’t the only ARM board out there. There is an OMAP4 build for the Pandaboard. It goes faster.

Secondly, don’t be deceived. Linux probably runs like crap because it is a memory hog and you aren’t going to get good results from a 256MiB board, and I would hope that the swap partition is disabled so you won’t trash the SD card in short order. Well, that makes things slower too.
Comparing RISC OS perceived performance with Linux on a Pi is a bit like saying “RISC OS must be rubbish because Windows 95 was horrible”. Huh? The two are not even remotely alike. Even on identical hardware, the two aren’t even remotely alike.

Also isn’t RISCOS Open GPL’d?

As Steve said, GPL is not a synonym of Open Source. There are alternatives. Some are even better than GPL. ;-)

Frankly, I’d rather be forced to listen to everything Justin Bloody Bieber has ever recorded

I’m sure that’s forbidden under the Geneva Convention.
Twice? Off the scale.

Some are even better than GPL. ;-)

Some?

Some are even better than GPL. ;-)
Some?

I was being polite.
It depends upon ones mindset. There are people who “believe” in releasing their source to the world, but only under a strict set of terms. To them, the GPL is great. The BSD licence, less so. Because people can do all sorts of nasty things to their code if it was BSD, like embed it into something and NOT share it further.
I guess it depends if a person thinks of sharing source as altruistic (take it, enjoy it), or evangelical (take it, here are all the ¹ terms and conditions that apply).
There’s a lot of middle ground, too, for licences that encourage sharing alike, without the GPL sledgehammer approach: EUPL, CDDL, Apache, the list is too long for me to remember…

¹ In the case of GPL, insert “vague, ill-defined, to be sorted out by expensive lawyers at some random future date” at this point.

There are people who “believe” in releasing their source to the world, but only under a strict set of terms. To them, the GPL is great. The BSD licence, less so. Because people can do all sorts of nasty things to their code if it was BSD, like embed it into something and NOT share it further.

BSD. Person A makes code available, person B adds and extends but does not share the additional source.
So? The original source is still there.

GPL. Person A makes code available, person B adds and extends but does not share the additional source. Unfortunately various as….s claim anything it is connected to is also GPL.
We know we’ve been there.

I guess it depends if a person thinks of sharing source as altruistic (take it, enjoy it), or evangelical (take it, here are all the 1 terms and conditions that apply).

Apart from turning up down the road on a regular basis and the NHS reciprocating by helping pay my mortgage I’ve never set conditions on what I do (although plagiarism will wind me up massively)

There’s a lot of middle ground, too, for licences that encourage sharing alike, without the GPL sledgehammer approach: EUPL, CDDL, Apache, the list is too long for me to remember…

Indeed. So many to choose from, why do so many choose the worst?

To make a point of the ARM hardware being underpowered…
Try running raspian on a Pi, then run RISC OS.
The Pi is pretty slow, but it runs RISC OS pretty fast – well very very fast.
As regards the Pandaboard ES, (which I have as well as a couple of pi) my newsuk application loads the bbc news rss feeds and translates the image all in around 5 seconds, whilst multitasking.
I have worked out how to get this done in under a second, it is possible (but cheating slightly) and I’m working on it.
I’d say the current commercial ARM offerings are underpowered, for linux/windows/android [GPU not being included]
It all depends on what you want to do, I wouldn’t run a database cluster on an ARM system at the moment.
But for my primary desktop my Pandaboard decimates my quad core i7 intel 3.5GHz,SSD,12GB ram for both responsiveness and speed – you may want to think how that is possible.
There is also the i.MX6 coming soon from RComp which i.AM waiting for ;-)

Isn’t someone also porting RISC OS 5 to OMAP5?

If it is so desirable to have a regular x86 PC to ‘boot into’ RISC OS, then this can be achieved with a minimal Linux distro and RPCEmu (with the right boot scripts etc.).

To make a point of the ARM hardware being underpowered…

Not really clear cut.
You can equally use the same performance difference of a linux build and RISC OS on a Pi to demonstrate that Linux is inefficient and dare we suggest: bloated?

Yes, clock speeds etc on the ARM board we are using is slow relative to x86 and I really do wonder what we could do with full spec ARM board – i.e. fast disc systems, fast bus, and clock speeds around the PC = 2-3GHz.
Bit of threading on multicore boards on top of that and the performance would probably leave you out of breath.

On the other hand – one might suggest that the x86 world is pretty much a battering ram to crack a nut.

Personally, I would be quite interested to see how an x86-64 system compares with an x86-32 system of the same clock speed and memory, FSB, etc.
The x86 architecture is, dare I say, appalling. It was probably okay in the late ‘70s but in 201x it is…well… one could be less than charitable and say that insane clock speeds and such are necessary to get reasonable response out of the machine (according to user expectations). Now thanks to Android, big bloaty operating systems run on mobile phones and this will influence the ARM architecture’s own race for the most cores and the most GHz and so on. However, one cannot directly compare systems based upon processor clock speed alone. This was true in 1987 and it’s just as true today…