DE1-SoC Hardware

Interrupt Procedure

Prerequisites for a hardware device to trigger an interrupt:

1. The program must have a .vector section (also known as the "exception table")
2. The instruction at address 0x18 in the .vector section must be B SERVICE_IRQ, ensuring that when an interrupt occurs, execution correctly enters the Interrupt ReQuest handler
3. The GIC must be properly configured, and the hardware device must be set up to trigger interrupts
4. The SERVICE_IRQ subroutine must contain corresponding ISR handlers for each hardware device
5. Each Interrupt Service Routine must perform its task and correctly return to the Interrupt ReQuest handler

So when an interrupt occurs (suppose ICCIAR contains the value 72, meaning a KEY press triggered the interrupt):

1. The processor immediately stops what it is doing. The GIC saves the current mode's special registers (SP, PC, CPSR), switches the mode to IRQ_MODE, and sets PC to 0x18
2. The instruction at 0x18 is exactly B SERVICE_IRQ, so execution enters the subroutine at the SERVICE_IRQ label
3. Inside SERVICE_IRQ, first back up the data registers (R0-R10; in practice, back up only the ones you use — the professor's code recommends R0-R7). Read ICCIAR into R5 (or any other register; R5 is used here as an example), then compare it against a series of interrupt IDs
4. If R5 equals 73, enter the KEY_ISR subroutine
5. After KEY_ISR finishes its task, return to SERVICE_IRQ, restore the previously backed-up data registers (R0-R10), and reset the interrupt status by writing the interrupt ID (R5) back to ICCEOIR (if you skip this step, the GIC will immediately re-trigger the interrupt after exiting IRQ mode)
6. Exit the interrupt. The GIC restores SP, PC, and CPSR

Program Counter

Key concepts:

About PC:

• As a register, PC stores the address of the next instruction to be executed (i.e., the instruction that is about to run but has not yet run)
• When PC appears as an operand in an instruction (e.g., MOV R0, PC), it represents an address equal to (the address of the current instruction + 8)

About LR:

• When executing BL someLabel, before branching into someLabel, the address of the BL someLabel instruction + 4 is stored in LR
• During normal program execution, if an interrupt occurs, the address of the first unexecuted instruction + 4 is stored in IRQ mode's LR

Special thanks to Dr. Henry Wong (https://www.stuffedcow.net/) who provided this perspective on Piazza in Winter 2019, even when he was not a TA at that time. He motivates me to post those review materials for free.

Original:

This is not the official position of ECE243, but I disagree sufficiently with the way PC is taught that I think an alternative view would be useful. What you've learned so far is

• The CPU has a set of registers,
• at any instantaneous moment in time, each register has one value, and
• the register values change when you execute an instruction or interrupt (or a few other things).

PC isn't really a register by the above definition, and cannot be treated as one (it violates #2). ECE243 tries really hard to explain PC as if it were a register, but when you dig deep enough you're left with a bunch of inconsistencies in behaviour that are very difficult to explain away, and it's these inconsistencies that lead you to ask questions like this one and @457. Congrats on detecting the lie.

What's a better explanation of PC?

Each instruction is an opcode in memory, and PC is the location of the opcode. PC is not a physical object. It is just the concept of the location of an instruction. This means that questions like "What is the value of PC" don't make sense, but questions like "What is the PC of this instruction?" do make sense. The correct question to ask is "What value do I observe when I look at PC from some perspective?" What you observe depends on the method you use to observe it:

• From the debugger (or at instruction fetch): PC points to the instruction that has not yet executed. This is what the debugger shows you.
• Reading r15 as an operand of an instruction (e.g., mov r0, pc or ldr r0, [pc]): The observed value is the PC of the instruction itself + 8.
• Writing r15 as the destination operand of an instruction (e.g., mov pc, lr): PC points to the next instruction to execute (same as the first definition above)
• Branch-and-link instructions (function call): The observed value (the value written to LR) is the PC of the instruction itself + 4.
• Interrupts: The observed value (the one written to LR) is the PC of the first unexecuted instruction + 4 (so that returning to LR-4 is correct). Note that this is not the same as "PC of the last completed instruction + 8"
• Software exception instruction: The observed value (written to LR) is the PC of the SVC instruction + 4.

(I might be missing a few cases) The point is: PC is not a register, and does not have a single value. What matters is what you get when you look at "PC", and the ISA specifies all the ways you can observe "PC", the meaning of each, and offsets that depend on the method you use to observe.

There are a few other imaginary things invented to fit the view of PC being a register. One of the most confusing is the concept of a "currently-executing instruction" and whether this "current instruction" is completed or aborted at an interrupt. (The logic behind it is: If we suppose that PC has a single global value, then there must be a "current" instruction related to this value, and thus we must define whether the "current" instruction is completed or aborted at an interrupt to make it consistent with the observations about LR during an interrupt). These explanations need to exist only if you try to explain PC as if it were a register. At a precise interrupt, all instructions are completed up to some point, and all instructions after that point have not executed. Then the LR is set to the PC of the first non-executed instruction + 4. I think the clearest way to express this idea is to think of interrupts as occurring in between instructions, not at an instruction that is then completed/aborted.

So to directly answer your questions using the above interpretation:

• If you are looking at PC from the debugger, yes. PC points to the instruction that hasn't yet executed, which is at 0x0.
• If you're still looking at PC from the debugger, then PC would be 0x4 (the location of the instruction that hasn't yet executed) unless the instruction was a taken branch. What you were probably trying to ask was "If the instruction at 0x0 used PC as a source operand, would it see 0x8?", and the answer is yes: When reading pc as a source operand, the observed value is the PC of the instruction itself + 8.
• BL sets LR to (location of the BL instruction + 4). Interrupts set LR to (location of first unexecuted instruction + 4).

VGA

http://www-ug.eecg.utoronto.ca/desl/nios_devices_SoC/dev_vga.html

.global _start
_start:
	// using this address to write directly to the buffer
	ldr r7,=0xc8000000
	ldr r0,=0b11111

BLUE:
	LDR R1,xOffset
	ADD R1, #1
	STR R1,xOffset
	CMP R1, #320
	BLEQ ADD_Y

	LSL R1, #1

	LDR R2,yOffset
	LSL R2,#10

	ORR R1,R2

	STRH R0, [r7,R1]
	B BLUE

ADD_Y:
	MOV R1, #0
	STR R1,xOffset

	LDR R2, yOffset
	ADD R2,#1
	STR R2, yOffset

	CMP R2, #240
	BEQ DONE
	BX LR

DONE: B DONE

xOffset:
	.word 0
yOffset:
	.word 0