New atomic MAP instructions: PHM, PLM, JMPM, JSRM, RTSM

[dansanderson]

Problem statement
A common challenge with MAP is that the code changing the MAP can't be in a region whose MAP is changing. This requires that programs take great care in locating their MAP code, such as in a reserved "dispatch" region. Setting the MAP with the MAP instruction is complex because the MAP changes immediately when the instruction is performed, but the complete operation might involve calling MAP twice or managing interrupts. You cannot set all eight bits of MAP atomically, and the mapping code must survive the intermediate state.

Another (less common) challenge is that MAP cannot be read via a CPU instruction. In cases where a program disables the KERNAL and takes over the machine, the program can usually get away with having their own fixed set of known MAP values, and tracking the program's mode separately as needed. Anything resembling an operating system, including the KERNAL, must own the MAP, and client programs cannot change the MAP without the operating system's cooperation. We have a Hyppo call to work around this, but ideally a method to read the MAP would be symmetric with the method to set the MAP.

The 45GS02's width extension to the original 4502's four-byte MAP is useful, but comes with its own hazard that any code that only sets the lower four bytes will not change the upper bytes, and may not even realize that the upper bytes are set to non-zero. Again, this would be rare for a program that does all of its own MAP manipulation from the boot state, but this is potentially relevant for operating systems.

Proposed solution
This feature request proposes new CPU instructions to manipulate MAP and PC together in an atomic fashion.

• PHM : push all eight bytes of the current MAP value to the stack
• PLM : pull an eight-byte MAP value from the stack and set MAP
• JMPM ... : set MAP and PC atomically to given values
• JSRM ... : push MAP, push PC, then set MAP and PC to given values
• RTSM : pull PC, pull MAP, then set MAP and PC to the pulled values

JMPM and JSRM have four addressing modes:

• ... Addr, ZP8 : the new PC, and a ZP address of the eight-byte MAP value
• ... (Addr), ZP8 : the address of the new PC, and a ZP address of the eight-byte MAP value
• ... Addr, Addr : the new PC, and a 16-bit address of the eight-byte MAP value
• ... (Addr), Addr : the address of the new PC, and a 16-bit address of the eight-byte MAP value

Alternatives considered
Over on #645 we're discussing adding instructions that copy four bytes of MAP into and out of Q, as an alternative to MAP/EOM and also as a way to read MAP using CPU instructions. These would act on only four bytes of MAP at a time and would not be atomic across all eight bytes.

A 10-byte operand containing both the PC and the MAP value would be unusual. My first guess is that it wouldn't be useful enough to justify the burden on both the VHDL and on assemblers to support it. The expected applications for this would want to treat MAP as either a variable (ZP) or as an entry in a table (code address), not inline with instructions.

If we want fewer new instructions, PHM, PLM, and RTSM are sufficient to implement JMPM and JSRM, similar to how it's technically possible to implement JMP and JSR with PHA and RTS. I would consider JMPM and JSRM to be advanced techniques, so maybe requiring sophisticated use of a minimal instruction set is justified in this case.

Even if we don't do JMPM, JSRM, or RTSM, I hope we continue to consider PHM / PLM due to their eight-byte atomic nature.

[gardners]

Should leverage the existing partial implementation of FAR JMP/JSR and FAR RTS, that mirror the JMPM etc semantics described above to a reasonable approximation. They work by magically banking the 2nd 16KB, and saving/restoring the relevant map info on the stack.

[hth313]

As there is flat addressing memory access, e.g. [dd] I wonder if the PC could be 24 bit address? When executing outside 64K, it could ignore MAP settings. That would make it similar to 65816.
It would allow a programming model that can addressing both data and executing code inside 64K (according to MAP settings) as well as accessing outside 64K. which is possible for data today, but not for code.

[lydon42]

I don't think that a 24bit PC is the way to go, as this would radically alter the CPU from what it is.