현동훈
현동훈

Reputation: 1

Difference of 'software interrupt' and 'exception' in RISC-V

I'm reading privileged ISA manual of RISC-V, and I found that they strictly separate the 'interrupt' and 'exception' and 'trap'. In my understanding, the asynchronous event from outside is 'interrupt', and unexpected situation by instruction execution is 'exception'. And 'trap' is context switching by both 'interrupt' and 'exception'.

And I found other terms, 'hardware interrupt', 'software interrupt' and 'timer interrupt'. I understand that the timer interrupt needs to be managed separately because it's important. However, I can't understand what 'software interrupt' is. I found these terms at the description about mcause, mideleg and mie registers. Here's the table.

table 14

In my guess, I think 'exception' is different from 'software interrupt' because in the table, there're distinct entries for 'software interrupt' and other not-interrupt events such as 'instruction access fault' or 'illegal instruction' which I thought would be the examples of 'exception'.

Can anyone explain about what exactly this 'software interrupt' is?

And if it's different from the 'exception', then is mie register not responsible for enabling any 'exceptions'?

Upvotes: 0

Views: 35

Answers (1)

Erik Eidt
Erik Eidt

Reputation: 26686

All these interrupts use the same mechanism, just set the cause differently, and have different handling by the kernel.

The classic trap is ecall.  A (user) thread that makes an ecall expects that instruction to be serviced (by the kernel) as if it were a function call.

This has two notable low-level effects: that the ecall is synchronous with respect to that thread; that in order to resume that thread the kernel must both service the request operation, return a value (such as success & some data or failure & some reason) and must also advance the thread's program counter just past the ecall machine code instruction such that the thread resumes at the next instruction after, mimicking subroutine return/resumption behavior.

Compare this exception handling behavior with another exception, such as memory access violation, which is also an interrupt by instruction execution of software.

In a memory access violation, the kernel must decide if the violation is a true violation, in which case the program is considered in error and the violating thread is terminated, or, if the violation is a page fault.

A page fault is considered normal operation and is recoverable, by having the kernel locate or create the desired page of virtual memory and make it available to the user process.  This can be quite involved, doing I/O, changing page table entries, tlb entries, etc...  However, as page faults do not indicate program error, and once serviced, the user thread can resume — here, though by re-starting/re-executing the (formerly) offending instruction rather than skipping over it as with ecall.

All synchronous exceptions (e.g. ecall and memory access violation) cannot be "turned off" because when a software thread leads the processor to an instruction that demands an exception, these are simply not optional: they must be handled.

By contrast, external interrupts can be enabled or disabled.

So, the term trap is usually used for the kernel attention getting operation that is like a function call.  Software interrupts are those caused by execution of faulting or excepting machine code instructions (memory access violation, privilege violation, etc..)

The timer will behave more like an external interrupt, though on these systems the timers are built-in to the chip (rather than off chip as in days of old), and due to the desire to be able to use timers in today's more complex programming models, they often have their own enable/disable separate from off-chip interrupts, to easily disable all other truly external device interrupts, while leaving timers working.

Upvotes: 0

Related Questions