back
53 comments
I did the fun part of a RISC OS emulator 20 years ago - http://riscose.sourceforge.net/ - i.e. WINE but for RISC OS applications.

It got as far as being able to run the RISC OS C compiler, compile and run its own output for a few command line applications.

But then we got to the stage of needing a test suite. Then my friend & collaborator on the project (Chris Rutter) died at the age of 19, then I finished college, had to find work and lost most of my RISC OS connections & nostalgia.

There was definitely a rich seam of RISC OS software in 2000 that Linux desktop could have used - great text editors and word processors and Sibelius. But Linux got most of that pretty fast.

Also I don't think RISC OS would have escaped the trap of most desktop OSes - that a desktop OS with native applications became a niche, expensive taste. By 2010 most desktop computer users were looking for a host for a web browser, and RISC OS itself is still spectaularly unsuited to that - hostile code, multithreading, support for proprietary blobs (at least in 2000) etc. etc.

That doesn't stop me missing it though!

RISC OS is written mostly in ARM assembly, but it's a pretty complete (if dated) OS. I think it would be interesting to convert the sources to LLVM-IR and then abstract the hardware specific parts giving you a cross platform version of RISC-OS. Yeah, it'd be a lot of work ... but I think it'd be very cool.

Why?

25 years ago there were dozens of OS's: AIX, Ultrix/OSF-1/Tru64, HP/UX, DG/UX, SCO (yuck), MS-DOS, Dynix/PTX, Solaris/SunOS, Windows, MSDOS, Mac, VMS, RISC-OS, Amiga, BeOS etc. etc. Now we're down to a handful of OSs with a large amount of computing now converging on Intel/Linux -- FWIW, I have nothing against Linux, I've used it since the early Slackware / pre 1.0 kernel days.

But I do believe competition is a good thing and the current trend for OS (and processor) convergence is worrying to me. I'd like to see more innovation and diversity in this space.

Listing some I know of: linux windows macos freebsd redox fuchsia ios android(sharing the kernel but sufficiently different from linux) chromeos plus many more experimental but available os
There's also freedos, haiku, and reactos.
• linux <- an xNix (DEC PDP-7/PDP-11 OS) • windows <- modernised VMS (DEC VAX OS, the 32-bit PDP-11) • macos <- xNix • freebsd <- xNix • redox <- experimental, unfinished, no apps, xNix-like • fuchsia <- xNix in Go • ios <- basically macOS, an xNix • android <- a weird Linux • chromeos <- Linux

That's 2 so far. 2.5 if I'm being generous.

Do keep going, would you?

That's 2 families, not 2 operating systems. If you can tell me with a straight face that Debian, FreeBSD, and iOS are the same thing, then we're really not having the same conversation.
There's a myriad of interesting OSes which run a Linux kernel. Containers, for one (such as Docker). Qubes, for another. Third, Tails. Fourth, NixOS. And so on, and so forth. These 4 examples might each run a Linux kernel, but they each have very different design goals and aims.

I'm much more concerned about the lack of diversity in hardware space... specifically, the lack of open hardware.

Seven of the GP are unices also. They're not the same OS however.
Chrome OS is Linux too.
ChromeOS uses Linux kernel, userspace has nothing to do with Linux.

Even Crostini and ARC++ execute inside their own VM alongside their own kernel flavour.

With Google turning the Web into ChromeOS, it matters even less, given how many OSes Chrome runs on.

Harvey OS

Redox OS

Both xNix-like.

Harvey is Plan 9, which is Unix 2.0.

Redox is xNix redone in Rust, I think because they've never seen anything that isn't xNix.

> No memory protection or hardware-assisted memory management

This isn’t true. There are many modern features missing from RISC OS but memory protection isn’t one of them.

Each process sees its memory at the same logical address, it doesn’t have any way of accessing other process’ memory.

The process’ memory starts at the address 0x8000. http://www.riscos.com/support/developers/riscos6/memory/logi...

From - err - memory, the OS used some of the memory protection in hardware, but it didn't use it with security in mind.

I'm pretty sure an application could rewrite important kernel tables below &8000. And if you were using any shared libraries, these were all implemented as kernel modules, with no guard rails.

So it was kinda safe against some accidental access errors, but not at all a secure environment, and definitely possible to blow up the whole machine.

Still better than the Amiga, where their was no memory protection at all. Basically the entire OS was built on sharing memory between processes through message passing...
> It's too late for virtual memory, and we don't really need it any more -- but the programming methods that allow virtual memory, letting programs spill over onto disk if the OS runs low on memory, are the same as those that enforce the protection of each program's RAM from all other programs.

Strictly speaking, I don't think this is true - virtual memory and process-based memory protection are separate issues. One could have a single-address-space OS where physical memory is identically mapped in each process' address space, while still preserving memory protection. A privileged process in such an OS might effectively be exempt from memory protection altogether, which would provide compatibility for legacy apps.

That's the difference between an MMU and MPU.

The first (MMU) adds virtual memory to the story, while the second (MPU) simply protects certain areas of memory.

https://www.geeksforgeeks.org/whats-difference-between-mmu-a...

[Author here]

OK, I will give you that one. :-)

But they are at least related concepts, no?

It was weird to me that you said nobody needs virtual memory.

On Unix, any time you mmap() or fork(). And loading code from disk looks very similar to the former.

It's an implementation detail of one type of OS.

I am interested in the bigger picture.

See my FOSDEM talk for more: https://liam-on-linux.livejournal.com/69099.html

Paul Fellows, mentioned by reference in the article as giving the talk on writing RISCOS, presented again at Virtual ABug earlier in the Summer. The talk is online here: http://abug.org.uk/index.php/2020/07/04/paul-fellows/
"A software emulation of 32-bit ARM would be needed, with perhaps a 10x performance drop."

