Discussion on answer by Raffzahn: How did the "Programmer's Switch" work on early Macintosh Computers?

Feeds

17:42

27

A: How did the "Programmer's Switch" work on early Macintosh Computers?

The early Apple Macintosh computers (original Mac, Mac 512K, Mac Plus) all came with a "Programmer's Switch" installed on the side. Yes and no. While the switch was there, it was on the inside, so, not really accessible. Only after being 'enhanced' with the so called 'Programmers Key Aid', a sn...

njuffa

Not everyone may be aware that NMI = non-maskable interrupt.

Raffzahn

@njuffa done...

PoC

There's no such thing like real mode on 68k CPUs. Please don't confuse the INTeL protected mode with memory protection. See the appropriate Wikipedia articles for details.

Martin Ueding

”Serious, who would deliver the source code of an application?“: Well, applications written in JavaScript or Python are delivered as source code and only interpreted during running. And many desktop applications are JavaScript based these days (Spotify, Signal, Slack, …)

Martin Rosenau

@PoC 68000 CPUs have a User mode and a Supervisor mode. And there were systems where some memory ranges where protected from User access. You might use the x86 terminology ("Real Mode" / "Protected Mode") to distinguish between systems using protection features and systems not using them.

Raffzahn

17:42

@PoC The term real mode is older than 68k or Intel. And its counter part isn't protected mode but virtual mode, as that is what it's about, (not) using virtual addressing. 68k CPUs do as well allow virtual addressing, don't they? Also, have you noted that I didn't mention the CPU, but talked about the OS? An important detail. MacOS is a real mode OS, which means it provides a one address space for all applications (including it self). That behaviour was the same independent if CPU (or machine) was capable of virtual addressing or not.

@MartinRosenau Let me just check how many Java Script there was in the age of Mac Plus ... nope couldn't find any :) On a more serious side, did you notice the term Brian used? "assembly source code" so again, how many Applications delivering their Assembly source have you seen for the Mac?

chepner

@Raffzahn I assume the OP means "machine source code", which is often confused with, but distinct from, assembly code that is assembled into machine code. Nothing has ever prevented people from looking at machine code, which necessarily has to be readable to be used. Decoding it into something human-comprehensible has always been the hard part, typically harder than is worth doing.

Martin Rosenau

@Raffzahn I don't know why even the 68008 (the lowest-level 68k) had a User mode with limited access rights (malware from the Internet is definitely not the reason), but it is fact that the 68ks had such an operating mode. Virtual memory was possible, but at least the earlier 68ks (68000, 68010) required an additional circuit for this. I didn't notice the term "assembly source code" but I think that the OP actually meant "machine code".

Raffzahn

@chepner Usually I do assume people know what they are writing and Brian isn't exactly a newcommer :)) And yes, you're right, there is no ultimate way to stop disassembling. still, it can be made hard, very hard - and modern OS designer waste ...err... invest a lot of brain power to do so.

@MartinRosenau well, without any doubt it was for compatibility. No need to make software that uses it not run on a 68008. Beside that, I always preferred CPUs with a supervisor mode. Doesn't have to have fancy register configurations, just the simple pact of having it and being able to invoke it due some external interrupt helped a lot in making systems stable - having some instructions trap added to it. And yes, I'm aware that a plain 68,000 needs an MMU - as well as later versions did provide one, and they have been used in Macs providing that switch, having MiniBug and running classic OS.

user253751

50 Newtons is a lot of force, are you sure it took that? Think of the force it takes to lift 5 kg, but then imagine concentrating all that force onto one little button. I'd be worried about knocking my computer over.

Martin Rosenau

@Raffzahn Actually, with "event the 68008" I didn't mean the 68008, but CPUs featuring a Supervisor mode in general: Obviously, there already was some use-case for memory protection in the 1970s...

Raffzahn

17:42

@user253751 true, that was supposed to read 5N (0,5 kg). These are pushbuttons with an intended counter force, not one used for keyboards which range around 0.5N). Noone wants the have Reset or NMI pressed without intend.

@MartinRosenau Having a supervisor mode is an easy way to separate OS and user application without the need of lots of hardware as virtual addressing needs. All needed is a defined way to switch between modes (interrupt) and to signal that to external (Bus Status), which can protect some memory (like vectors) against overwriting in user mode and maybe as well OS-RAM (a common way was to use A23). Needs only a few TTL and adds much stability. Things like user/supervisor stack are already luxury items. One can do without. Ofc, having them and things like a second register set speeds up execution

supercat

@MartinRosenau: If a machine has a user mode that uses a separate stack pointer from supervisor mode, prevents code from disabling interrupts, and performs memory accesses in a way that hardware can recognize as different from supervisor mode, the hardware necessary to sandbox user-mode code so it can't disrupt overall system operation may be simple enough to fit in a single quad-nand-gate chip, which is just about the cheapest logic chip one can buy. A lot of protection at very little cost.

