Modernising RISC OS in 2020: is there hope for the ancient ARM OS?

Post by asveikau » Sat, Oct 10, 2020, 2:37 PM UTC

lproven wrote: post #36

zozbot234 wrote: post #12

> 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…

[Author here] OK, I will give you that one. :-) But they are at least related concepts, no?

Post by asveikau » Sat, Oct 10, 2020, 2:47 PM UTC

ilaksh wrote: post #17

ithkuil wrote: post #8

Earlier quoted context omitted.

> 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…

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.

Post by icedchai » Sat, Oct 10, 2020, 3:39 PM UTC

mattbee wrote: post #29

adrianmsmith wrote: post #13

> 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 defini…

Post by qz2 » Sat, Oct 10, 2020, 5:45 PM UTC

lproven wrote: post #35

qz2 wrote: post #21

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…

Did you read the blog post? (I wrote it, BTW.) That is more or less what I was arguing for, you see.

Post by bobince » Sat, Oct 10, 2020, 8:13 PM UTC

robin_reala wrote: post #11

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.