There’s no reason you couldn’t retrofit preemptive multitasking and memory protection to RiscOS. Legacy apps wouldn’t be aware of the fact that they were preempted and you’d still allow them to cooperatively schedule threads within the apps. Each app would see its own 26-bit virtual address space if you added memory protection. I thought Acorn added both of those features around RiscOS 3 but apparently I misremembered. I’m pretty sure it did move to a 32-bit address space because I remember the 26->32-bit transition breaking things.
The article also says that emulation would be slow. There was a paper at VEE a few years back that used virtualisation extensions to run an AArch32 emulator on an AArch64 system and bounce system calls into the 32-bit compat interface in the kernel. It ran faster than native AArch32 mode on the same hardware for some things, slower on others, but not more than about 10% variation either way. Considering that a modern ARM core is a 2.5GHz superscalar monster and most legacy RiscOS applications were written for a 33MHz single-issue in-order core, emulation speed is unlikely to be a problem. RiscOS development pretty much died by the time 400MHz StrongARM cores were state of the art, so few legacy apps would still be faster than on the machine that they were written for, even if an emulator ran at 20% of native speed.
Well, yes, there has already been an attempt to retrofit pre-emption, as I mentioned in the piece. It’s called Wimp2 and I believe it broke compatibility with a lot of stuff.
The 26-bit to 32-bit transition was initiated inside Pace, but finalised by Castle Technology when they sub-licensed (later, purchased) Pace’s RISC OS licence which was bought to make the Acorn NC range. It did break almost everything compiled, but for those things where the authors were alive and still involved, I believe updating software was not too hard.
I am much heartened by your comments on running 32-bit stuff on 64-bit, though. That is good news.
If I may be permitted a moment of self-indulgence, this feels like a cautionary tale for my Mu project. I chose to implement it in x86 in hopes that it would be easy to try out. However, I’m starting to have some regrets about using 32-bit x86. It’s more aesthetically pleasing and efficient (no REX bytes all over the place, pointers take less space) but support for it is slowly fading from mainstream OSs.
When I started Mu I planned eventually to have my own OS, which would make this moot. (Hopefully Intel won’t ever stop supporting 32-bit. Right? Right?) However, over the last 3 years I’m slowly gaining an appreciation for just how much work and sheer learning that’s going to take.
Intel still supports real mode; 32-bit support will live as long as the architecture survives.
x64 doesn’t support running 16-bit apps under emulation and there are a lot of dusty decks out there.
There’s no reason you couldn’t retrofit preemptive multitasking and memory protection to RiscOS. Legacy apps wouldn’t be aware of the fact that they were preempted and you’d still allow them to cooperatively schedule threads within the apps. Each app would see its own 26-bit virtual address space if you added memory protection. I thought Acorn added both of those features around RiscOS 3 but apparently I misremembered. I’m pretty sure it did move to a 32-bit address space because I remember the 26->32-bit transition breaking things.
The article also says that emulation would be slow. There was a paper at VEE a few years back that used virtualisation extensions to run an AArch32 emulator on an AArch64 system and bounce system calls into the 32-bit compat interface in the kernel. It ran faster than native AArch32 mode on the same hardware for some things, slower on others, but not more than about 10% variation either way. Considering that a modern ARM core is a 2.5GHz superscalar monster and most legacy RiscOS applications were written for a 33MHz single-issue in-order core, emulation speed is unlikely to be a problem. RiscOS development pretty much died by the time 400MHz StrongARM cores were state of the art, so few legacy apps would still be faster than on the machine that they were written for, even if an emulator ran at 20% of native speed.
Thanks for the comment!
Well, yes, there has already been an attempt to retrofit pre-emption, as I mentioned in the piece. It’s called Wimp2 and I believe it broke compatibility with a lot of stuff.
The 26-bit to 32-bit transition was initiated inside Pace, but finalised by Castle Technology when they sub-licensed (later, purchased) Pace’s RISC OS licence which was bought to make the Acorn NC range. It did break almost everything compiled, but for those things where the authors were alive and still involved, I believe updating software was not too hard.
I am much heartened by your comments on running 32-bit stuff on 64-bit, though. That is good news.
If I may be permitted a moment of self-indulgence, this feels like a cautionary tale for my Mu project. I chose to implement it in x86 in hopes that it would be easy to try out. However, I’m starting to have some regrets about using 32-bit x86. It’s more aesthetically pleasing and efficient (no REX bytes all over the place, pointers take less space) but support for it is slowly fading from mainstream OSs.
When I started Mu I planned eventually to have my own OS, which would make this moot. (Hopefully Intel won’t ever stop supporting 32-bit. Right? Right?) However, over the last 3 years I’m slowly gaining an appreciation for just how much work and sheer learning that’s going to take.
Intel still supports real mode; 32-bit support will live as long as the architecture survives.
x64 doesn’t support running 16-bit apps under emulation and there are a lot of dusty decks out there.