Well, my Archimedes was 8Mhz, and my Pi is 1500Mhz, so we have some room there perhaps?

Don't forger the fact 187.5 times the frequency is not the only improvement. Today you also have 4x the cores, 8x the bits and hardware 4Kp60 HEVC en/de-coding. There probably are more things (like AES encryption, linear algebra and FPU) hardware-accelerated, I don't really know. This way your emulated Archimedes can probably do much much more than it was supposed to.
Gameboy advance emulators emulate 32bit arm, plenty of those around.
Which is fine, but the things we do with our home computers today are not the same things we did in the late 80s.
Maybe so, but I'd imagine most of the legacy 32-bit apps you'd be running in emulation here on your 64-bit RISC OS system are from the late 80s (or maybe the early-to-mid-90s), doing those late 80s things.
Plenty of them actually are.

A rusty Amiga 2000, with Internet connection could handle like 80% of the stuff I use my 2009 laptop for.

If the things we do with with our home computers are crunching in kernel space instead of in userland, someone's done something wrong.
The article's talking about running 32-bit applications in emulation, with a 64-bit native kernel.

> Then a rewrite of RISC OS for 64-bit ARM chips would require a 32-bit emulation layer for old apps to run -- and very slowly at that, when ARM chips no longer execute 32-bit code directly. A software emulation of 32-bit ARM would be needed, with perhaps a 10x performance drop.

I saw some YouTube videos of RISC OS running on Pi.
[Author here]

I have RISC OS running on a Pi, and it's not the first one I've had, either.

https://twitter.com/lproven/status/1310304554395860996

http://blog.tynemouthsoftware.co.uk/2015/12/day-8-zx-spectru...

I don't just make this stuff up, you know. :-)

I still have my A305, too, and an A5000 as well.

Thanks to Castle's mysterious one big customer it has survived into its fourth decade.

I’d previously missed this piece of lore. Anyone got any more info on it? I’m trying to picture what critical system built on RISC OS would have required ongoing maintenance and am coming up blank.

Got to wonder whether it’s something like ncipher/Thales due to the van someren/aleph1 connection.
Don't know, but there was a mysterious entity that nearly bought the rump of Acorn IIRC to keep producing RiscPCs. Due to some fumble the deal fell through. I vaguely remember it being some kind of media-tech company. Probably the same mysterious entity.
I'm guessing Eidos's Optima video editing system? That was the last of the major RISC OS users as I remember it.
RISC OS is quite frankly dead in its current incarnation. And I say that as a somewhat prolific Acorn customer in the 80s and 90s. It was after all a quick hack because they weren’t going to deliver ARX. Some of the impedance mismatches between the OS and everything else in the universe are glaringly irritating today such as paths and file type metadata.

But a lot of the better ideas from the operating system should be carried forwards into something else. I’m not talking about sticking something on top of Linux but something completely different. Perhaps a resurrection of ARX and the UI concepts from RISC OS would be interesting.

Did you read the blog post? (I wrote it, BTW.)

That is more or less what I was arguing for, you see.

I wrote that then read the post if I’m honest. I wanted to compare notes :)
I see RISC OS has having one particular advantage: cooperative multitasking. You can basically turn it into a gigantic MCU with proper interrupts and timing.

It doesn't seem like it's a niche others are interested in, though.

Get a git client and GCC working with it and you have a pretty nifty real-time development platform.

Whenever I see RISC OS I always assume it's something for RISC V.

I know this is not about that actually, just makes me think about it.

But obviously it's for original RISC i.e. ARM. But anyway I still wonder if something like RISC OS could work on RISC V.

I saw a youtube demo of someone running RISC OS on Raspberry Pi and it was very snappy. Something older like that has had less time to acquire features (that can slow it down or just be bloat).

Besides eliminating bloat, I feel like RISC V is an opportunity to start with some new assumptions. So I am interested to hear how operating systems and software evolve for it. Linux is great but I believe that there is always room for a fresh approach after a few decades.

So I wonder if things like Fuchsia or MirageOS or new Rust things etc. will be targeted to RISC V.

> But obviously it's for original RISC i.e. ARM.

Not sure if you actually mean that, but to me it sounds like you're implying that ARM is the "original RISC".

The first RISC processor was called RISC-I and came out of Berkeley research in 1981.

Around the same time came out the MIPS cpu, from Standford university, by a group who shortly after founded a company that by 1985 commercialized the first RISC CPU, the R2000.

ARM, SPARC and PA-RISC came out just about the same time.

The ideas were brewing for some time, but I think it's safe to say historically that the name "RISC" was not invented by ARM and that the R in ARM references a pre-existing term that has been developed at Berkeley.

It really was the original RISC in a personal computer; you could actually buy one (especially in the UK); and run it at home; the others were things that lived in computer rooms and drove green screen terminals.
The original RISC was the IBM 801, in ~1975, or arguably even the CDC 6600 in 1965. It is hard to identify anything that originated in the RISC-1.
Didn't register windows originate at Berkeley?

Sure, the IBM 801, the CDC 6600 and others were forerunners, but it was the Berkeley research project that popularized the acronym IIRC.

Okay so it was just the most popular RISC and not the original one.

So good job on that correction but it doesn't seem necessary to downvote me. I thought I had some interesting comments about the future of operating systems on RISC.

Most popular hasn't always been accurate either. If you asked in the 90s there'd be alpha, ppc, sparc. There was a time when I would have put all of those as more relevant than ARM.
What is the point of this discussion for others not in the ecology?
[Author here]

"Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it."

-- George Santayana (The Life of Reason: The Phases of Human Progress)