Multiple microprocessors as a single CPU (not multiprocessing)

I hope it's ok to answer here instead of on vcfed.org since I don't want to create yet another account...

Sun workstations did not use the dual 68000 approach to handle VM. The problem with the 68000 was that it didn't save enough information on the stack when an exception occurred (e.g. a page fault), so a faulting instruction could not be recovered/re-executed in all cases.

Sun solved this by using "harmless" instructions such as "tst" that did non have to be recovered in case of a page fault. The OS could then kick in, load the contents to memory and just skip the failed instruction. This required changes to the compiler, e.g. when creating a new stack frame that would have required to extend the stack size. For paging, this approach would cause significant overhead. However, the first versions of SunOS which ran on the Sun 1 workstations were based on 7th Edition Unix and used only swapping.

The 68010, used in the Sun-2 workstation, fixed the restarting problem by saving sufficient state to the stack, so SunOS could switch to an early BSD release as its basis.

AFAIK, the dual 68000 approach was used by early Apollo workstations instead. The way I understand it is that the second processor was idling until a page fault occurred. The 68000 has an asynchronous bus which requires an explicit acknowledge (/DTACK) to indicate that data (e.g. from slow memory) has arrived. This feature was used by the Apollos - the second 68k would kick in while /DTACK on the first 68k was deasserted, handle the required virtual memory operations, and then indicated that the first CPU can continue working. So here, no bus error was indicated (which would have caused the restarting problem), but the virtual memory behaved like a very slow physical memory. Apollos were able to perform remote memory accesses to other machines over the TokenRing interface (which was about as fast as memory accesses - 12 Mbit/s IIRC), so this feature was much more useful for DomainOS than for early Unix systems.

Another not quite that interesting approach (more of an I/O coprocessor) was used when you put a Z80 CP/M "Softcard" into a (6502-based) Apple II.

Steve Wozniak's floppy controller was very simple on the hardware side (more or less only a state machine implemented in a PROM), so most of the data serializing/deserializing and GCR de/encoding was done in software on the 6502. This was very timing-critical, so implementing this in Z80 code for CP/M instead would have been a challenge.

Instead, the Z80 on the Softcard called 6502 routines to handle disk (and other) I/O. Usually, the 6502 is stopped when running Z80 code, but it had to be woken up frequently not only for I/O accesses, but also to ensure that the 6502 did not lose its register values, which are stored in dynamic memory cells in the (non-CMOS) 6502.

This sounds like the way the 8087 and 8089 (look that one up!) co-processors worked: they snooped the instructions the 8086/8088 CPU read from memory and then handled their own subset of the instruction set. That did require that they could reconstruct the program flow from instruction fetches, which probably became nigh impossible when CPUs started integrating instruction caches.

The DEC J-11 CPU is a single CPU that is implemented on two discrete chips with one taking care of control and the other of data paths, not exactly the same idea as using two identical cpu's to implement a different architecture, but somewhat related.

I've worked on high availability systems where CPUs were duplicated for reliability. In one product - which I won't name here - the surrounding ASICs were constructed of "self-checking logic" - where every data path had parity and all logic elements were designed such that no single wire failure could go undetected. The idea was that with near 100% reliability, a compute module could flag itself defective before recent work by it could be "committed" into the main memory which was transaction based (every segment of which also had to have at least two redundant copies in different modules).

But who will sell you a self-checking CPU? So use two of them and compare everything they do from reset. This may not be so easy with modern CPUs with huge internal clock rates - who says that they will emerge from asynchronous reset in step, for example? But with 1990s technology it was fine.

The phone switch GTD-5 had 2 separate sets of 2 CPUs for each function and instructions were run through both, then compared: https://en.wikipedia.org/wiki/GTD-5_EAX

"If the results were not identical, the processors were immediately reset, and the pair of processors on the other card were brought online as the active processor complex. The active processor always kept memory up-to-date so that when these forced switches occurred, little data loss was suffered. When the switch was requested as a part of routine maintenance, the switch could be accomplished with no data loss at all."

Do IBM Mainframes that can fail over to a second CPU running synchronously with the first count?

this used to be a thing, building up processors out of lanes: https://en.wikipedia.org/wiki/Bit_slicing

how much would be 'shared'?