What are Exceptions?

An exception is an unexpected event from within the processor. EXCEPTION refers to unusual events or happenings that deviate from the expected flow of execution. These exceptions can originate from internal sources within the processor or from external factors. They can also be classified based on whether they occur synchronously or asynchronously.

Synchronous Exceptions:

These exceptions are synchronized with the clocks and instructions of the processor. This means that one can predict when they might occur, although their actual occurrence is not guaranteed. Synchronous exceptions occur within specific time slots or clock periods, making it possible to anticipate them to some extent. Examples of synchronous exceptions include division by zero or invalid memory accesses.

Asynchronous Exceptions:

In contrast, asynchronous exceptions can occur at any time and are not synchronized with the processor's clocks or instructions. Unlike synchronous exceptions, the timing of asynchronous exceptions cannot be precisely determined. These exceptions are often triggered by external events or conditions beyond the control of the program or processor. Examples of asynchronous exceptions include hardware interrupts or system crashes like keyboard interrupts, hardware malfunctions and disk failure

Intentional Exceptions:

These are deliberately triggered by the program or the system to handle specific conditions or events. For example, a program might intentionally raise an exception to handle an error condition or to signal a specific event.

Example:

For instance, consider a program that calculates the average of a list of numbers entered by the user. The program expects the user to input numerical values, but if the user enters a non-numeric value, it will raise an intentional exception to handle this error.

Unintentional Exceptions:

These occur due to unexpected events or errors that are beyond the control of the program or the system. They can be caused by hardware failures, external interference, or unexpected inputs.

Example:

An example of an unintentional exception could be a program encountering a divide-by-zero error due to a logical flaw or a bug in the code.

Handling Exceptions:

Handling exceptions in programming means dealing with unexpected problems that might happen while the program is running. This includes recognizing when something goes wrong, figuring out what went wrong, and then deciding what to do about it. It's like having a backup plan for when things don't go as expected, so the program can recover gracefully and keep running smoothly

Exception VS Interrupt

yet to be completed

Examples of exceptions

Unintentional exception

• Access to Privileged Instructions: Instructions are often divided into two types: privileged and general. Privileged instructions are special instructions reserved for the operating system's use. They are used for overall resource management. User programs can't run privileged instructions, and hardware checks prevent them from doing so. If a user program tries to run a privileged instruction, it's not allowed to execute.

• Overflow/Underflow Instruction - The occurrence of underflow or overflow conditions during arithmetic operations is unintentional, resulting from the result of an operation exceeding the prescribed limits of a certain word size. Without prior checks, the result may exceed the expected range. When faced with such a situation, the response depends on the programmer's intention.

What do you do when it happens?

Some programmer may choose to continue with the remaining calculations, while others may perceive it as an unintended error, and abort the execution and stop there. Given its internal and synchronous nature, underflow or overflow is predictable within the program's execution cycle. During an arithmetic instruction, when conducting arithmetic operations within a specific cycle, you would be aware of whether the outcome is as expected or deviates from the anticipated result.

• Undefined instruction - Suppose there is 6-bit opcode, which means there's 2^6=64 possible patterns of opcode. It's possible that not all patterns are defined within the instruction set architecture. Encountering an instruction with an undefined opcode during program execution raises questions about how the hardware should respond. Even with a limited instruction set, such as the nine instructions previously discussed, there remain many undefined opcodes. As a result, the hardware must be prepared to handle such occurrences by responding in a meaningful manner to execute any unexpected instruction encountered in the code. This situation is unintentional, internal, and occurs synchronously.

• Hardware Malfunction: -A hardware malfunction occurs when something goes wrong within the hardware. The hardware is equipped with self-testing logic capable of detecting faults. When a fault is detected, it signals that there is a malfunction in the hardware. This event can occur asynchronously, meaning it may not be synchronized with the instruction being executed. It can originate from both internal components of the processor and external hardware. Whether it's an internal or external issue, the processor receives a signal indicating that something has gone wrong.

• Memory Access Exception: -A memory access exception occurs when an instruction generates an address that exceeds the physical memory available in a hardware system. Despite having addressing capability for 2^32 or 4 GB of memory space, the hardware may not be fully populated with memory. In such cases, if an instruction tries to access memory beyond the physical memory's capacity, a memory access exception is triggered.

Additionally, in a multitasking environment where multiple programs are running simultaneously, the operating system allocates specific memory areas to each program. Each program is expected to access memory within its allocated area. If a program attempts to access memory beyond its designated area, it results in a memory access exception. These exceptions serve as safeguards to ensure the proper functioning and integrity of the system's memory management.

