User ISA Clarification: EBREAK vs ECALL

1,200 views
Skip to first unread message

Samuel Falvo II

unread,
Oct 4, 2016, 12:47:43 AM10/4/16
to RISC-V ISA Dev
I can easily see ECALL saving IA+4 (where IA is the ECALL instruction address) in MEPC prior to taking the trap.  When executing an xRET instruction, you often want to return to the instruction following the ECALL.

However, what does EBREAK do?  My emulator currently defines its behavior as saving IA+4 in MEPC.  However, a debugger would often want to know exactly where the break happened.  Some traps (e.g., illegal instructions, access violations, etc.) store the instruction address in MEPC.

Can someone help me understand which traps store IA and which store IA+4 into MEPC?  Thanks.

Stefan O'Rear

unread,
Oct 4, 2016, 12:51:50 AM10/4/16
to Samuel Falvo II, RISC-V ISA Dev
This is quite simple - all of them store IA. If you don't want a
system call to reexecute, you need to manually adjust *epc in the trap
handler, for instance
https://github.com/riscv/riscv-linux/blob/priv-1.9/arch/riscv/kernel/entry.S#L158
.

-s

Angelo Bulfone

unread,
Oct 4, 2016, 12:54:46 AM10/4/16
to Samuel Falvo II, RISC-V ISA Dev
From what I understand of x86, calling "int 3" (breakpoint exception) stores the next instruction rather than the current one to facilitate returning to it. My understanding is that most exceptions invoked by mnemonic behave the same way, while runtime exceptions store the current instruction so it can be retried if the exception is resolved (like in the case of demand paging).

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/ee78f49f-0442-45bc-adea-487422833414%40groups.riscv.org.

Samuel Falvo II

unread,
Oct 4, 2016, 12:55:51 AM10/4/16
to RISC-V ISA Dev, sam....@gmail.com
Holy crap, I had that wrong the whole time.  Hahaha!!  Time to cut a new release of the Kestrel emulator then.  :D

And, that makes implementing the hardware markedly easier.  Thanks for the clarification!

Samuel Falvo II

unread,
Oct 4, 2016, 1:20:25 AM10/4/16
to Angelo Bulfone, RISC-V ISA Dev
On Mon, Oct 3, 2016 at 9:54 PM, Angelo Bulfone <mbul...@gmail.com> wrote:
> From what I understand of x86, calling "int 3" (breakpoint exception) stores
> the next instruction rather than the current one to facilitate returning to
> it. My understanding is that most exceptions invoked by mnemonic behave the
> same way, while runtime exceptions store the current instruction so it can
> be retried if the exception is resolved (like in the case of demand paging).

Given that this contradicts Stephan's response, the correct answer
should probably be made explicit in the User ISA spec.

--
Samuel A. Falvo II

Stefan O'Rear

unread,
Oct 4, 2016, 1:36:33 AM10/4/16
to Samuel Falvo II, Angelo Bulfone, RISC-V ISA Dev
Angelo's response was correct. x86 does indeed behave as they
describe. RISC-V just takes the other approach (AFAIK both are
common)

The value of *EPC after a trap is out of scope for the user spec. All
user code needs to know is that when you say ECALL, a system call
happens and execution continues at the next instruction.

https://content.riscv.org/wp-content/uploads/2016/07/riscv-privileged-v1.9-1.pdf
§3.1.19 says:

> When a trap is taken, mepc is written with the virtual address of the instruction that encountered the exception.

which I'll admit could be more explicit. See also
https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/42IM6tstYOg/ePRyYIenDAAJ
, which appears to indicate that the precise specification of ECALL
will be in "the next draft".

-s
Reply all
Reply to author
Forward
0 new messages