A deliberately non-authoritative placeholder — it exists to explain the conventions the code examples assume, while the real vector calling convention is finalized in the RISC-V psABI.
| Rule | |
|---|---|
| Everything caller-saved | v0-v31, vl, and vtype are ALL caller-saved — a callee may clobber any of them, so the caller saves whatever is live across a call. |
| vstart = 0 contract | Procedures may assume vstart is zero on entry and on return. Any procedure that writes vstart nonzero must re-zero it before returning or calling out. |
| vxrm / vxsat | Thread storage duration (they persist per-thread, like a rounding-mode setting). |
| System calls clobber vector state | A syscall makes all caller-saved vector state (v0-v31, vl, vtype, vstart) UNSPECIFIED. |
Hardware Designer Notes
For the OS team, the takeaway pairs with mstatus.VS: lazy vector-state switching plus a syscall-clobber ABI keeps the cost of the giant vector register file off the common path. The authoritative rules will come from the psABI; this appendix just documents what the book’s examples assume.
Minimal Linux-boot hart MUST
- Nothing architectural — this is a software ABI convention, not a hardware requirement
MAY simplify / trap-and-emulate
- Note for OS bring-up: the syscall-clobber rule means the kernel may reset vector state on syscall return; combined with mstatus.VS dirty tracking, this is what makes vector context-switch cost manageable
Check yourself — vector calling convention
1.Under the (placeholder) vector calling convention, which vector state is caller-saved?
2.What happens to vector state across a system call, and why?
2 questions