• Alignment Error: -Memory addresses are typically byte addresses, while memory is organized word-wise. A word may start at an address that is a multiple of 4, or it may not. When the addresses of words are multiples of 4, the logical and physical words are aligned. However, if they are not aligned, a logical word may span two physical words, with some bytes in one word and some in the next.

Certain processors may offer the option to disallow unaligned memory access due to the performance penalty associated with it. In such cases, a check is performed to determine whether the access to be made is aligned or not. If unaligned accesses are prevented and an attempt is made to access unaligned memory, it is flagged as an error. This type of error is related to memory access and helps maintain system stability and efficiency.

• Timeouts -Timeouts can occur, especially concerning input/output (I/O) devices.

Intentional exception

• Invoke OS Function: -Invoking an operating system function involves creating a situation similar to an exception within a user program. When this occurs, control is transferred to the operating system, which provides the necessary service before returning control to the user program. This mechanism is essential because the operating system can execute privileged instructions and has access to resources that user programs do not. Unlike regular jump or branch instructions, which cannot target addresses within the operating system's area, invoking an OS function follows a controlled path. It ensures that access to the operating system remains regulated and prevents unpredictable actions. Think of it as being guided through a restricted area, where you are escorted, shown around, and then safely returned. This intentional event involves special instructions that are treated similarly to exceptions, leading to control being transferred to a specific area within the OS for service provision.

• Trace/Debug: -Tracing and debugging in processors often involve hardware debugging facilities that allow running instructions step by step, typically executing one instruction at a time. One common method involves generating an exception after each instruction, directing control to a special handler. In this handler, the user can interact with the debugger, inspecting memory contents, register values, and other relevant information. Once the user wishes to resume program execution, they return to execute the next instruction, triggering another exception, and thus continuing the debugging process. This iterative approach ensures that only one instruction is executed within the user program before control is returned to the exception handler, facilitating effective debugging.

How exceptions are handled

To understand the general approach to handling exceptions, let's visualize a timeline horizontally, representing the sequence of instructions being executed. In the first block, normal program execution is depicted. At the end of this block(in first line), an event or exception is identified. The response to this exception can take different paths.

In the second block(in second line), control is transferred to another activity, represented in green, which addresses the exception. This activity could involve interrupting and halting the processor temporarily. Alternatively, after handling the exception, the program can resume its previous operation.

In the third line(in figure) , various choices exist depending on the type of exception encountered. For interrupt and resume exceptions, two main alternatives are considered. The first is a vectored interrupt, where control transfer is accompanied by identifying the cause of the exception and directing control to specific addresses dedicated to handling different types of exceptions. Each address hosts a piece of code known as an interrupt service routine or handler, responsible for taking appropriate action based on the exception.

The second alternative, depicted in the fourth line(in figure), involves non-vectored interrupt handling. Here, control is transferred to a specific address regardless of the exception's cause. Following this, a few instructions are executed to determine the exception's cause, followed by branching off to the appropriate handler. While the vectored approach is faster since it directly links the next address to the exception's cause, the non-vectored approach requires additional time to identify the cause before proceeding, albeit with fewer hardware requirements.

NESTED INTERRUPTS

• When there are multiple sources of exceptions there are chances of rise of complications.
• If one exception is serving, then after some time the other exception occurs which is an interrupt, then after some time of 2 nd exception serving 3 rd exception occurs, again an interrupt.
• These are usually called nesting of interrupts or nesting of exceptions which can complicate the issues.
• Here first 3rd exception completes, then the 2nd exception and then comes back to the original exception it is started with.

CHECKING FOR EXCEPTIONS

Let's discuss about the two exceptions mentioned in the diagram.

1. undefined instruction and
2. exception resulting from overflow.

The instruction cycle decodes, executes and writes back so these are the four-cycle instructions it goes through.

Here getting values from the register file is considered as "execute cycle(EX)" and writing back the result into the register file is "write back cycle(WB)."

• In cycle "D", it indicates whether the opcode is the same as you catered or not and cycle "EX" indicates whether overflow has occurred.

CHANGES REQUIRED IN DATAPATH:

1. First thing is Interrupt/Exception Handling: When an interrupt or exception occurs, the processor saves the current execution context (such as program counter, register values, etc.) on the stack or in dedicated registers. It then jumps to a predefined exception handler routine specified by the interrupt or exception vector.

