Interrupts in 65xx processors

From Wikipedia, the free encyclopedia
(Redirected from BRK)
Jump to navigation Jump to search

Script error: No such module "redirect hatnote". The 65xx family of microprocessors, consisting of the MOS Technology 6502 and its derivatives, the WDC 65C02, WDC 65C802 and WDC 65C816, and CSG 65CE02, all handle interrupts in a similar fashion. There are three hardware interrupt signals common to all 65xx processors and one software interrupt, the <templatestyles src="Mono/styles.css" />BRK instruction. The WDC 65C816 adds a fourth hardware interrupt—<templatestyles src="Mono/styles.css" />ABORT, useful for implementing virtual memory architectures—and the <templatestyles src="Mono/styles.css" />COP software interrupt instruction (also present in the 65C802), intended for use in a system with a coprocessor of some type (e.g., a floating-point processor).[1][2]

Interrupt types

65xx interrupt vector locations[2][3]
Interrupt Vector (hexadecimal)
LSB MSB
<templatestyles src="Mono/styles.css" />IRQ/<templatestyles src="Mono/styles.css" />BRK FFFE FFFF
<templatestyles src="Mono/styles.css" />RESET FFFC FFFD
<templatestyles src="Mono/styles.css" />NMI FFFA FFFB
<templatestyles src="Mono/styles.css" />ABORTTemplate:Refn FFF8 FFF9
<templatestyles src="Mono/styles.css" />COPTemplate:Refn FFF4 FFF5

The hardware interrupt signals are all active low, and are as follows:[1]

RESET
a reset signal, level-triggered
NMI
a non-maskable interrupt, edge-triggered
IRQ
a maskable interrupt, level-triggered
ABORT
a special-purpose, non-maskable interrupt (65C816 only, see below), level-triggered

The detection of a <templatestyles src="Mono/styles.css" />RESET signal causes the processor to enter a system initialization period of six clock cycles, after which it sets the interrupt request disable flag in the status register and loads the program counter with the values stored at the processor initialization vector (<templatestyles src="Mono/styles.css" />$00FFFC–<templatestyles src="Mono/styles.css" />$00FFFD) before commencing execution.[1] If operating in native mode, the 65C816/65C802 are switched back to emulation mode and stay there until returned to native mode under software control.

65C816/65C802 native mode interrupt vector locations[2]
Interrupt Vector (hexadecimal)
LSB MSB
<templatestyles src="Mono/styles.css" />IRQ 00FFEE 00FFEF
<templatestyles src="Mono/styles.css" />RESET NoneTemplate:Refn
<templatestyles src="Mono/styles.css" />NMI 00FFEA 00FFEB
<templatestyles src="Mono/styles.css" />ABORT[nb 1] 00FFE8 00FFE9
<templatestyles src="Mono/styles.css" />BRK 00FFE6 00FFE7
<templatestyles src="Mono/styles.css" />COP[nb 2] 00FFE4 00FFE5

The detection of an <templatestyles src="Mono/styles.css" />NMI or <templatestyles src="Mono/styles.css" />IRQ signal, as well as the execution of a <templatestyles src="Mono/styles.css" />BRK instruction, will cause the same overall sequence of events, which are, in order:[1][3]

  1. The processor completes the current instruction and updates registers or memory as required before responding to the interrupt.
  2. 65C816/65C802 when operating in native mode: The program bank register (<templatestyles src="Mono/styles.css" />PB, the <templatestyles src="Mono/styles.css" />A16-A23 part of the address bus) is pushed onto the hardware stack.
  3. The most significant byte (MSB) of the program counter (<templatestyles src="Mono/styles.css" />PC) is pushed onto the stack.
  4. The least significant byte (LSB) of the program counter is pushed onto the stack.
  5. The status register (<templatestyles src="Mono/styles.css" />SR) is pushed onto the stack.
  6. The interrupt disable flag is set in the status register.
  7. 65C816/65C802: <templatestyles src="Mono/styles.css" />PB is loaded with <templatestyles src="Mono/styles.css" />$00.
  8. <templatestyles src="Mono/styles.css" />PC is loaded from the relevant vector (see tables).

