The Macintosh, ST, and Amiga were all 68000 CPU systems released in 1984-85, along with their respective new Operating Systems. While this was 5 years before protected mode became commonplace on Intel PC (80286/80386) OS's, the 68000 had a protected mode as well (i.e. a special mode allowing the use of privileged/supervisor instructions not normally available to user code).

The Amiga Exec kernel eschewed the use of protected mode in order to provide efficient multitasking and inter-process communications. The original Mac OS and Atari TOS did not really have these features, and I think they made use of protected mode for something.

How was the protected mode used in Mac OS and TOS? What advantages did this provide?

  • 1
    Could you clarify what you mean by protected mode on the 68k? Supervisor v. user privilege levels, or something else? – Stephen Kitt Apr 26 '17 at 22:40
  • 2
    The 68030 was the first CPU in the 68k line that included an on-die MMU, making it an ideal processor for protected memory and virtualization. So any OS writer who wanted to support both the MMU and also earlier CPUs without the MMU had some extra work to do. (This may be the reason why Amiga Workbench for example does not support the MMU.) Later came the 68040 whose MMU tables were incompatible with the 68030, so any OS writer who wanted to support both MMU implementations again had some work cut out for them. (This is probably why Amiga Unix only supports the 68030.) – traal Apr 26 '17 at 23:40
  • 1
    I am pretty sure you mean Supervisor mode, because early 68k CPUs didn't have an MMU, but your question should be making it clearer. – tofro Apr 27 '17 at 7:12
  • 1
    I've edited the question to refer specifically to supervisor mode, and elide the Intel-related verbiage. – Chris Hanson Apr 27 '17 at 7:19
  • 3
    @ChrisHanson And now my answer doesn't fit the question properly anymore, thanks... – tofro Apr 27 '17 at 8:45

The (plain) 68k never had anything directly comparable to the Intel x86 range's Protected Mode. When Intel introduced the Protected mode (PM) to its x86 range of CPUs, this lifted a number of restrictions, though, that the 68k range never had:

  1. PM allowed the OS designer to protect (hence the name...) certain address ranges from access from non-privileged code, basically layering the software into privileged (OS) and non-privileged (applications) layers with certain access limitations on memory areas and certain instructions. The 68k from the very beginning supported supervisor and user modes to do a similar thing (but needing support from circuitry external to the CPU to define and impose those protected ranges). The Atari ST, for example, would execute a software trap triggered by its MMU (**) and GLUE custom chips when applications in user mode tried to access certain hardware register areas that were only allowed for Supervisor Mode code.
  2. Starting with the 386, PM provided a 32-bit linear address range to end user programs and allowed OS and applications writers to get rid of the quirky segmented architecture the original 8086 had (with "tiny", "large" and "huge" memory models and all the software quirks that came with them). The 68k never had this limitation as it provided linear 32-bit addressing from the very beginning (but see further down below (*))
  3. The 386 PM introduced a fully capable MMU and address translation between virtual, linear and physical memory addresses - The original 68000 didn't have this and relied on external circuitry to do such things. A similar capability was introduced to the Motorola CPU range with the 68010 and 68020 CPUs, until the first "full MMU" implementation followed in the 68030.

The Atari ST generally ran applications in User Mode, in order to allow memory (and I/O) protection.

The Sinclair QL's QDOS did as well, effectively switching off multitasking when in Supervisor Mode (or rather, running OS code). Thus restricting Supervisor Mode code to OS code or hardware specific code like device drivers and (obviously) interrupt service routines. This also meant that user applications had to restrict the time they spent in Supervisor Mode as much as possible, in order to not severely harm proper time-slicing. Another reason not to stay in SM for too long was the very limited resources (only 100 bytes of supervisor stack, for example) assigned to this mode by the OS.

The 68k Mac, to my knowledge, didn't actually care much about UM and SM and applications were allowed to run in Supervisor mode all the time.

PalmOS also had a strong distinction between Supervisor and User Mode, reliant on co-operative multitasking, it effectively switched off application switching in Supervisor mode in order to be able to do some of it's complicated memory management magic.

(*) The fact that the 68k range had a non-segmented architecture is only partially valid: It is true that the 68000 did have linear 32-bit addressing from the very beginning, but this was only valid for direct addressing modes - indirect (register-relative) addressing was limited to +-32k in the original 68000, this limitation was lifted only later by the 68020.

This lead to the interesting fact that some computer architectures for the 68000 (examples being MacOS 68k, QDOS for the Sinclair QL and PalmOS for Palm Handhelds) implemented a software-segmented architecture, that introduced artificial segmentation into 64k segments by only allowing register- and PC-relative addressing, which allowed them to get rid of an otherwise needed relocating loader to adapt absolute addresses in the code to the load address of the binary.

This limited intrasegment calls to +-32k and actually introduced a sort of segmentation similar to what the 8086 had, but made life for the OS writers quite a bit easier (but for applications writers more complicated). Imposing the limit of fully position-independent code and data onto applications allowed the OS to do much more effective memory management (entirely needed on early 68k Macs that were limited to 128k of memory and PalmOS devices whose main memory also had to accommodate for mass data storage). The OS could shift applications' data and code around arbitrarily and only had to adjust one single base register in the application - Much like it had a hardware MMU. Applications writers, however, had to introduce jump islands or other helpers in their code (typically done on MacOS and PalmOS) in order to be able to reach a location further than 32k away, or, as an alternative, had to resort to having a relocation loader embedded into the application, where possible (Sinclair QL).

