RISC-V spec references the word 'hart' - what does 'hart' mean?

Question

I found references to hart on page 35 of the RISC-V 2.1 spec. However, I could not find a definition for hart in this document. Does hart refer to a hardware-thread or something more sinister?

Garibald

Yes, it's "hardware thread" - see en.wikipedia.org/wiki/RISC-V, for example. – Hitchcock

Ah yes......'hart' is elaborated in the other RiscV spec (riscv-privileged -v1.9.1). The user level spec (volume 1) could use a attribution to the privileged spec (volume II) when it comes to 'hart'. Maybe it is best to read these specs out of order - starting with volume II? Thanks. – Garibald

@Garibald FWIW, the manual is maintained in a github repo, you could submit a PR or an issue! UPDATE: there's already an issue lol – Debor

Answer 1

Yes, a hart is a hardware thread.

Cardinal

Thank you very much, kind of HARD to find. – Joke

Answer 2

A RISC-V compatible core might support multiple RISC-V-compatible hardware threads, or harts, through multithreading.

The RISC-V Instruction Set Manual
Volume I: Unprivileged ISA Document Version 20191214-draft
Page 2

Dandridge

Answer 3

In simple language, a hart is a RISC-V execution context that contains a full set of RISC-V architectural registers and that executes its program independently from other harts in a RISC-V system. What constitutes a "RISC-V system" depends on the software's execution environment but for standard user-level programs, it means the user-visible harts and memory (i.e., a multithreaded Unix user process). "Execute independently" means that each hart will eventually fetch and execute its next instruction in program order regardless of the activity of other harts (at least at user level).

This is closest answer I ever got after spending a lot of time to understand what 'hart' is https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/QKjUDjz_vKo

Scevour

Are you implying that a hart might be an illusion of the kernel, or something, and only run user-space software threads? I'm having a hard time imagining anything that could properly be called a hardware thread that didn't look (to kernel software) like a full CPU, so e.g. code on two separate harts could be running kernel code simultaneously. I could see having only one hart on a physical core actually handle external interrupts, although for preemptive multi-tasking you'd need every hart to be able to receive a timer interrupt or something. – Ethe

Sounds to me like "hart" is just trying to capture every possible SMT and related thing (en.wikipedia.org/wiki/Simultaneous_multithreading), the same concept that we describe as a "logical core" on other ISAs. – Ethe

@PeterCordes RISC-V defines a separate address space of 4096 for Control Status Registers address space of CSRs associated with each hart. Further, these CSRs are NOT memory mapped so it don't go through LD/STORE instead atomically read/modifiable by machine code. So hart and thread in software differs completely when you think of context switching and harts can't run simultaneously. Chapter 9 in unprivileged spec throws light on this. Its neither a conventional hardware or software thread instead a special breed. – Scevour

Its just a RISC-V execution context . – Scevour

Answer 4

From page 20 of the RISCV Spec v2.2:

We use the term hart to unambiguously and concisely describe a hardware thread as opposed to software-managed thread contexts.

Egression