3 ms·

Wow. Having pretty much ventured from 6502 directly to the 386 and later ARM, 68k was something I never really took a close look at. Was that limitation in the

by anyfoo 7y ago

Wow. Having pretty much ventured from 6502 directly to the 386 and later ARM, 68k was something I never really took a close look at. Was that limitation in the original 68000 unintentional, or did they just not design for faulting in virtual memory at page granularity? After all, you don't need to be able to restart on a page fault if you just swap in whole tasks out and back into memory just before switching to them (which you know when you're going to do), and you still get virtual memory's benefit of the swapped in tasks being able to occupy different physical, and discontiguous, memory regions without the task itself noticing. So did they only design for that, or did they actually make a mistake?

tropo 7y ago
They didn't support any MMU at all. People would add one as a separate chip, right between the CPU and the RAM, but this wasn't supported. The CPU was unaware of it. There was no way for the MMU to tell the CPU to take a recoverable fault. Sun solved this problem in an expensive way. The MMU would make the CPU wait while a second 68000 was used to process the page fault.
- anyfoo 7y ago
  Ah, your comment about them being "broken" led me to believe that some form of virtual memory was expected in the design. Now that you mention it, I recall reading that two 68000s story before (possibly from another comment you made here?), and reading it this second time, it still amazes me. Is it possible to find the source code involved? Not sure what of Sun's kernels is available.
Taniwha 7y ago
There was no builtin in MMU in early chips (68000-68020). An external MMU for the 68000/68010 did exist - a weird thing called a 68451 that mapped arbitrary power of two aligned physical blocks of memory to arbitrary power of two aligned virtual addresses (harder to use and particularly hard to allocate memory for) - it was VERY slow (7 clocks from memory) and was rumored to have been designed by a summer intern at Moto. You do need to restart instructions if you want your stack to extend automatically, there's a hack you can do to make this happen on a 68000 You could do a paging system on a 68010/68451 - you had to treat the 68451 as a software refilled TLB Sun built their own MMU using SRAM, at the time there was a guy going around the Valley designing "sun-style" MMUs, for IP reasons every one was different, some were broken (one I ported to couldn't protect the kernel from user mode). Someone (maybe Sun?) managed to get 68000s to do paging by having two of them and freezing the primary on a page fault and having the second one load the page somehow. 68020s had external MMUs, Moto made the PMMU which most people used Phillips tried to make one (it never really worked), Apple had a weird pseudo MMU that fit in a PMMU socket on the mac 2 - it emulated the 24-bit addressing on the 68000 (Apple had stupidly used the upper bits in their pointers) Finally: I think that the 68000 not being able to restart a page fault was probably a mistake, something they hadn't thought all the way through
- anyfoo 7y ago
  I've since also found a comment on an interesting blog post in which one of the original designers is quoted in saying that virtual memory was not a consideration for the 68000 initially: http://www.dadhacker.com/blog/?p=1383 http://www.dadhacker.com/blog/?p=1383 Though qualified with "until the design was almost complete", making the answer to my question (as often) much more fuzzier than I thought. And another commenter speculates it was Apollo with the two-68k implementation, but without sources and the commenter is unsure of it themselves. In any case, very interesting stuff. EDIT: Someone else claims it was Masscomp: http://www.dadhacker.com/blog/?p=1383#comment-3582 http://www.dadhacker.com/blog/?p=1383#comment-3582
  - Taniwha 7y ago
    That article kind of mixes up AT&T releases - we'd ported V7 and System 3 to the Lisa (base and bounds MMU like the original PDP-11 the ports came from), and the 68451 and Sun-style MMUs by mid '84, SVR (System 5 Release 1) didn't exist yet. SVR2 was a full paging release from AT&T (competing with BSD 4.2 by then). The '451 is more functional than his power of 2 design (because it offers multiple powers of 2 that you can cobble together into arbitrary regions) - the 'throwaway instructions' he mentions is indeed what we used for stack extensions - you do a 'tstb offset(%sp)' in every subroutine entry where 'offset' is the extent of the stack the subroutine will use, the results of the instruction aren't used and the fault can be detected - by recognizing the instruction at the fault pc offset and returning to the address following it
    - anyfoo 7y ago
      Thanks for your insights, and for clarifying (I primarily linked to the article for its comments, which seemed to contain a collection of interesting historical tidbits.) Again as someone who somehow never got to touch 68k during its day, the level of creativity required in 68000 MM, and the internal state spilling of the 68010 and later, really got me curious (x86 of course always had plenty of curious quirks, but I think I'm too familiar with them at this point %) ). I'd also still love to read more about the details of the two-68000 design, but everything I could find so far was essentially folklore.

by anyfoo 7y ago

tropo 7y ago

They didn't support any MMU at all. People would add one as a separate chip, right between the CPU and the RAM, but this wasn't supported. The CPU was unaware of it. There was no way for the MMU to tell the CPU to take a recoverable fault. Sun solved this problem in an expensive way. The MMU would make the CPU wait while a second 68000 was used to process the page fault.

anyfoo 7y ago
Ah, your comment about them being "broken" led me to believe that some form of virtual memory was expected in the design. Now that you mention it, I recall reading that two 68000s story before (possibly from another comment you made here?), and reading it this second time, it still amazes me. Is it possible to find the source code involved? Not sure what of Sun's kernels is available.

Taniwha 7y ago

There was no builtin in MMU in early chips (68000-68020). An external MMU for the 68000/68010 did exist - a weird thing called a 68451 that mapped arbitrary power of two aligned physical blocks of memory to arbitrary power of two aligned virtual addresses (harder to use and particularly hard to allocate memory for) - it was VERY slow (7 clocks from memory) and was rumored to have been designed by a summer intern at Moto. You do need to restart instructions if you want your stack to extend automatically, there's a hack you can do to make this happen on a 68000 You could do a paging system on a 68010/68451 - you had to treat the 68451 as a software refilled TLB Sun built their own MMU using SRAM, at the time there was a guy going around the Valley designing "sun-style" MMUs, for IP reasons every one was different, some were broken (one I ported to couldn't protect the kernel from user mode). Someone (maybe Sun?) managed to get 68000s to do paging by having two of them and freezing the primary on a page fault and having the second one load the page somehow. 68020s had external MMUs, Moto made the PMMU which most people used Phillips tried to make one (it never really worked), Apple had a weird pseudo MMU that fit in a PMMU socket on the mac 2 - it emulated the 24-bit addressing on the 68000 (Apple had stupidly used the upper bits in their pointers) Finally: I think that the 68000 not being able to restart a page fault was probably a mistake, something they hadn't thought all the way through

