Stuff like branch prediction probably isn't too useful to implement as a switchable feature. Instead, the core is designed so that mispredict latency is still reasonably short (short pipeline, in-order execution or OoO with a short reorder window). This means you won't get as much benefit from speculative work as you would on a desktop-class core, but you're probably not going to be as vulnerable to Spectre-style attacks, either.

So, there is a spectrum of realtime and how "hard" it needs to be. There are a lot of cases where simply having a real time OS on a traditional processor is fine as long as everything can be sufficiently bounded.

I've only worked with one RTOS, and a lightweight one at that.

The scheduler would run every time an interrupt handler finished running.

One such interrupt was the 'systick' - you can choose if you want it to run every 1ms, or 100us, or a different rate (depending on how fast your CPU is)

The systick was how you timed anything you didn't want to use a dedicated hardware timer for. If you want to wait 10ms and your systick happened every 1ms, you waited until the 10th systick.

If you want to time something with finer resolution than 1ms, you either made your systick faster, or used a hardware timer with the interrupt triggering the scheduler.

> Just hardcoding the interrupts resulted in 1us resolution easily.

If your CPU runs at 180MHz, 1us is enough time for 180 clock cycles. Plenty of time to run one reasonably carefully coded interrupt handler, not much time to run 10 interrupt handlers.

As you can imagine, running your systick at 1us with that clock rate would be challenging!

I would say there are two (2) sets of realtime definitions.

1) concerning amount of events

Hard realtime system always produces output to an input in predefined time (subject to clocking). This time can vary between different inputs, but is fixed for a given input.

Soft realtime systems are bound - output time is bounded to some number.

2) concerning number of inputs

Hard realtime system has bound reaction time to every possible input

Soft realtime system has bound reaction time to "critical" inputs.

---

Definitions used in practice mix the two in some ways. The most prevalent definition I happen to come across in the general internet is something like "realtime system has bounded, low-variation reaction time to critical inputs".

Specifically with the R-family ARM chips, there is support for things like tightly-coupled memory (https://developer.arm.com/documentation/ddi0338/g/level-one-...) to provide latency guarantees for real-time code, deterministic interrupts, that kind of thing.

Real-time systems show up especially in industrial control and safety systems. For example, take a logging harvester, which cuts down trees and strips their branches and bark. It has a control panel for moving incredibly violent, dangerous machinery. It is truly critical that you can guarantee that, for example, sensors which detect a problem can abort something within a very tight latency budget.

I think you are missing something here.

Real Time systems aren't designed for high performance at all and instead they are designed for predictability.

You aren't aiming to "hit your metric", you are aiming to never, even go below it.

This is useful for something like old-style spinning hard drives where you had to calculate where to move the head of the disk within the time of the rotation. You have a instructions/second budget, and you know it will execute that.

On non-realtime hardware (and software) you know how many instructions/second it can do, but things like speculative execution of caching strategies or non-RTOS mean those instructions are not guaranteed at all.

It's pretty rare in software for it to define minimum performance. There's good reasons for this - software is interacting with intrinsicly messy things (like humans) and so performance outliers are a big factor.

It's pretty common in software for the worse case to be 10x the "hit your metric" case, and this isn't viewed as bad: the worst case happens rarely enough for the trade off to be worth it.

I am coming from the hardware world, through raw assembly, to C so my path is very much the assumption that if the microcontroller is going to control a feedback loop that stabilizes at 10MHz it will be guaranteed to do so.

But I suppose that I actually do that by overspecifying things nowadays since it's much too unpredictable as you say to predict how long things will take.

To me if you say you sample at 100kHz you sample at a minimum of 100kHz. Very very good to know that if I work with a firmware engineer that they won't hear the same thing as I mean if I say that it needs to hit a 100kHz sampling rate.

It would be very disappointing if they wrote a loop designed to average a 100kHz sampling rate with random jitter... (kidding mostly, I'd assume they would at least not do that).

That value doesn't have to be anything in particular. Could be 1ms. Could be 100ms. Could be a year. It just has to exist and be documented, and never, ever be exceeded by whatever operations are covered by its guarantee.

Generally, hard realtime means missing a deadline in unacceptable, but does not necessarily imply that latency is exactly fixed—just bounded. Soft realtime means that the consequences of missing a deadline are less severe, so the system may allow for some missed deadlines: eg. dropped packets for a video conference or delayed frames for a video game are noticeable especially if they become common, but they don't crash the whole system and the system remains useful even after missing a deadline.

There's no such requirement.

All hard realtime needs is the guarantee that the value will never be exceeded.