Deterministic latency. That usually means no cache, speculative execution, or anything else that can't guarantee it will complete in a reasonable time.

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.

Thanks! I guess in the designing of the accompanying software then, the people writing it probably spend equal (or more) time in writing what happens if the expected/desired behavior fails, than if it succeeds?

It sounds analogous to the question of deterministic memory usage (vs GC), but at a hardware level and for runtime instead of memory

Realtime is both software and hardware.

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)

> realtime OS won't do much preemption, probably would rather stick to cooperative scheduling.

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.