That depends on the youngin' - the same technique was also used with the Dual Systems
Version 7 Unix port to the mc68000 without an MMU in 1981: split the address space in half
at 0x800000, top for kernel, bottom for running process, swap to context switch, and any
reference to RAM below 0x800000 while in CPU user mode faulted, to protect the kernel from
errant user code.
I can also tell you some S-100 (IEEE-696) device driver horror stories because CP/M-68k
and its ilk were not multitasking like Unix and let us say that allowed the S-100 add-in
board hardware designers to be ... lazy. The work-arounds in software were very ugly.
Main irritant: customers who claimed our hardware was broken because dereferencing a NULL
pointer (0) resulted in a fault, rather than returning 0. "No, your C code is broken
because address zero is not in the available address space of processes, and your code
should not assume it is." (not a popular response from our customer service
engineer). IIRC, most of the Unix code was well-behaved because it had grown up on
computers with MMUs by the time we got it ... except for that issue.
Later, Dual produced a CPU board with an mc68451 MMU on it, and that helped. Sort of.
Erik Fair