Using BRK and COP
As previously noted, BRK and COP are software interrupts and, as such, may be used in a variety of ways to implement system functions.
A historical use of BRK has been to assist in patching PROMs when bugs were discovered in a system's firmware. A typical technique often used during firmware development was to arrange for the 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 $00. Upon executing the resulting 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 BRK for PROM patching diminished once EPROMs and EEPROMs became commonly available.
Another use of BRK in software development is as a debugging aid in conjunction with a machine language monitor. By overwriting an opcode with BRK ($00) and directing the 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 NOP instructions (opcode $EA) that can be replaced by BRK instructions without altering the actual behaviour of the program being debugged.
A characteristic of the BRK and COP instructions is that the processor treats either as a two byte instruction: the opcode itself and the following byte, which is referred to as the "signature." Upon execution of BRK or COP, the processor will add two to the program counter prior to pushing it to the stack. Hence when RTI (ReTurn from Interrupt) is executed, the interrupted program will continue at the address immediately following the signature. If 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 NOP may be inserted as a signature "placeholder," in which case no program counter adjustment will be required.
The fact that BRK and 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 BRK or 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. 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 RTI instruction would be used to return control to the program that made the operating system call. Note that the signature for BRK may be any value, whereas the signature for COP should be limited to the range $00-$7F.
The use of BRK and/or 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 BRK or 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 BRK or COP, requiring that the operating system re-enable them.
Read more about this topic: Interrupts In 65xx Processors