17

The Sun-1 was Sun Microsystems' first Unix workstation. As described in its Wikipedia article, it had a Motorola MC68000 processor and a custom memory management unit:

The Sun-1 MMU was necessary because the Motorola 68451 MMU did not always work correctly with the 68000 and could not always restore the processor state after a page fault.

Exception handling that could restart an instruction did not appear in the M68k family until the MC68010. So how was the Sun-1 able to recover from virtual memory page faults?

DrSheldon
  • 15,979
  • 5
  • 49
  • 113
  • 6
    Didn't it have a second 68000 for that purpose? – Patrick Schlüter Jun 27 '22 at 05:32
  • 2
    The answer is contained here https://retrocomputing.stackexchange.com/a/24729/4692 (search for 'two 68000') – lvd Jun 27 '22 at 08:20
  • 6
    While other 68k workstations did use two 68ks, I’m not sure the Sun-1 did. The architecture paper says “The original 68000 processor cannot fully recover from page faults because it does not save sufficient state information to continue an aborted instruction. However, for a limited set of operations, such as load and store, recovery from aborted instructions is straightforward. With additional software assistance, recovery from more complex addressing modes appears feasible.” – Stephen Kitt Jun 27 '22 at 08:26
  • 1
    See also the Sun 68000 Board User’s Manual. – Stephen Kitt Jun 27 '22 at 08:33
  • 3
    And judging from "The Sun memory management provides all the necessary mechanism for demand paging and virtual memory and will be fully compatible with the 68010 virtual memory processor when it becomes available.", and the fact that you can retrofit a Sun-1 with an 68010 (Model 100U), maybe they just made do with the 68000 until the 68010 was available, and avoided the more complex instructions in earlier code. And a custom-built MMU may have been chosen for other reasons (2-level translation instead of what the 68451 does). – dirkt Jun 27 '22 at 09:28
  • 2
    @StephenKitt: I suspect that if OS documentation were to specify that all 32-bit operations must be 32-bit aligned, and that the OS makes no attempt to correctly handle 32-bit operations that cross page boundaries, hardware to record the address of the first word of a faulting instruction might be sufficient to allow OS software to take care of all other related cases. – supercat Jun 27 '22 at 17:41
  • 1
    Did the earliest SunOS even implement virtual memory? – John Doty Jun 28 '22 at 11:40
  • 1
    @JohnDoty that’s a good point, virtual memory was introduced in SunOS 4, which never supported 68000-based Sun-1s. But page faults are used for more than virtual memory in the SunOS 4 sense. – Stephen Kitt Jun 28 '22 at 19:47
  • @StephenKitt The Unisoft Unix that Callan and Pacific used on Stanford hardware would signal bus and segmentation violations, but, of course, those aren't generally recoverable. – John Doty Jun 28 '22 at 21:12
  • @JohnDoty indeed, and UniSoft Unix is also pretty much what the Sun-1 used. – Stephen Kitt Jun 29 '22 at 13:45

2 Answers2

23

I haven't looked at the relevant versions of SunOS, so I can't say for sure which method they chose, but I'm aware of three methods for dealing with this problem.

The first method uses two CPUs. You basically run one CPU one instruction behind the other. When the leader encounters a page fault, you halt the follower, handle the page fault, then unhalt the second to execute the instruction that caused the fault (and the former lead now becomes the follower).

The second method is based on the observation that the instructions that cause problems are those that use autoincrement or autodecrement addressing. So you simply write your compiler to never generate instructions that use autoincrement/autodecrement addressing. As @supercat points out, there may be a few other restrictions, but the basic idea remains: just avoid generating instructions that cause problems.

The third method is to have your fault handler disassemble the faulting instruction, check whether it used autoincrement/autodecrement addressing, and if so adjust the appropriate register to undo the state change that had already happened from the partially executed instruction.

In both the second and third methods, after you've handled the fault, you restart execution starting from the instruction that faulted.

Apollo used the first (dual CPU) method. But to my knowledge, they were the only ones to do so (and I seem to recall their having gotten a patent on it, so it's particularly doubtful that anybody else did it).

Apple used the second method in the LISA. If you (for example) used a third party assembler to generate autodecrement/autoincrement instructions on your own...well, you were on your own.

I think Sun used the third implementation, but as I said up front, I'm not certain of that. But also note that the difference between the second and third is entirely in software, so it's possible to switch between them without changing hardware.

One final note: the third method (and to a lesser extent, the second) does depend on behavior I'm reasonably certain Motorola didn't actually document. So you needed to start by testing the processor to be sure what it was doing, and act accordingly. And basically anytime Motorola did even the slightest update, you needed to rerun acceptance tests, since you were depending on behavior they didn't guarantee (but as far as I know, they didn't actually change).

Jerry Coffin
  • 4,842
  • 16
  • 24
  • Another requirement would be that software never access a 32-bit value that's split across a page boundary. The 68000 documented that 32-bit values could be loaded or stored from half-word boundaries, and supporting software that did this in page-crossing scenarios was a major complication. If a fault stores the address of the faulted instruction, rather than the instruction following, I don't think identifying the bit patterns associated with pre/post-increment addressing be that hard. I think much of the complexity of the 68010 was its ability to handle page faults on split writes. – supercat Jun 27 '22 at 20:32
  • @supercat: for the 68010 that was clearly a consideration. But for Sun, I'd guess it simply didn't arise--they probably just never generated code to allocate a 32-bit word crossing a page boundary in the first place (and Apple probably didn't either). – Jerry Coffin Jun 27 '22 at 20:49
  • Surely it's not realistic completely to avoid autoincrement/decrement addressing, as per JSR, RTS, etc? – Tommy Jun 27 '22 at 22:49
  • 1
    Completely? Probably not. That pair, at least, can be dealt with by always keeping the stack in physical memory. And obviously you can do that use them in any other code that addresses only physical memory as well. – Jerry Coffin Jun 27 '22 at 22:59
1

The original Stanford University Network computer design used a 68000. Several companies (Callan, Pacific Microcomputers, SUN, maybe others) marketed computers based on the Stanford design. I used computers from all three of the ones above.

I don't know about the earliest SUN but the other two used the 68000 and did not implement virtual memory. My experience with SUN started a couple of years later. By that time they were using the 68010.

John Doty
  • 2,344
  • 6
  • 12