Protected mode and the separation of kernel and user space was only available since 80286 processors starting in 1982.
Refs:
The 68K processors did not have a concept of protected mode. It just had user mode and supervisor mode[1]
[1]: https://retrocomputing.stackexchange.com/questions/2784/how-...
https://en.wikipedia.org/wiki/VAX#Virtual_memory_map
(although paging was in pdp-11 unix too, and neither was the 1st to have memory levels)
see also:
https://svnweb.freebsd.org/base/head/share/misc/bsd-family-t...
Have a look at the architectures of the PDP-11, VAX, 68000 and many other CPUs.
When Sun (?) wanted to implement their Unix with paging on the 68000 they had a problem: If you access a memory page that has been swapped out to disk, the OS has to (1) load the page from disk to RAM and (2) let the CPU repeat the instruction that caused the memory access. But the last step could not be properly done on the 68000 because it did not store its internal state completely when an (address) error happened (this was fixed in the 68010).
Their solution: Run two 68000 in parallel on the same code, one of them delayed by one instruction. When the first CPU triggers the page fault, the system can stop the second CPU before it reaches the instruction that caused the fault.
On the other hand, this could also be used as a form of error checking. If CPU2 ever returns something different you know there was an error somewhere in the system and you can hard stop to prevent further data corruption.
I assume that the 68000 was so powerful for its price (probably much cheaper than the existing mainframe CPUs) that it made this a viable solution. Or maybe the company had promised their customers a 68k-based Unix system (with the 68451 MMU) and the 68010 was delayed or too expensive and they had to find a quick solution? (I have no idea)
Btw, I was probably wrong about Sun being the company behind this. Apollo and MassComp have been mentioned in mailing lists.
A lot of companies wanted to use them instead of the Mickey Mouse Intel chips of the day, but the price point was too severe.
The article describes a motherboard with both a soldered on 386 CPU, and a separate socket for another one. This was not a multiprocessor board, to make use of the socket you were supposed to disable the onboard CPU using a jumper.
But if you plugged in a similar enough CPU without setting the jumper, it appears that both CPUs ran at the same time. And since they had the same clock and they should have no difference in behavior, the system, at least as tested, ran fine.
CPUs act on data coming from eg the disk, memory, the network, etc. The results of instructions influences what the CPU will do next, especially so in the case of self-modifying code.
So, with a system that has a "chaser" CPU following a master CPU one instruction behind... how do you also impose a one-instruction delay on the CPU's view of the real world?!
Unless this is done, the chaser CPU is going to see real-world data and I/O that is out of sync with the instruction stream, isn't it?
I'm quite sure this problem was very elegantly solved, and I'm very curious+interested to find out what that solution was.
Elsewhere, you unfortunately sometimes have to plain emulate the instructions. VM86 mode on x86 is notorious for that; not so much when accessing memory but for all the vast privileged instructions that can trap into the monitor (e.g. CLI, IN, OUT, POPF...). VM86 Extensions ameliorated it only somewhat.
But VM86 also does not have much relevance anymore. It was a mode for running 16bit real mode software, and 64bit x86 CPUs don't support it anymore when in long mode.