Why are old CPUs like MOS Technology 6502 and Motorola 68000 considered better for real time systems applications than modern x86 based CPUs?

Question

Reading the Wikipedia article about real-time computing, I found written that:

Once when the MOS Technology 6502 (used in the Commodore 64 and Apple II), and later when the Motorola 68000 (used in the Macintosh, Atari ST, and Commodore Amiga) were popular, anybody could use their home computer as a real-time system.

The next sentence elaborates a little on that claim:

The possibility to deactivate other interrupts allowed for hard-coded loops with defined timing and the low interrupt latency allowed the implementation of a real-time operating system, giving the user interface and the disk drives lower priority than the real-time thread.

After this they are contrasted with the modern CPUs and operating systems depending on them:

Compared to these the programmable interrupt controller of the Intel CPUs (8086..80586) generates a very large latency and the Windows operating system is neither a real-time operating system nor does it allow a program to take over the CPU completely and use its own scheduler, without using native machine language and thus surpassing all interrupting Windows code.

Could someone elaborate a bit more on this information and give some examples for "deactivating other interupts" and "hard-coded loops with defined timing" to clear what it exactly means and to give some additional reasons with appropriate examples, if any?

Answer 1

On a typical 6502, Z80, or 68000 system, it's possible to predict very precisely exactly how long a piece of code will take to execute. The same is true, incidentally, of many small microcontrollers produced today. In many cases, this allows some operations to be done more efficiently than would otherwise be possible.

For example, if both function-control latches are set, the Apple's Disk II controller card will, once every four cycles, grab whatever happens to be on the CPU bus into its shift register for transmission to disk. To output a stream of data, the CPU must compute each byte byte, write it to a register which turns on control latch #1 [this operation takes four cycles, and will both set the latch and put the proper value on the data bus during the fourth cycle], and then turn off control latch #1 [which also takes four cycles, clearing the latch on the fourth cycle], then compute the next byte and repeat the sequence, with each byte's "set control latch #1" operation starting exactly 32 cycles after that of the previous byte. Disk-writing code wouldn't include any data to check whether the controller is ready for a byte of data; instead, it would blindly expect that if latch #1 is on and #2 is off, the controller will look for data at a fixed intervals starting a certain amount of time after latch #2 turns on.

On modern CPUs, out-of-order execution, memory caching, and many other features will improve the speed with which many operations are performed, most of the time, but predicting how much the speed will be improved would often be impractical. If code accesses a piece of memory that had not been accessed in a long time and wasn't in a region of fast memory called the cache, the access would need to be performed using slow memory, but the data would get copied to the cache so that if it's needed again soon, it can be fetched more quickly--often more than an order of magnitude faster. Because the cache is much smaller than main memory, however, data which is in the cache but hasn't been used for awhile will often need to be displaced to make room for other data. Although it's unlikely, one may end up with situations where the CPU repeatedly selects for displacement information that's about to be used again. Fetching data from memory in a sequence that causes that to occur may take an order of magnitude longer than fetching that same data in a slightly different sequence.

On systems using a simple processor or controller, in most cases where the CPU would usually be significantly faster than needed to accomplish what needs to be done, one could establish that it will always be at least fast enough. There may be some timing uncertainties with regard to how long it will take to handle an event if some other event happens simultaneously, but it's usually possible to compute worst-case timings and will be fairly close to what could realistically occur. On fancier high-performance machines, however, it may be possible to guarantee that timing targets will be met unless more than 50% of memory accesses in a stretch of code result in cache misses, and one may determine that it would be unlikely for even 20% of the accesses to result in cache misses, but it may be very hard to prove that no sequence of inputs could cause 80% or more of the accesses to result in cache misses, which could in turn prevent a program from meeting a timing deadline.

Answer 2

This paragraph in Wikipedia really is no candidate for the best entry-of-the-year award. It seems to be comparing Apples with Oranges. (Or rather starts talking about CPUs, then commences on PCs vs. "something else", i.e. system architecture). A comparison of interrupt latency and predictability thereof doesn't make much sense on CPU level - It must be done on system level, as all components of a system can affect this timing and need to be taken into account for comparison.

Wikipedia seems to have realized that and warns you with a "largely unverified" banner. So, take it with a grain of salt (or, rather, a spoonful).

