What's the hardware difference required to support real time? Is it some dedicated parts of compute to support the queueing / prioritization of jobs? And some additional ability to have the "master" must-always-work part be able to interrupt or reset "optional" processes?
Specifically, in many architectures interrupt handling code must be able to yield _very_ quickly in order to continue receiving interrupts (or use reentrant interrupts which are a whole other mess) and even a cache look up, which might fail and have to wait for DDR ram for hundreds or thousands of cycles, makes the system unable to guarantee that it will do what it needs to do in time, like respond to some safety shutoff switch.
I think one of the things ARM did here is make a way for interrupt handling code to stay in cache permanently along with some other determinism guarantees.
A realtime OS won't do much preemption, probably would rather stick to cooperative scheduling.
On the hardware side, explicit cache controls are big in realtime chips. Your programmers know exactly which data is in cache and what isn't, and therefore can accurately plan how long tasks take.
The MMU traditionally wasn't realtime. I wonder how they managed to get realtime controls with virtual memory. (They must have some kind of guarantee on TLB lookups or something)
I've seen realtime OSes that were very preemptive, at least between priorities. Tasks/processes had priorities, and a higher-priority task that became active would preempt anything lower-priority that was running. vxWorks ran this way, IIRC, and it wasn't alone.
https://www.oracle.com/technical-resources/articles/javase/J...
(somebody correct me if this is wrong)