anyfoo 7y ago
I've since also found a comment on an interesting blog post in which one of the original designers is quoted in saying that virtual memory was not a consideration for the 68000 initially: http://www.dadhacker.com/blog/?p=1383 http://www.dadhacker.com/blog/?p=1383 Though qualified with "until the design was almost complete", making the answer to my question (as often) much more fuzzier than I thought. And another commenter speculates it was Apollo with the two-68k implementation, but without sources and the commenter is unsure of it themselves. In any case, very interesting stuff. EDIT: Someone else claims it was Masscomp: http://www.dadhacker.com/blog/?p=1383#comment-3582 http://www.dadhacker.com/blog/?p=1383#comment-3582
- Taniwha 7y ago
  That article kind of mixes up AT&T releases - we'd ported V7 and System 3 to the Lisa (base and bounds MMU like the original PDP-11 the ports came from), and the 68451 and Sun-style MMUs by mid '84, SVR (System 5 Release 1) didn't exist yet. SVR2 was a full paging release from AT&T (competing with BSD 4.2 by then). The '451 is more functional than his power of 2 design (because it offers multiple powers of 2 that you can cobble together into arbitrary regions) - the 'throwaway instructions' he mentions is indeed what we used for stack extensions - you do a 'tstb offset(%sp)' in every subroutine entry where 'offset' is the extent of the stack the subroutine will use, the results of the instruction aren't used and the fault can be detected - by recognizing the instruction at the fault pc offset and returning to the address following it
  - anyfoo 7y ago
    Thanks for your insights, and for clarifying (I primarily linked to the article for its comments, which seemed to contain a collection of interesting historical tidbits.) Again as someone who somehow never got to touch 68k during its day, the level of creativity required in 68000 MM, and the internal state spilling of the 68010 and later, really got me curious (x86 of course always had plenty of curious quirks, but I think I'm too familiar with them at this point %) ). I'd also still love to read more about the details of the two-68000 design, but everything I could find so far was essentially folklore.