@Raffzahn: The separation of the user/supervisor stack pointer is hardly a luxury. It is absolutely required to make supervisor mode offer any real protection. If an interrupt happens, the current program counter will be stacked using a supervisor-mode memory access. If user-mode code could set the stack pointer to be used for that, it could cause any arbitrary location in the supervisor's address space to be clobbered the next time an interrupt occurs.

user253751

@supercat it's optional on systems that have some other way to handle the conflict, like blocking recursive interrupts

supercat

@user253751: If a processor can internally latch state and transfer control to a supervisor-mode interrupt handler without having to write anything to the stack first, then an implementation could get by without any kind of hardware stack pointer (which is how the ARM7-TDMI worked) but if hardware is going to push data to the stack before an interrupt handler takes control, user code must not be allowed control over where that goes.

Raffzahn

@supercat Only if the supervisor state is already signalled before the return address is pushed. Beside being a philosophical question I would consider doing a user operation (which pushing the user PC at time of an interrupt is) not part of the supervisor mode portion an interrupt, that only starts after pushing address and status, when the vector is fetched and execution switched. So, no need for a supervisor stack pointer to be found here.

supercat

@Raffzahn: Perhaps it may be possible to arrange things so one could get by with a single stack pointer, such as by having interrupts that occur within user mode switch to supervisor mode but dispatch through a separate vector table than the one used for interrupts that occur within supervisor mode, thus allowing the user-mode interrupts to exit via "return to supervisor mode" instruction, but such techniques would be both more expensive and harder to work with than simply having two stack pointers.

Raffzahn

17:42

@supercat Erm, i do not know how to describe it more directthan Ialready did. A (hardware supplied) supervisor stack pointer may be hand (which is up to everyones opinion), but is not needed at all. Further is there no use for a second vector table. The vector table only needs to be protected from user mode writes (like all of OS data/code). After all, changing vectors is an OS function, no need for user access. Security can be implemented on a pretty low gate budget.

supercat

@Raffzahn: If an interrupt might be invoked from within either user or supervisor mode, the interrupt handler will need to know whether to return in user mode or supervisor mode. If a user-mode interrupt would push the status at user mode address $00123456, but a supervisor-mode interrupt would push the status at supervisor mode address $00123456, the pushed status would be useless for determining which mode to return to, since retrieving it would require that the processor know whether to fetch from user address $00123456 or supervisor address $00123456.

@Raffzahn: I guess one could get by with a single stack pointer, without needing lots of extra logic, if the upper bits of the stack pointer were treated as read-only in user mode, but for that to really be useful, different applications would need to treat different numbers of bits as read-only, which would get almost as expensive as simply having two stack pointers.

Raffzahn

@supercat I guess I see your problem here. you assume different address spaces. That was never implied. This is not about virtualization. Single address space for user and supervisor like one residing in $000000...7FFFFF the other in $800000...FFFFFF. All needed as address control is an AND gate between supervisor mode output and A23. With Supervisor mode set, all addresses can be generated, with cleared, only half is writeable (the user address space), the other half will initiate a privilege fault asuser has not to write OS. Set allows to write all memory - as OS ofc, may write anywere :)

PoC

@Raffzahn: Wikipedia explains real mode solely in terms of x86. My experience shows common understanding of "real mode" within the computing community is usually the association with x86 architecture. In addition, I can't see proof of your claim. :-) I'm not talking about similar terms like problem/supervisor mode/state, but exactly about "real mode". To me, this is clearly an x86 term.

@Martin Rosenau: Real/Protected Mode of x86 has more differences than "just" memory protection between processor states (user/supervisor mode). One notable example is segmented addressing. Maybe you want to read about real mode in the Wikipedia? ;-)

Raffzahn

@PoC Except that that term since way before Intel even made the 8086, not to mention any later CPU offering various kinds of enhancements.Its usage stems from the time the IBM /370 line offered virtual addressing and was used to describe operating systems modes between DOS as a real mode OS and DOS/VS or MVS which used virtual addressing. And that meaning hasn't changed. And it doesn't matter if it's abotut a /370, and 68k or a 386. I wouldn'T argue about your knowledge is maybe rather recent and restricted to use within an x86 environment. It's still only part of a bigger picture.

supercat

@Raffzahn: I'm not "assuming" different address spaces, but rather allowing for the possibility. For example, a minimal sandbox-protection approach on a 68000 system with 40K of RAM could simply pass A22 through an AND gate with FC2, and map addresses where A23:A22 are 00 to ROM, 01 to I/O, 10 to 8K of RAM, and 11 to 32K of RAM. Further, even if all addresses are the same, it's unclear what should happen if an interrupt occurs when the stack pointer points to a location which would be valid in supervisor space but not user space, and the value that happens to be there in supervisor space...

...would appear to represent valid information about what the processor would have been doing if it was in supervisor mode. I don't see any way of making a system robust against user code that sets an invalid SP value unless it includes a way of dispatching to a double-fault handler while keeping track of the cause of the first fault in a way that doesn't require a valid stack pointer, and any hardware approaches I see for that would be more complicated than providing a second stack pointer (though I suppose the 68000 could have simply made A7 inaccessible user mode).

Transcript for

Discussion on answer by Raffzahn: How…