The situation RISC OS dates to the beginning of ARM and still lives but is 32bit only and in assembly. They have been getting sponsorship for small improvements.
32bit Arm is going away.
They are looking for the resources for a 64bit port.
That seems like an entirely reasonable ask. I don't know if enough people are interested but it seems entirely reasonable to ask.
All 32 bits in the ARM1 and 2 were used to address data, so in theory you could have 4GB of RAM. But these processors only had 26 address pins, so that would give you at most 64MB (similar to the 24 address pins in the 68000). If you used the MEMC chip to interface to your DRAM then the limit would be a mere 4MB.
For code the limitation was baked into the architecture itself. The bottom two bits of the program counter were used to define the current execution mode (and always output as 0 to fetch word aligned instructions) while the top six bits were the status flag. That meant that saving the PC to the stack saved the whole execution context in a single memory write and it only took one read to restore it.
Fixing this required moving the flags to a separate register, which was a very visible change.
That's no doubt why this is a big issue for ROOL, as the pi is one of the main things they run on. Very few people would buy something just to run RiscOS so they need a relatively common platform.
Wasn't OpenVMS stuck in a similar situation in the late 1980s, where they had tons of VAX MACRO assembly files they had to transpile to Alpha, then Itanium and nowadays x86_64?
VAX is a rather different beast than 32-bit ARM and that bandaid would result in a hybrid 32/64-bit operating system, but I wonder if a similar solution could be implemented for RISC OS.
One aspect might be "avoiding getting stuck in local maxima".
Starting with a "parallel universe" like RiscOS, FreeDOS, or the numerous Amiga-necromancy projects might make it easier to get to some clever idea that we wouldn't easily find starting from the assumptions modern Linux systems impose.
The situation RISC OS dates to the beginning of ARM and still lives but is 32bit only and in assembly. They have been getting sponsorship for small improvements.
32bit Arm is going away.
They are looking for the resources for a 64bit port.
That seems like an entirely reasonable ask. I don't know if enough people are interested but it seems entirely reasonable to ask.
This seems totally reasonable but wasn’t the original problem that RiscOS was 26bit Arm?
It was originally 26 bit (running on 32 bit processors but only 26 bits used for addressing RAM? Something like that...)
At some point was updated to 32 bit, you can run it on a Raspberry Pi.
All 32 bits in the ARM1 and 2 were used to address data, so in theory you could have 4GB of RAM. But these processors only had 26 address pins, so that would give you at most 64MB (similar to the 24 address pins in the 68000). If you used the MEMC chip to interface to your DRAM then the limit would be a mere 4MB.
For code the limitation was baked into the architecture itself. The bottom two bits of the program counter were used to define the current execution mode (and always output as 0 to fetch word aligned instructions) while the top six bits were the status flag. That meant that saving the PC to the stack saved the whole execution context in a single memory write and it only took one read to restore it.
Fixing this required moving the flags to a separate register, which was a very visible change.
"32bit Arm is going away."
Unlikely for embedded.
It's true in context. 32bit is going away for the class of device most people would run riscos on.
At the same time, many AArch64 implementations will run a 32-bit kernel.
Granted, some do not. Fujitsu's supercomputer comes to mind.
Yeah. It turns out, even Arm's A76, which is what the raspberry pi 5 uses, doesn't support a 32 bit kernel: https://www.theregister.com/2018/05/31/arm_cortex_a76/
That's no doubt why this is a big issue for ROOL, as the pi is one of the main things they run on. Very few people would buy something just to run RiscOS so they need a relatively common platform.
Wasn't OpenVMS stuck in a similar situation in the late 1980s, where they had tons of VAX MACRO assembly files they had to transpile to Alpha, then Itanium and nowadays x86_64?
VAX is a rather different beast than 32-bit ARM and that bandaid would result in a hybrid 32/64-bit operating system, but I wonder if a similar solution could be implemented for RISC OS.
Additional context: https://www.riscosopen.org/content/documents/risc-os-moonsho...
For RISC-OS's future, it'd make sense to invest on a RV64GC port.
I wish it could handle larger disks and had a decent browser.
[dead]
ROOL is seeking: * Funding partners * Experienced embedded software engineers * Community advocates
So they have non of those. What’s the point then?
> So they have non of those.
It just implies that they don't have sufficiently many of those.
> What’s the point then?
Well, to change this unsustainable situation. :-)
Any new operating system has to answer the question “why? what will this do that Linux can’t?”.
If there’s a good answer to that, sure build it, but Linux is incredibly flexible, powerful, honed, compatible and other things.
I see the romance in bringing a historic operating system into the future but without good reason there’s little point.
One aspect might be "avoiding getting stuck in local maxima".
Starting with a "parallel universe" like RiscOS, FreeDOS, or the numerous Amiga-necromancy projects might make it easier to get to some clever idea that we wouldn't easily find starting from the assumptions modern Linux systems impose.