The behavior of the 65C816 when <templatestyles src="Mono/styles.css" />ABORT is asserted differs in some respects from the above description and is separately discussed below.

Note that the processor does not push the accumulator and index registers on to the stack—code in the interrupt handler must perform that task, as well as restore the registers at the termination of interrupt processing, as necessary. Also note that the vector for <templatestyles src="Mono/styles.css" />IRQ is the same as that for <templatestyles src="Mono/styles.css" />BRK in all eight bit 65xx processors, as well as in the 65C802/65C816 when operating in emulation mode. When operating in native mode, the 65C802/65C816 provide separate vectors for <templatestyles src="Mono/styles.css" />IRQ and <templatestyles src="Mono/styles.css" />BRK.[4]

When set, the interrupt request disable flag (the <templatestyles src="Mono/styles.css" />I bit in the status register) will disable detection of the <templatestyles src="Mono/styles.css" />IRQ signal, but will have no effect on any other interrupts (however, see below section on the <templatestyles src="Mono/styles.css" />WAI instruction implemented in WDC CMOS processors). Additionally, with the 65(c)02 or the 65C816/65C802 operating in emulation mode, the copy of the status register that is pushed on to the stack will have the <templatestyles src="Mono/styles.css" />B flag set if a <templatestyles src="Mono/styles.css" />BRK (software interrupt) was the cause of the interrupt, or cleared if an <templatestyles src="Mono/styles.css" />IRQ was the cause.Template:Refn Hence the interrupt service routine must retrieve a copy of the saved status register from where it was pushed onto the stack and check the status of the <templatestyles src="Mono/styles.css" />B flag in order to distinguish between an <templatestyles src="Mono/styles.css" />IRQ and a <templatestyles src="Mono/styles.css" />BRK.[1][2][4] This requirement is eliminated when operating the 65C802/65C816 in native mode, due to the separate vectors for the two interrupt types.[2]

<templatestyles src="Mono/styles.css" />ABORT interrupt

The 65C816's <templatestyles src="Mono/styles.css" />ABORTB interrupt input is intended to provide the means to redirect program execution when a hardware exception is detected, such as a page fault or a memory access violation. Hence the processor's response when the <templatestyles src="Mono/styles.css" />ABORTB input is asserted (negated) is different from when <templatestyles src="Mono/styles.css" />IRQB and/or <templatestyles src="Mono/styles.css" />NMIB are asserted. Also, achieving correct operation in response to <templatestyles src="Mono/styles.css" />ABORTB requires that the interrupt occur at the proper time during the machine cycle, whereas no such requirement exists for <templatestyles src="Mono/styles.css" />IRQB or <templatestyles src="Mono/styles.css" />NMIB.

When <templatestyles src="Mono/styles.css" />ABORTB is asserted during a valid memory cycle, that is, when the processor has asserted the <templatestyles src="Mono/styles.css" />VDA and/or <templatestyles src="Mono/styles.css" />VPA status outputs, the following sequence of events will occur:[2]

  1. The processor completes the current instruction but does not change the registers or memory in any way—the computational results of the completed instruction are discarded. An abort interrupt does not literally abort an instruction.[2]
  2. The program bank (<templatestyles src="Mono/styles.css" />PB, see above) is pushed to the stack.
  3. The most significant byte (MSB) of the aborted instruction's address is pushed onto the stack.
  4. The least significant byte (LSB) of the aborted instruction's address is pushed onto the stack.
  5. The status register is pushed onto the stack.
  6. The interrupt disable flag is set in the status register.
  7. <templatestyles src="Mono/styles.css" />PB is loaded with <templatestyles src="Mono/styles.css" />$00.
  8. The program counter is loaded from the <templatestyles src="Mono/styles.css" />ABORT vector (see tables).

As the address pushed to the stack is that of the aborted instruction rather than the contents of the program counter, executing an <templatestyles src="Mono/styles.css" />RTI (ReTurn from Interrupt) following an <templatestyles src="Mono/styles.css" />ABORT interrupt will cause the processor to return to the aborted instruction, rather than the next instruction, as would be the case with the other interrupts.