While it is true that the 8259 in a PC (contemporary to the mentioned 68k and 6510, not a modern one) adds some overhead to the interrupt latency, this is not at all a trait of the x86 CPU, but rather one of the IBM PC's architecture. You can easily add an interrupt controller to a 68k system and it will add the same latency there. Lots of 68k computers BTW did that - The Atari ST (with its MFP) and the Amiga, had both interrupt and DMA controllers that introduced similar latency and bus contention overheads.

Intel's x86 architecture can just as well be used for real-time applications - and this has been done successfully in the past - many embedded systems were based on 80186 and 80386 CPUs - just not on an IBM PC architecture.

MS Windows didn't help much as well, so it was out of the question for running realtime applications - But there were (and are) quite some real-time OS for x86, like QNX or VxWorks, and there are even real-time Linux derivates for x86 CPUs.

Of the three computers mentioned, the Commodore Amiga is probably the computer with the least predictable interrupt latency - Its custom chips are allowed to take over and occupy the bus for a significant and relatively unpredictable amount of time (length of a possible DMA access is of concern here).

Taking superscalar traits of a CPU (like out-of-order-execution, parallel instruction execution, branch prediction, caches,...) into the argument (started with the Pentium on Intel's range of CPUs), still doesn't distinguish the Intel CPU range as particularly bad - Motorola had, with the 68060, very similar technology in its portfolio with very similar consequences on predictability (obviously, there is no 6502 derivate with such features).

Some more comments on the Wikipedia paragraph:

On ...anybody could use their home computer as a real-time system.:

Well, yes and no. To my knowledge, there was no real-time multitasking OS available for any of the mentioned home computers other than the Atari ST, which had OS-9 and RTOS-UH, both respectable RTOSs. So, using any other such HC as a real-time system required you to write your OS from scratch - Not a task for the faint-hearted, and not distinguishing these computers at all from x86-based computers - you could have done the very same thing there.

On ... possibility to deactivate other interrupts allowed for hard-coded loops with defined timing and the low interrupt latency

Deactivating interrupts and hard-coded tight loops are both definite no-nos for real-time systems. This seems to be alluding to "racing-the-beam" applications and other tight synchronisation to video timing techniques, mainly used in the home computer demo scene. While those techniques are definitly closely dependant on timing, they are basically the opposite of a real-time system - as they hog the CPU for quite a long time for one single task, like busy-waiting until the CRT beam reaches some definite position. This indeed does rely on low interrupt latency, but also heavily increases latency for anything else. Nonwithstanding that, there is no reason you couldn't do the same thing on an x86-based computer (maybe not the IBM PC, again because of its architecture)

Answer 3

It's the simplicity.

Under modern general purpose operating systems, you don't usually have hard real-time guarantees. Too many things are going on. Context switching is slow. Interrupts are slow. The kernel is often not fully pre-emptable.

On top of all that, modern hardware incorporates features like speculative execution, extensive pipelining, multiple levels of cache and other features that make instruction execution timings very complex. It can be impossible to predict instruction timing, except to give an upper limit.

This means that, if you have a process running on a Linux system in a tight loop, you don't know when the next instruction will run. It could be in 2 nanoseconds, in 2 microseconds, or in 2 milliseconds.

On a 6502 running at 1 MHz, you know it takes exactly 2 microseconds to execute a CLC instruction. You can trace your code lock-step with real-time if you want.

There is no real barrier to that level of control on a modern x86 machine in principle; it's just very complicated compared to the simplicity of simpler machines.

Answer 4

There are three principal reasons:

1: Realtime software demands CPUs whose execution time is highly predictable. That is true mostly of CPUs without speculative features such as caching and dynamic branch prediction. Some modern CPUs (eg. ARM Cortex-R series) are specifically designed to provide this property.

2: Low interrupt latency and overhead, on the order of a single-digit cycle count. This is a feature of the 6502 (which has a maximum interrupt latency of about 15 cycles to the first instruction in the ISR, and a minimum of one cycle if correctly prepared with the WAI instruction) and the ARM (which has a dedicated alternate register bank for handling FIRQs, eliminating the overhead of saving registers to stack), but decidedly not of the 68000 and x86 families. The 68000 and 68020 are sometimes used where interrupt latency is less of a concern.

3: Ability to run at "micropower", ie. less than a milliwatt, in embedded applications that demand extremely long battery life, sometimes on the order of several years (eg. 6502s are used in pacemakers). This practically demands a "fully static" CMOS implementation. Current production 6502 and ARM CPUs can achieve that in practice; your average x86 CPU and its auxiliary hardware eats several watts at full idle sleep.

Answer 5

While many of the performance capabilities of modern desktop processors intended to run multi-tasking operating systems are somewhat wasted in a real time context, they are not actually impediments.

A soundly designed real time operating system uses hardware timers for the precise timing needs in terms of scheduling when code runs. Desktop operating systems typically have trouble performing to the true capability of the hardware, though there are various strategies for altering scheduling to prioritize certain tasks; at an extreme, a hard realtime schedular can own the actual hardware, and run the kernel of a conventional multi-tasking operating system as its lowest priority task. Most of the software architecture problems inherent in using commodity desktop hardware for real time control are thus solvable. Ad

However, most modern commodity computer boards are ill-suited for realtime control for another reason: the lack of low-latency I/O, at least in any easily interfaced form. Once local-bus I/O channels like true parallel ports were replace by things proxied through multiple levels of protocol indirection (USB being the notorious case) it became far harder for even carefully engineering code to interact with the external world in a timely fashion.

What's fundamentally different about a modern ARM SoC or MCU that is suitable for real time applications, vs a typical x86 desktop platform that is not, is the provision of simple I/O schemes directly from the processor, eg, memory-mapped GPIOs, hardware timers with input/output channels, etc. Nothing says that a part with a computational architecture in the x86 tradition could not have these (and indeed, from time to time vendors try an offering...) but these tend to lose in the marketplace, both to the flash-based ARM parts suitable for small problems, and the more tablet/router-class ARM/MIPS/etc SoC's used for larger ones.

Typically what this all points to is the use of an distinct processor for real time tasks. Some modern control-oriented SoC's even include one right on chip; in the PC world the existence of I/O copressors goes right back to the start and far simpler problems, eg, the original IBM PC has an early MCU on it simply to deal with the keyboard interface (and another in the keyboard) and the presence of additional processor continues to this day. In the control realm, it's common to see things like a 3d printer which has a realtime G-code interpreter running in a small flash based MCU, and then a larger platform like PC or raspberry pi (or an ESP8266 talking to an Android tablet) which then provides a user interface and drip-feeds stored programs just ahead of need. This not only solves the I/O latency problem, it also simplifies software by having the real-time and non-real-time code run on entirely separate computational engines, rather than having to fight over a single execution core.

Answer 6

I simply have to add my take on this subject. And, basically, it misses the most important parts. You cannot talk about real-time unless you add two important parameters:

• what time scale are you talking about?
• what are the consequences of missing a deadline?

My belief is that the wikipedia article as well as several of the answers given are very much a question of "old-school" thinking in the box. It used to be that real-time was esoteric, today it is extremely commonplace.

Time scale The definition of realtime might include working with things happening on the hour, the minute, the second, the millisecond, the microsecond or the nanosecond scale. No 6502 or 68000 microcomputer in itself will help you in controlling things happening on the nanosecond scale. On the other hand you could probably use any computer chip controlling things on the hourly scale. And all time scales do exist in what are called real-time. Controlling healing in a house as example is somewhere between minute and hour on the scale. Assembling information from an particle collision experiment at CERN might be on the nanosecond scale.

Consequence of missing a deadline The most common real-time application today I would say is running Youtube. Here the computer outputs both video and sound fetching it from the internet without you as user noticing stuttering or delay. Most of the time that is. In this application missing a deadline, creating what the kids call a lag, is not especially serious.

In other cases, missing the deadline might kill people, say in controlling the ABS breaks in a car. When missing the deadline may actually lead to death, you would not rely on the computer chip and the program as the only safety. You add safety circuits and functions outside the computer chip as part of the system. These extra circuits may extend to taking over the software functions, perhaps with a slighly lower efficiency or performance.

Why the 6502 or 68000 Again, this is to me old school thinking. That answer focuses on one aspect only, how well the programmer can understand what the computer chip is doing. And it generally assume something like a millisecond time scale. If we widen the horizon a bit, we find that any discussion would need to include the whole system as such, where the computer chip is only one part. Yes, of course, you may find exemples where one or the other property of the computer chip is the limiting factor. But to state it again, you need to look at the totality of the system and the requirements of the environment.

Finally the answer

Why are old CPUs like MOS Technology 6502 and Motorola 68000 considered better for real time systems applications than modern x86 based CPUs?

Because the persons writing that kind of things are old-school and not thinking outside their little box.