(If PC value is stored in "ra" there is a chance of happening that this exception may occur at a point where it interupts interfering with normal procedure cause)

In some processors there are the call instruction that directly saves the program counter on stack unlike MIPS.

2. Second thing is what is called a cause register which will generally record the cause of exception. In this case there are two possible exceptions so it could be one bit register only but in general in real cases there are many causes of exception and the registers are bigger. So often it may be a full-fledged 32-bit register.

Value 0 in this would mean undefined instruction exception and 1 would mean arithmetic overflow exception

3. Third, it has to be known that to which address is the control is transferred. In case of vector interrupt it has an array of such addresses and control is transferred to one of those depending upon cause of exception.

So these addresses could be typically uniformly placed, say they are spaced by sixteen words that may not necessarily be able to accommodate each routine within sixteen words and one can write some initial code and then branch off to some other place.

DP Modified For Exceptions

• To manage exceptions in a multicyle datapath, three critical modifications are necessary:
• Implementing an Exception Program Counter (EPC) to capture the faulting instruction's address
• Introducing a Cause Register for identifying the exception's cause.
• Expanding the PC selection multiplexer to redirect execution to the exception handler.

1. Exception Program Counter (EPC):

Purpose: Stores the address of the instruction that caused the exception.

Modification: Since the Program Counter (PC) would have already moved past the offending instruction (incremented by 4), the original address needs to be recalculated by subtracting 4 from the current PC value.

Implementation: This is achieved by using an Arithmetic Logic Unit (ALU) operation, where PC and 4 are the operands, and the operation is subtraction. The result is then stored in the EPC. A control signal (likely named something like ew for EPC write) triggers storing the output of the ALU into the EPC.

2. Cause Register:

Purpose: Holds a value indicating the cause of the exception, typically 0 or 1, to differentiate between types of exceptions.

Implementation: A simple register with a control signal for loading values into it. The specific value (0 or 1) is provided by the controller, which determines the type of exception that has occurred.

3. Alternative Source for Next PC Value:

Modification: The existing 3-input multiplexer, which selects the next value for the PC, is expanded to a 4-input multiplexer.

Purpose: Allows for the selection of the address of the exception handler as the next PC value, facilitating the transfer of control to exception handling routines.

Overall Process:

These modifications ensure that when an exception occurs, the datapath can:

• Save the address of the problematic instruction,

• Identify the cause of the exception,

• And transfer control to the appropriate exception handler.

• This setup requires corresponding adjustments in the controller design to recognize when exceptions occur and to transition the machine to new states where these modified datapath components are utilized to handle the exceptions appropriately.

• By introducing these changes, the multicyle datapath becomes capable of handling exceptions, improving the robustness and reliability of the system by allowing it to respond to and recover from unexpected conditions during execution.

Modified Controller

• The modifications to the control state diagram in the processor's controller design address how to handle conditions such as arithmetic overflows and undefined operations, aiming to enhance the system's robustness and reliability by ensuring graceful handling of exceptional circumstances.

Handling Arithmetic Overflows

Context: The operation involves arithmetic (addition/subtraction) where there's a potential for overflow.

Modification: After performing the arithmetic operation, the decision to branch is postponed until after the result is potentially stored in the register file. This allows for the possibility of storing the arithmetic result even in the event of an overflow.

Implication: This approach provides flexibility for programmers who may want to use the overflowed result for some purpose. However, it also introduces the risk of contaminating the register file with erroneous values if the overflowed result is stored without any conditional checks. An alternative approach would be to branch immediately after detection of an overflow, preventing the storage of overflowed results unless explicitly handled.

Handling Undefined Operations

Context: The point in the control flow where it's determined that an operation does not fit predefined, valid categories (like load, store, branch-equal (beq), or jump (j)).

Modification: Introducing a new branch in the control flow to handle undefined or illegal operations. This branch leads to a state specifically designed to address these cases.

Implication: This modification ensures that the system can gracefully handle illegal instructions by transferring control to a state where appropriate measures can be taken (such as throwing an exception or terminating the program), rather than allowing the processor to execute an undefined state or operation.

Overall Impact of the Modifications

• These changes illustrate a refinement in the processor's ability to handle exceptional conditions more gracefully. By explicitly managing arithmetic overflows and undefined operations within the controller's state diagram, the modifications aim to improve the robustness and reliability of the system.