In order for the processor to correctly respond to an abort, system logic must assert (negate) the <templatestyles src="Mono/styles.css" />ABORTB input as soon as a valid address has been placed on the bus and it has been determined that the address constitutes a page fault, memory access violation or other anomaly (e.g., attempted execution of a privileged instruction). Hence the logic must not assert <templatestyles src="Mono/styles.css" />ABORTB until the processor has asserted the <templatestyles src="Mono/styles.css" />VDA or <templatestyles src="Mono/styles.css" />VPA signals. Also, <templatestyles src="Mono/styles.css" />ABORTB must remain asserted until the fall of the phase-two clock and then be immediately released. If these timing constraints are not observed, the abort interrupt handler itself may be aborted, causing registers and/or memory to be changed in a possibly-undefined manner.[2]

Interrupt anomalies

In the NMOS 6502 and derivatives (e.g., 6510), the simultaneous assertion of a hardware interrupt line and execution of <templatestyles src="Mono/styles.css" />BRK was not accounted for in the design—the <templatestyles src="Mono/styles.css" />BRK instruction will be ignored in such a case. Also, the status of the decimal mode flag in the processor status register is unchanged following an interrupt of any kind. This behavior can potentially result in a difficult to locate bug in the interrupt handler if decimal mode happens to be enabled at the time of an interrupt. These anomalies were corrected in all CMOS versions of the processor.[2]

Interrupt handler considerations

A well-designed and succinct interrupt handler or interrupt service routine (ISR) will not only expeditiously service any event that causes an interrupt, it will do so without interfering in any way with the interrupted foreground task—the ISR must be "transparent" to the interrupted task (although exceptions may apply in specialized cases). This means that the ISR must preserve the microprocessor (MPU) state and not disturb anything in memory that it is not supposed to disturb. Additionally, the ISR should be fully reentrant, meaning that if two interrupts arrive in close succession, the ISR will be able to resume processing the first interrupt after the second one has been serviced. Reentrancy is typically achieved by using only the MPU hardware stack for storage (though there are other possible methods).

Preserving the MPU state means that the ISR must assure that whatever values were in the MPU registers at the time of the interrupt are there when the ISR terminates. A part of the preservation process is automatically handled by the MPU when it acknowledges the interrupt, as it will push the program counter (and program bank in the 65C816/65C802) and status register to the stack prior to executing the ISR. At the completion of the ISR, when the <templatestyles src="Mono/styles.css" />RTI instruction is executed, the MPU will reverse the process. No member of the 65xx family pushes any other registers to the stack.[2]

In most ISRs, the accumulator and/or index registers must be preserved to assure transparency and later restored as the final steps prior to executing <templatestyles src="Mono/styles.css" />RTI. In the case of the 65C816/65C802, consideration must be given to whether it is being operated in emulation or native mode at the time of the interrupt. If the latter, it may also be necessary to preserve the data bank (<templatestyles src="Mono/styles.css" />DB) and direct (zero) page (<templatestyles src="Mono/styles.css" />DP) registers to guarantee transparency. Also, a 65C816 native mode operating system may well use a different stack location than the application software, which means the ISR would have to preserve and subsequently restore the stack pointer (<templatestyles src="Mono/styles.css" />SP). Further complicating matters with the 65C816/65C802 is that the sizes of the accumulator and index registers may be either 8 or 16 bits when operating in native mode, requiring that their sizes be preserved for later restoration.[2]

The methods by which the MPU state is preserved and restored within an ISR will vary with the different versions of the 65xx family. For NMOS processors (e.g., 6502, 6510, 8502, etc.), there can be only one method by which the accumulator and index registers are preserved, as only the accumulator can be pushed to and pulled from the stack.[5] Therefore, the following ISR entry code is typical:

        PHA                     ; save accumulator
        TXA
        PHA                     ; save X-register
        TYA
        PHA                     ; save Y-register
        CLD                     ; ensure binary mode by clearing decimal flag

The <templatestyles src="Mono/styles.css" />CLD instruction is necessary because, as previously noted, NMOS versions of the 6502 do not clear the <templatestyles src="Mono/styles.css" />D (decimal mode) flag in the status register when an interrupt occurs.

