If RISC OS 3.11 had been written in C, then

If RISC OS 3.11 had been a C re-write of RISC OS 2 then:
- We would have had a slightly slower experience on our computers.
- only slightly slower. The OS never really ‘got in the way’ as such. Games, software could still have been written in ASM.
- we would have had to lose perhaps one of the ROM apps. Maybe !Draw?
- or, for a few pounds more per machine, we could have had larger physical ROMS (perhaps a carrier board / bank swap logic for A3xx, A3000?).

RISC OS 3.5 would have been a lot easier to produce. It could have been 32-bit from the start.
- Acorn would have had a LOT of spare time on their hands. They could have used this to make something like !AEmulor, and to integrate better backwards compatibility. And many other things.
– if RISC OS 3.5 was in C, a lot of the OS coding work towards StrongARM compatibility, and later to Phoebe, would have been quicker.
– this would have given Acorn more time to work on ‘ARX 2.0’. They had that kernel running when they were shut down. If they had had more time, RISC OS could have become a ‘VM’ within that new OS.
– Apple were probably happy that Acorn didn’t get a chance to make a pre-emptive tasking OS design (for, but not only for) mobile devices powered by ARM processors, with a focus on intermet connected devices and ‘quality of service’ multitasking. Sounds like iOS, just 10 years early… (ahem, Acorn NewsPad … Apple iPad?)

We would be able to backport RISC OS 5 to 26-bit machines (why not? Maybe ROM switching logic and a carrier board with RISC OS 3.11 and RISC OS 5 :)

Things would have been different. Of course, we wouldn’t be on these forums, and probably wouldn’t have had the source code for RISC OS eithee!

Also found this https://www.theregister.com/2022/06/23/how_risc_os_happened/

Pish

RISC OS 5 on Acorn A4? One can dream (it is Aldershot after all!) :)

Edit : of course, my other idea about the A4 makes a lot more sense.

Put a Raspberry Pi 4 inside the A4 (loads of room once you have an SD card for HDD and a small FDD USB emulator). Connect the RaspBerry Pi to the A4 over Ethernet. Detect a certain keypress on boot to load a fullscreen VNC-like screen sharing thingy. Use keyboard as normal. Put a touchpad where there should have been one (Triumph-Adler Walkstation used a trackball).

(Or…)

Retrofit IOMD to an A4. Given that IOMD was developed on modded A5000s anyway :) then backport RISCOS 5 to RISCOS 5 26-bit edition

Don’t think about what could have been

Don’t think about what could have been

What could have been?

ARX was a thing. RISC OS never was because ARX was “good enough” if not great. After a few years Acorn struggled because ARX really needed higher end hardware and Acorn made a niche in desktop publishing with Impression, but it was a hard sell to put the machines in schools or to sell to home users because of the price of memory and storage. Acorn eventually met it’s demise in 1993 and because of this the ARM processor is unfortunately a forgotten relic of the days before “everything is a PC”. Smartphones are a thing these days, but they’re slightly chunkier because of the power requirements of the MIPS processors inside them. Lower end devices sometimes use cut down x86 chipsets, and it’s just accepted that the battery will need to be charged up during the day to keep the things going.

Oh, and Apple isn’t the behemoth it is now. They did try to go the phone/tablet route, but in trying to meet Jobs’ ideals, they tried PowerPC, they tried x86, and they tried MIPS but nothing really worked and all were incompatible with each other so they gave up. They’re kind of a big deal in graphics and design and they’ve made a nice little niche in the case of video editing, but that’s about it. Most of the world runs Win-X these days.

That’s what could have been. So let’s now concentrate on what is, eh? ;)

If RISC OS 3.11 had been written in C, then

I’d still be waiting for my A310 to boot.

“I’d still be waiting for my A310 to boot.”

(Assuming it was upgraded to RISC OS 3.11):

It would be a bit slower to boot, and you would need to lose some of the ROM apps due to increased code size :)

(edit : actually, I am thinking of the situation with modern C compilers; early compilers must have been much less ‘clever’ with optimisations. Also, given that the beginnings of MOS32, as well as ARM BASIC originate on the ARM1 evaluation kit, and given TWIN was in use, cross-compilation probably wasn’t immediately possible for such a niche processor as the ARM :D). It makes sense it was written in ARM).

However, if all the extras added between RISC OS 2 to RISC OS 3.11 had been in C, we would now ‘only’ be facing an ASM kernel!

FWIW, my C VDU drivers are now in C (was using CPP to compile C). Some typedef struct statements were needed. But that part of the RISC OS 5 kernel is now in C, and structured as in RISC OS (code filenames .c rather than .S, function names the same, and in the same order, most of the stuff the same). With some added structs for commonly used ‘register set structures’ (line blocks as a major example!).