The Amiga and the Atari ST operating systems did have a relocating loader and supported full absolute 32-bit addressing in applications programs. This did, however, mean that once an application was loaded and relocated in memory by the OS, it couldn't easily be moved. (I'm not an Amiga expert, but do believe the Amiga used register-relative addressing in libraries, though).

The Sinclair QL allowed both approaches, supporting both so-called pure and impure programs, the former fully movable in memory and allowing to run several task ("job") instances on top of the very same code, the latter supporting in-built relocating loaders.

(**) The Atari ST custom chip referred to as "MMU" here (that was the name Atari christened it) was not what we would call an MMU today. Yes, it did "manage memory", but not in the sense of virtual memory and address translation.

  • 1
    I fixed up some of the x86 PM discussion. Note that 32-bit addressing is largely orthogonal to protected mode — the default segments on 386s and later had 64K boundaries for backwards compatibility, but you can set them up to have 4G boundaries and use 32-bit addresses in real mode (“unreal mode”). Discussing x86 protection v. segmentation v. paging in detail quickly gets complicated... – Stephen Kitt Apr 27 '17 at 10:54
  • @StephenKitt I wasn't trying to explain the x86 improvements in all their glory and, especially not, with historical accuracy :) The x86 story is only of relevance here (at least to me) where it fixed important shortcomings in the initial design that were a nuisance to programmers and OS architects. But thanks for fixing anyways. – tofro Apr 27 '17 at 11:58
  • Yes, that’s why I just clarified the 286/386 stuff (and the MMU which was fully operational in the 386). – Stephen Kitt Apr 27 '17 at 12:11
  • The statement "The Atari ST generally ran applications in User Mode, in order to allow memory (and I/O) protection." sort of leaves me hanging. This sounds significant. How does this keep user programs "in check", protect the OS/hardware, and better handle user program errors? Or does it... – Brian H Apr 27 '17 at 16:23
  • 1
    @BrianH Read the other sentence "The Atari ST, for example, would execute a software trap triggered by its MMU when applications in user mode tried to access certain hardware register areas that were only allowed for Supervisor Mode code." This basically reserved direct hardware register access to the OS only (or applications that went into SM - There never was any protection against applications entering Supervisor mode). So, this only helped against software errors, not malicious users (which wouldn't make a lot of sense on a single-user system anyhow...). – tofro Apr 27 '17 at 16:26

So far as I recall, the Macintosh System Software didn't bother with the user versus supervisor mode distinction. Even after the release of System 7, which supported virtual memory, virtually everything ran in supervisor mode.

I think the Apple Lisa, which had a more minicomputer-like (or what we'd today call Unix-like) operating system design, as well as an MMU, did use supervisor for the operating system itself and user mode for application level code.

  • That's really interesting about the Lisa. I haven't seen much writing on the Lisa's OS. – Brian H Apr 27 '17 at 15:18

68000 had a protected mode as well (i.e. a special mode allowing the use of privileged/supervisor instructions not normally available to user code).

Err, no. At least don't call it protected mode, call it supervisor mode or privileged mode. "Protected mode" implies something like the >=80286 protected mode which had hardware memory protection. This did not exist with the original 68K.

The 68000 supervisor mode meant two things:

  • certain instructions were not allowed in user mode, for example enabling and disabling interrupts
  • supervisor mode had a separate stack pointer

There was no built in support for memory protection at all, and I know for a fact (bitter experience), that early TOS on the Atari treated the memory space as a single shared resource for all programs. However, the 68000 had memory mapped IO and I think I'm correct in stating that the Atari MMU (a separate chip to the 68000) stopped user mode programs from accessing memory locations used by the registers of the IO devices. But that was the limit of memory protection.

I think roughly the same rules applied to Mac OS because one of the big deals when comparing it to Windows 9x was the lack of protection for processes (or pre-emptive multitasking). Mac OS X was the first virtual memory pre-emptive multitasking OS that achieved any traction in the Mac world.

With the 68000 you could not "eschew" supervisor mode. Any hardware interrupt or software trap automatically put the processor into supervisor mode, so you always had to deal with it - even on the Commodore Amiga.

  • Mac's supported virtual memory beginning with System 7 in 1991. They used the 680x0 MMU for this feature. – Brian H Apr 28 '17 at 13:53
  • @BrianH, Macs supported virtual memory in the sense that there was a switch you could turn on to enable it. Nobody I know of actually used it except in extreme circumstances (unlike in Windows, where the use of virtual memory was routine), because performance was abysmal. – Mark Apr 28 '17 at 20:37
  • @Mark you mean Windows 9x and NT. Windows 3.x did not use virtual memory. – JeremyP Apr 29 '17 at 14:51
  • @JeremyP, it made limited use of virtual memory: it could use a swapfile to provide backing for more address space than physically existed, but it did not do other things commonly associated with virtual memory, such as memory isolation between processes. – Mark Apr 29 '17 at 19:19
  • 1
    Actually, it is the GLUE chip that prevents user mode access to certain I/O address ranges in the ST. – tofro May 10 '17 at 6:42

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.