Once the accumulator and index registers have been preserved, the ISR can use them as needed. When the ISR has concluded its work, it would restore the registers and then resume the interrupted foreground task. Again, the following NMOS code is typical:

        PLA
        TAY                     ; restore Y-register
        PLA
        TAX                     ; restore X-register
        PLA                     ; restore accumulator
        RTI                     ; resume interrupted task

A consequence of the <templatestyles src="Mono/styles.css" />RTI instruction is the MPU will return to decimal mode if that was its state at the time of the interrupt.[5]

The 65C02, and the 65C816/65C802 when operating in emulation mode, require less code, as they are able to push and pull the index registers without using the accumulator as an intermediary.[2] They also automatically clear decimal mode before executing the ISR.[2] The following is typical:

        PHA                     ; save accumulator
        PHX                     ; save X-register
        PHY                     ; save Y-register

Upon finishing up, the ISR would reverse the process:

        PLY                     ; restore Y-register
        PLX                     ; restore X-register
        PLA                     ; restore accumulator
        RTI                     ; resume interrupted task

As previously stated, there is a little more complexity with the 65C816/65C802 when operating in native mode due to the variable register sizes and the necessity of accounting for the <templatestyles src="Mono/styles.css" />DB and <templatestyles src="Mono/styles.css" />DP registers. In the case of the index registers, they may be pushed without regard to their sizes, as changing sizes automatically sets the most significant byte (MSB) in these registers to zero and no data will be lost when the pushed value is restored, provided the index registers are the same size they were when pushed.[2]

The accumulator, however, is really two registers: designated <templatestyles src="Mono/styles.css" />.A and <templatestyles src="Mono/styles.css" />.B.[2] Pushing the accumulator when it is set to 8 bits will not preserve <templatestyles src="Mono/styles.css" />.B,[2] which could result in a loss of transparency should the ISR change <templatestyles src="Mono/styles.css" />.B in any way. Therefore, the accumulator must always be set to 16 bits before being pushed or pulled if the ISR will be using <templatestyles src="Mono/styles.css" />.B. It is also more efficient to set the index registers to 16 bits before pushing them. Otherwise, the ISR has to then push an extra copy of the status register so it can restore the register sizes prior to pulling them from the stack.

For most ISRs, the following entry code will achieve the goal of transparency:

        PHB                     ; save current data bank
        PHD                     ; save direct page pointer
        REP #%00110000          ; select 16 bit registers
        PHA                     ; save accumulator
        PHX                     ; save X-register
        PHY                     ; save Y-register

In the above code fragment, the symbol <templatestyles src="Mono/styles.css" />% is MOS Technology and WDC standard assembly language syntax for a bitwise operand.

If the ISR has its own assigned stack location, preservation of the stack pointer (<templatestyles src="Mono/styles.css" />SP) must occur in memory after the above pushes have occurred—it should be apparent why this is so. The following code, added to the above sequence, would handle this requirement:

        TSC                     ; copy stack pointer to accumulator
        STA stkptr              ; save somewhere in safe RAM
        LDA isrptr              ; get ISR's stack pointer &...
        TCS                     ; set new stack location

At the completion of the ISR, the above processes would be reversed as follows:

        REP #%00110000          ; select 16 bit registers
        TSC                     ; save ISR's SP...
        STA isrptr              ; for subsequent use
        LDA isstkptr            ; get foreground task's SP &...
        TCS                     ; set it
        PLY                     ; restore Y-register
        PLX                     ; restore X-register
        PLA                     ; restore accumulator
        PLD                     ; restore direct page pointer
        PLB                     ; restore current data bank
        RTI                     ; resume interrupted task

Note that upon executing <templatestyles src="Mono/styles.css" />RTI, the 65C816/65C802 will automatically restore the register sizes to what they were when the interrupt occurred, since pulling the previously–saved status register sets or clears both register size bits to what they were at the time of the interrupt.[2]

While it is possible to switch the 65C816/65C802 from native mode to emulation mode within an ISR, such is fraught with peril.[2] In addition to forcing the accumulator and index registers to 8 bits (causing a loss of the most significant byte in the index registers), entering emulation mode will truncate the stack pointer to 8 bits and relocate the stack itself to page 1 RAM.[2] The result is the stack that existed at the time of the interrupt will be inaccessible unless it was also in page 1 RAM and no larger than 256 bytes. In general, mode switching while servicing an interrupt is not a recommended procedure, but may be necessary in specific operating environments.