In my 34 years of using RISC OS, I can state quite confidently that the worst parts of the OS are the parts written in C.

That Acorn chose incompatible register allocations for their Modules/Vectors/CallBacks/Everything on one side, and their C compiler on the other, is a spectacular self-own that still causes inefficiency, bloat and pain now. Inexplicable.

Depends on your definition of “worst”. It’s often clearer about what’s going on, which means it isn’t a massive maintenance headache, and a recompile usually takes care of issues (like “oops, can’t use X on this processor”).

I will give you the “it’s a shame APCS didn’t exist when the OS was written”, meaning everything needs to go through the veneers. But, alas, those were the days when it was considered okay to write major applications in assembler…

Au contraire, APCS predates Arthur!

The ARM CoPro and PC SpringBoard products had a C compiler don’t forget. However, that used the APCS-A standard that was abandoned after Arthur in favour of APCS-R (used since RO2).

Either way, Arthur’s use of R12 as a context pointer for the OS is extremely inconvenient for both those mappings. At least APCS-R has R12 as the temp register.

For completeness, RISC iX used yet another mapping (-U), which is just as inconvenient:

Note that Risc iX had no stack limit, which meant R10 was completely unused by USR and SVC runtimes!

Dunno what -M was defined for, I’ve not seen it used.

I don’t know what the philosophy was behind the constraints imposed on these mappings – i.e. why not use R9, why not keep R12 free – it’s certainly nothing to do with register banking beyond sp=R13 (and again, what were they smoking with APCS-A?! Did ARM1 have weird banking?). R10-R12 are as unbanked as R8-R9 (see FIQ).

So why the obsession with these particular registers, to the detriment of interfacing with the actual operating system?! (or vice versa)

definition of “worst”

Most broken. Broken for longest. Least maintained. Least developed.

I have a disparaging theory about this which I won’t air. But put it this way, the people now claiming we must “rewrite everything in C” so that “they can maintain it” do not inspire my confidence precisely because of that admission.

Many programmers claim a higher-level language means fewer low-level bugs, and this may be true. But a higher-level language means higher-level bugs.

And failing to check parameters in C is no safer than failing to check parameters in MC.

to the detriment of interfacing with the actual operating system?!

Because it wasn’t supposed to matter because we’d all be rocking ARX.

But put it this way, the people now claiming we must “rewrite everything in C” so that “they can maintain it”

I’m a “we must rewrite it in anything that’s not assembler in order that it can be maintained” person.

I promote C not because I’m a great coder or because C’s the best, but because we don’t exactly have alternatives.

If somebody thinks Rust would be better, they’re probably right. But first the compiler, then the runtime, then…

But a higher-level language means higher-level bugs.

True, and C’s pointer funkiness is basically handing out hanging ropes with a gleeful smile…

That being said, RISC OS is quite sensitive to things like not (un)stacking things correctly in module code, or dumb brain farts like LDR R10, [R10]! that will cause an exception on more recent processors. Using C, I don’t need to worry about any of that crap. I don’t need to worry about what sort of instructions work best or how to schedule them. I tell the compiler and… it probably generates the same code, but whatever, NMFP.

And failing to check parameters in C is no safer than failing to check parameters in MC.

RISC OS is not a good example here. ;)

Every time I come back to C, I realise it’s closer to assembler than an actual high level language. I’ve just ported some TCP/IP code from C to Python, which I originally wrote on RISC OS for an industrial controller over 30 years ago. The Python is a fraction of the size and far easier to follow, mainly due being able to use exceptions rather than having to check the return values of evert function, but also having objects makes things much easier and avoids a preponderance of pointers. I really couldn’t stomach doing anything sizeable in anything less primitive than C++ these days, and a more sane subset of modern C++ at that. Of course that’s a non starter for RISC OS, as Acorn never progressed beyond a 1987 copy of CFront, and I’m assuming we still can’t build ROMs with gcc.

We first got the ability to create relocatable modules using C (APCS-R) with Acorn C Release 3, release note stating August 1989. That’s 11 months after RISC OS 2.0 went off for ROMing. To this day Norcroft C still cannot create ROM-able relocatable modules.

brain farts like LDR R10, [R10]! that will cause an exception on more recent processors. Using C, I don’t need to worry about any of that crap.

Not since late 2021 anyway, when a similar C compiler writeback bug was fixed! https://www.riscosopen.org/forum/forums/4/topics/16807

“To this day Norcroft C still cannot create ROM-able relocatable modules.”

What is the issue re: ROMable modules? (Naive question I am sure!); if we can”t do this, then that is a major barrier to C’ing RISC OS!