• Such enhancements can be particularly important in environments requiring precise error handling and in scenarios where recovery from an error condition is necessary to ensure continued operation.

New control states

The way we handle arithmetic overflow in CS10 is by setting the cause to 1 and using EPC to obtain the value of PC-4. The new value of PC is c followed by seven zeros. The cause register receives a different value, but other than that, Cs11 is the same. We must set values for the control inputs in order for this to occur.

Asrc1 is equal to zero which will select PC as the first operand, Asrc2 is equal to 01 will select 4 as the second operand and OPC is equal 01 which will perform subtraction. The result will load into exception registers. While writing into the PC, PWu(unconditional write) which will become 1 and PWc(conditional write) will become 0. The source is 11, which means new input to the multiplexer get selected and that value will get transferred to PC.

Exception handling in MIPS

• Exceptions and interrupts are unexpected events that disrupt the normal flow of instruction execution. An exception is an unexpected event from within the processor. An interrupt is an unexpected event from outside the processor.

There are three events that will trigger an exception :

1. Arithmetic overflow occurs during the execution of an add, addi, or sub instruction. If the result of the computation is too large or too small to hold in the result register, the Overflow output of the ALU will become high during the execute state. This event triggers an exception.
2. Undefined instruction occurs when an unknown instruction is fetched. This exception is caused by an instruction in the IR that has an unknown opcode or an R-type instruction that has an unknown function code.
3. System call occurs when the processor executes a syscall instruction. Syscall instructions are used to implement operating system services(functions).

When an exception occurs, the processor will perform the following actions:

• move the current PC into another register, call the EPC
• record the reason for the exception in the Cause register
• automatically disable further interrupts or execptions from occuring, by left-shifting the Status register
• change control (jump) to a hardwired exception handler address

To return from a handler, the processor may perform the following actions:

• move the contents of the EPC register to the PC.
• re-enable interrupts and exceptions, by right-shifting the Status register

Status Register

The status register is a hardware register that contains information about the state of the processor. Individual bits are implicitly or explicitly read and/or written by the machine code instructions executing on the processor.

Interrupt Masking:

Bits 8 to 15 of the status register are used as interrupt masks. Each bit corresponds to a different type of interrupt. This allows specific interrupts to be enabled or disabled individually.

Mode and Enable Bits:

• The status register has six bits for mode and enable/disable information.

• Each set of two bits represents a specific mode and its enable/disable state:

  • Bit 0 and Bit 1: Current mode and enable/disable status.

  • Bit 2 and Bit 3: Previous mode and enable/disable status.

  • Bit 4 and Bit 5: Mode and enable/disable status before the previous state.

Mode Information:

The mode bits (0, 2, and 4) indicate whether the processor is in kernel mode, user mode, or another mode (perhaps privilege or normal mode).

Stack-Like Behavior:

• These six bits effectively form a stack with a depth of three. As exceptions or interrupts occur, the stack is pushed down to store the current state.

• When returning from an exception or interrupt, the processor can retrieve the mode and enable/disable status from the stack to resume execution correctly.

Handling Exceptions:

When an exception occurs, the status register's stack is used to save the current state, including mode and interrupt enable/disable status. Upon returning from the exception, the processor can restore the previous mode and interrupt settings from the stack.

Cause Register

Cause register provides essential information about the type of exception or interrupt that has occurred, allowing the operating system to respond appropriately and ensure the system's stability and reliability.

Exception Code:

• The Cause register contains an exception code that indicates the type of exception that occurred.

• Some of the mentioned exceptions include:

  • Overflow: Indicates an arithmetic overflow condition.

  • Undefined Instruction: Occurs when the processor encounters an instruction that it doesn't recognize or support.

  • Syscall: Represents a system call instruction, used for invoking OS services.

  • External Interrupt (IST): Indicates an interrupt triggered by an external device or hardware.

  • Memory Errors: These could include exceptions related to memory access violations or errors.

Pending Interrupts:

• The Cause register may also include information about pending interrupts.

• Pending interrupts are interrupts that have occurred but have not yet been serviced by the processor.

Complexity of Interrupt System:

• The overall interrupt system can be quite complex, with various types of exceptions and interrupts to handle.

• Operating system interrupt routines are typically responsible for handling these events, rather than the user directly writing these routines.

Operating System Responsiveness:

• Operating system developers must carefully define responses to various events, including exceptions and interrupts.

• These responses are critical for maintaining system stability, handling errors, and ensuring proper operation of the system.