Using <templatestyles src="Mono/styles.css" />BRK and <templatestyles src="Mono/styles.css" />COP

As previously noted, <templatestyles src="Mono/styles.css" />BRK and <templatestyles src="Mono/styles.css" />COP are software interrupts and, as such, may be used in a variety of ways to implement system functions.

A historical use of <templatestyles src="Mono/styles.css" />BRK has been to assist in patching PROMs when bugs were discovered in a system's firmware. A typical technique in firmware development was to arrange for the <templatestyles src="Mono/styles.css" />BRK vector to point to an unprogrammed "patch area" in the PROM. In the event a bug was discovered, patching would be accomplished by "blowing" all of the fuses at the address where the faulty instruction was located, thus changing the instruction's opcode to <templatestyles src="Mono/styles.css" />$00. Upon executing the resulting <templatestyles src="Mono/styles.css" />BRK, the MPU would be redirected to the patch area, into which suitable patch code would be written. Often, the patch area code started by "sniffing the stack" to determine the address at which the bug was encountered, potentially allowing for the presence of more than one patch in the PROM. The use of <templatestyles src="Mono/styles.css" />BRK for PROM patching diminished once EPROMs and EEPROMs became commonly available.

Another use of <templatestyles src="Mono/styles.css" />BRK in software development is as a debugging aid in conjunction with a machine language monitor. By overwriting an opcode with <templatestyles src="Mono/styles.css" />BRK (<templatestyles src="Mono/styles.css" />$00) and directing the <templatestyles src="Mono/styles.css" />BRK hardware vector to the entry point of the monitor, one can cause a program to halt at any desired point, allowing the monitor to take control. At that time, one may examine memory, view the processor's register values, patch code, etc. Debugging, as advocated by Kuckes and Thompson, can be facilitated by liberally sprinkling one's code with <templatestyles src="Mono/styles.css" />NOP instructions (opcode <templatestyles src="Mono/styles.css" />$EA) that can be replaced by <templatestyles src="Mono/styles.css" />BRK instructions without altering the actual behaviour of the program being debugged.[5][6][7]

A characteristic of the <templatestyles src="Mono/styles.css" />BRK and <templatestyles src="Mono/styles.css" />COP instructions is that the processor treats either of them as a two byte instruction: the opcode itself and the following byte, which is referred to as the "signature."[2] Upon execution of <templatestyles src="Mono/styles.css" />BRK or <templatestyles src="Mono/styles.css" />COP, the processor will add two to the program counter prior to pushing it to the stack. Hence when <templatestyles src="Mono/styles.css" />RTI (ReTurn from Interrupt) is executed, the interrupted program will continue at the address immediately following the signature. If <templatestyles src="Mono/styles.css" />BRK is used as a debugging device, the program counter may have to be adjusted to point to the signature in order for execution to resume where expected. Alternatively, a <templatestyles src="Mono/styles.css" />NOP may be inserted as a signature "placeholder," in which case no program counter adjustment will be required.

The fact that <templatestyles src="Mono/styles.css" />BRK and <templatestyles src="Mono/styles.css" />COP double-increment the program counter before pushing it to the stack facilitates the technique of treating them as supervisor call instructions, as found on some mainframe computers. The usual procedure is to treat the signature as an operating system service index. The operating system <templatestyles src="Mono/styles.css" />BRK or <templatestyles src="Mono/styles.css" />COP handler would retrieve the value of the program counter pushed to the stack, decrement it and read from the resulting memory location to get the signature.[8][9] After converting the signature to a zero-based index, a simple lookup table can be consulted to load the program counter with the address of the proper service routine. Upon completion of the service routine, the <templatestyles src="Mono/styles.css" />RTI instruction would be used to return control to the program that made the operating system call. Note that the signature for <templatestyles src="Mono/styles.css" />BRK may be any value, whereas the signature for <templatestyles src="Mono/styles.css" />COP should be limited to the range <templatestyles src="Mono/styles.css" />$00-<templatestyles src="Mono/styles.css" />$7F.[2]

