#lazyweb Is it correct to say that the 68000 and 68008 only have atomic load/stores of 16-bit and 8-bits respectively*?
* Unlike most CPUs, an interrupt will pause the current instruction and continue from where it left off. But I haven't read the patent or RE'd microcode. So not clear to me if 68000 will wait to honor an interrupt until after an up-to-32-bit load/store completes.
@dalias This is correct for most CPUs; the 68k saves enough of its internal state to the stack on interrupt to continue in the middle of an instruction. It's in the patent, supposedly*.
* Which, I did not read, and I've heard conflicting info over the years as to whether the patent correctly describes all the saved state.
@dalias I could do the same thing with Sentinel. I would have to constantly check for interrupts each microinstruction (3-way or n-way jump in many cases), and if found, divert to a routine to save the microprogram counter to the stack, and a few other state bits.
It would help with interrupt latency in Sentinel a bit, but the extra hardware and microprogram required is Not Worth The Savings.
Also, I don't think RISC-V allows you to use the stack as a private data :D.
@cr1901 I'm familiar with "68k" as the mmu-ful models 68020 (I think I got that right) and up, which almost certainly don't do this because it's a behavior not very compatible with a multitasking privilege-domain-separated operating system. It can be made to work, but it's not pretty, and I never noticed any Linux code to work around that.
If you do have to deal with it on mmu-less, the reasonable thing to do would probably be to insert a breakpoint instruction at the next instruction boundary and immediately return from the interrupt. This would give you atomicity at instruction granularity whenever your interrupt handling code's body actually runs.
@dalias 68010 is demand-paging compatible as well, and has the "save current uprogram context to stack" behavior as well. The original 68000 had a bug where a page fault _specifically_ didn't properly save/restore uprogram context. So you could use virtual memory for protection, but no demand-paging. Sounds reasonable that this behavior was gone by the '20 tho.
68000 bugs aside, you can pin atomic load/store width to data bus size (16 bits) to get some level of atomic load/store.
@dalias > it's a behavior not very compatible with a multitasking privilege-domain-separated operating system
From a performance perspective, yes, this seems to be quite a disaster. But if you save the uprogram state as part of a context switch and pin atomic width to data-bus size (data bus is 8 or 16 bits, but a single insn can operate on 32 bits), what other fundamental correctness issues can you think of for multitasking OSes?
@dalias https://www.bitsavers.org/components/motorola/68000/68000/MC68451_Memory_Management_Unit_Apr83.pdf
What Motorola calls "virtual memory" I call demand paging. See 6.3 VIRTUAL MEMORY SUPPORT, where AFAICT, Motorola is describing "demand paging" but calling it "virtual memory".
Virtual memory without demand-paging is a fancy protection unit, correct? I think that was how 68451 was used for 68000 systems.
William D. Jones
Cassandrich