Is it specifically about ROM modules containing functions that are called directly from other ROM code (like the kernel), and getting those calls properly linked up? I have noted that the ShellCLI module is in C;

Is there a workaround? If not, this should be priority #1 fix (or priority #1 workaround) for RISC OS moving forward!

What is the issue re: ROMable modules?

You can produce ROMable modules using Norcroft C, but they have to be statically linked to the SharedCLibrary routines in that particular ROM.

Alternatively, you can produce relocatable modules, but they fix up addresses at run-time so can’t live in ROM.

Not use the ‘SharedCLib’ :-/

[Edit]
I seem to remember that ‘Aemulor’ took this route – ie containing it’s own CLib routines.

“You can produce ROMable modules using Norcroft C, but they have to be statically linked to the SharedCLibrary routines in that particular ROM.”

Can see how that is problematic!

a major barrier to C’ing RISC OS

It’s not a barrier – that is how RISC OS ROMs have been produced since RISC OS 3.0. It’s just that the modules created with C in the ROM aren’t in fact relocatable and have build-time assigned addresses. Try RMFaster on one, no, don’t. Given how easy it is to produce PIC on ARM, this has always annoyed me.

I think a more majorer barrier is how much of CLib depends upon OS functions, which would make it hard rubber have an OS in C because catch 22.
But, then, surely any C implementation will have a different way of working than trying to bash the old assembler interface and SWI mechanism to work in a C world?

aren’t in fact relocatable and have build-time assigned addresses.

Draw, Edit, Paint… about the only things that are safe from softloading a newer CLib.

Try RMFaster on one, no, don’t.

That, along with RMTidy, are commands that should have been retired a long time ago.

RMTidy, I think, is a dummy command anyway. Since the OS handed back pointers to memory blocks and not opaque pointers that had to be loaded before use, the whole concept of RMTidy was never going to work.

this has always annoyed me.

That softloaded builds of CLib didn’t refuse to quit always annoyed me. I’ve heard various “excuses” along the way (“but CLib doesn’t keep track of clients so maybe nobody is using it”) which is a nonsense argument given that the alternative is everything blows up, risk of catastrophic data loss.

It’s just that the modules created with C in the ROM aren’t in fact relocatable and have build-time assigned addresses. Given how easy it is to produce PIC on ARM, this has always annoyed me.

It could have been done by the module stubs claiming some RMA to build the SCL jump table in, and indirecting all calls through that. Perhaps, if the underspec’d 512K A305 hadn’t been made and all RISC OS machines had at least 1MB of memory, this could have been done.

Is the Shared C Library closed source? Have had a look at the source code, probably not opening the correct folder? In particular, am trying to find the version that gets built into the ROM itself?

Edit – found it (Sources.RISC_OSLib)

Looking into this further – is there a list of ‘what can be used from the C Library(ies) in ROMmable modules’?

ShellCLI is a ROM module, and uses

Stuart suggested

Try RMFaster on one, no, don’t. Given how easy it is to produce PIC on ARM, this has always annoyed me.

I’m with you there brother.

Druck decided

It could have been done by the module stubs claiming some RMA to build the SCL jump table in

That’s the least of it. The compiler simply doesn’t emit position-independent ARM code – pointers stored within the binary are absolute not relative addresses. For writable memory they’re offset using a value at the base of the stack (load static ‘pointer’ from binary, load static offset from stack, add them to get actual address, access the workspace), but for code pointers they’re simply absolute, and this relocation code gets added to RAM builds (and omitted from ROM builds as Stuart implies):

This is unforgivable on ARM

I’m with Stuart – the compilers are very half-hearted about RISC OS. The ARM code they produce just isn’t very nice. It feels like they really want to be generating code for some other OS. Linux, say. R12-relative workspace and PC-relative code addresses are simply beyond it. The best it manages is ADD PC,PC,Rn,LSL#2 sometimes (though it often prefers to compare individual values and branch).

tymaja tried

Is there a way to find out what can / cannot be used from the CLib in a ROM module

You’ve misunderstood. SharedCLibrary is entirely usable from ROM modules. The problem is that the ROM build statically links the modules with the CLib. So loading a new version of the library doesn’t change the code that those modules are using – hence bugs can’t be fixed with a softload.

It is typical in RO4 to have two CLibs – the ROM one that the ROM C Modules are linked to, and a newer RMA-loaded one that everything else then links to. eg on my machine:

82 System ROM   SharedCLibrary          4.98    Dormant
75 RMA          SharedCLibrary          5.59    Active

Oh the fun of 32bitting a 26bit ‘C’ module without source code :-)