The use of <templatestyles src="Mono/styles.css" />BRK and/or <templatestyles src="Mono/styles.css" />COP to request an operating system service means user applications do not have to know the entry address of each operating system function, only the correct signature byte to invoke the desired operation. Hence relocation of the operating system in memory will not break compatibility with existing user applications. Also, as executing <templatestyles src="Mono/styles.css" />BRK or <templatestyles src="Mono/styles.css" />COP always vectors the processor to the same address, simple code may be used to preserve the registers on the stack prior to turning control over to the requested service. However, this programming model will result in somewhat slower execution as compared to calling a service as a subroutine, primarily a result of the stack activity that occurs with any interrupt. Also, interrupt requests will have been disabled by executing <templatestyles src="Mono/styles.css" />BRK or <templatestyles src="Mono/styles.css" />COP, requiring that the operating system re-enable them.

<templatestyles src="Mono/styles.css" />WAI and <templatestyles src="Mono/styles.css" />STP instructions

<templatestyles src="Mono/styles.css" />WAI (WAit for Interrupt, opcode <templatestyles src="Mono/styles.css" />$CB) is an instruction available on the WDC version of the 65C02 and the 65C816/65C802 microprocessors (MPU) that halts the MPU and places it into a semi-catatonic state until a hardware interrupt of any kind occurs.[2] The primary use for <templatestyles src="Mono/styles.css" />WAI is in low-power embedded systems where the MPU has nothing to do until an expected event occurs and minimal power consumption is desired as the system is waiting, and/or a quick response is required. A typical example of code that would make use of <templatestyles src="Mono/styles.css" />WAI is as follows:

        SEI                     ; disable IRQs
        WAI                     ; wait for hardware interrupt
        ; ... execution resumes here

In the above code fragment, the MPU will halt upon execution of <templatestyles src="Mono/styles.css" />WAI and go into a very low power consumption state. Despite interrupt requests (IRQ) having been disabled prior to the <templatestyles src="Mono/styles.css" />WAI instruction, the MPU will respond to any hardware interrupt while waiting. Upon receipt of an IRQ, the MPU will "awaken" in one clock cycle and resume execution at the instruction immediately following <templatestyles src="Mono/styles.css" />WAI. Hence interrupt latency will be very short (70 nanoseconds at 14 megahertz), resulting in the most rapid response possible to an external event.

Similar in some ways to <templatestyles src="Mono/styles.css" />WAI is the <templatestyles src="Mono/styles.css" />STP (SToP, opcode <templatestyles src="Mono/styles.css" />$DB) instruction, which completely shuts down the MPU while waiting for a single interrupt input.[2] When <templatestyles src="Mono/styles.css" />STP is executed, the MPU halts its internal clock in the high phase, retaining all data in its registers, and enters a low power state. The MPU is brought out of this state by pulling its reset input pin (<templatestyles src="Mono/styles.css" />RESB, which is classified as an interrupt input) low. Execution will then resume at the address stored at locations <templatestyles src="Mono/styles.css" />$00FFFC-$00FFFD, the hardware reset vector. As with <templatestyles src="Mono/styles.css" />WAI, <templatestyles src="Mono/styles.css" />STP is intended for use in low-power embedded applications where long periods of time may elapse between events that require MPU attention and no other processing is required. <templatestyles src="Mono/styles.css" />STP would not be used in normal programming, as it would result in total cessation of processing.

Footnotes

  1. Cite error: Script error: No such module "Namespace detect".Script error: No such module "Namespace detect".
  2. Cite error: Script error: No such module "Namespace detect".Script error: No such module "Namespace detect".

References

  1. a b c d e Script error: No such module "citation/CS1".
  2. a b c d e f g h i j k l m n o p q r s t u v w Script error: No such module "citation/CS1".
  3. a b Script error: No such module "citation/CS1".
  4. a b Script error: No such module "citation/CS1".
  5. a b c Script error: No such module "citation/CS1".
  6. Script error: No such module "citation/CS1".
  7. Script error: No such module "citation/CS1".
  8. Script error: No such module "Citation/CS1".
  9. Script error: No such module "citation/CS1".

Further reading

Script error: No such module "Navbox".