diff options
Diffstat (limited to 'src/rv32.adoc')
| -rw-r--r-- | src/rv32.adoc | 69 |
1 files changed, 44 insertions, 25 deletions
diff --git a/src/rv32.adoc b/src/rv32.adoc index 9714df4..86f636e 100644 --- a/src/rv32.adoc +++ b/src/rv32.adoc @@ -3,7 +3,7 @@ This chapter describes the RV32I base integer instruction set. -[TIP] +[NOTE] ==== RV32I was designed to be sufficient to form a compiler target and to support modern operating system environments. The ISA was also designed @@ -174,7 +174,7 @@ bits in the instruction and have been allocated to reduce hardware complexity. In particular, the sign bit for all immediates is always in bit 31 of the instruction to speed sign-extension circuitry. -include::images/wavedrom/instruction_formats.adoc[] +include::images/wavedrom/instruction-formats.edn[] [[base_instr,Base instruction formats]] RISC-V base instruction formats. Each immediate subfield is labeled with the bit position (imm[x]) in the immediate value being produced, rather than the bit position within the instruction's immediate field as is usually done. @@ -201,7 +201,7 @@ to keep the ISA as simple as possible. There are a further two variants of the instruction formats (B/J) based on the handling of immediates, as shown in <<baseinstformatsimm>>. -include::images/wavedrom/immediate_variants.adoc[] +include::images/wavedrom/immediate-variants.edn[] [[baseinstformatsimm,Base instruction formats immediate variants.]] //.RISC-V base instruction formats showing immediate variants. @@ -222,9 +222,19 @@ formats and with each other. <<immtypes>> shows the immediates produced by each of the base instruction formats, and is labeled to show which instruction bit (inst[_y_]) produces each bit of the immediate value. + [[immtypes, Immediate types]] -.Types of immediate produced by RISC-V instructions. -include::images/wavedrom/immediate.adoc[] +include::images/wavedrom/i-immediate.edn[] + +include::images/wavedrom/s-immediate.edn[] + +include::images/wavedrom/b-immediate.edn[] + +include::images/wavedrom/u-immediate.edn[] + +.Types of immediate produced by RISC-V instructions. +include::images/wavedrom/j-immediate.edn[] + The fields are labeled with the instruction bits used to construct their value. Sign extensions always uses inst[31]. @@ -258,7 +268,7 @@ destination is register _rd_ for both register-immediate and register-register instructions. No integer computational instructions cause arithmetic exceptions. -[TIP] +[NOTE] ==== We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many @@ -291,7 +301,7 @@ comparing the results of ADD and ADDW on the operands. ==== Integer Register-Immediate Instructions -include::images/wavedrom/integer_computational.adoc[] +include::images/wavedrom/integer-computational.edn[] //.Integer Computational Instructions ADDI adds the sign-extended 12-bit immediate to register _rs1_. @@ -312,7 +322,7 @@ XOR on register _rs1_ and the sign-extended 12-bit immediate and place the result in _rd_. Note, XORI _rd, rs1, -1_ performs a bitwise logical inversion of register _rs1_ (assembler pseudoinstruction NOT _rd, rs_). -include::images/wavedrom/int-comp-slli-srli-srai.adoc[] +include::images/wavedrom/int-comp-slli-srli-srai.edn[] [[int-comp-slli-srli-srai]] //.Integer register-immediate, SLLI, SRLI, SRAI @@ -324,7 +334,7 @@ shifted into the lower bits); SRLI is a logical right shift (zeros are shifted into the upper bits); and SRAI is an arithmetic right shift (the original sign bit is copied into the vacated upper bits). -include::images/wavedrom/int-comp-lui-aiupc.adoc[] +include::images/wavedrom/int-comp-lui-aiupc.edn[] [[int-comp-lui-aiupc]] //.Integer register-immediate, U-immediate @@ -364,7 +374,7 @@ the _rs1_ and _rs2_ registers as source operands and write the result into register _rd_. The _funct7_ and _funct3_ fields select the type of operation. -include::images/wavedrom/int_reg-reg.adoc[] +include::images/wavedrom/int-reg-reg.edn[] [[int-reg-reg]] //.Integer register-register @@ -383,7 +393,7 @@ the lower 5 bits of register _rs2_. ==== NOP Instruction -include::images/wavedrom/nop.adoc[] +include::images/wavedrom/nop.edn[] [[nop]] //.NOP instructions @@ -444,7 +454,7 @@ than the regular link register. Plain unconditional jumps (assembler pseudoinstruction J) are encoded as a JAL with _rd_=`x0`. -include::images/wavedrom/ct-unconditional.adoc[] +include::images/wavedrom/ct-unconditional.edn[] [[ct-unconditional]] //.The unconditional-jump instruction, JAL @@ -456,7 +466,13 @@ instruction following the jump (`pc`+4) is written to register _rd_. Register `x0` can be used as the destination if the result is not required. -include::images/wavedrom/ct-unconditional-2.adoc[] +Plain unconditional indirect jumps (assembler pseudoinstruction JR) are +encoded as a JALR with _rd_=`x0`. +Procedure returns in the standard calling convention (assembler +pseudoinstruction RET) are encoded as a JALR with _rd_=`x0`, _rs1_=`x1`, and +_imm_=0. + +include::images/wavedrom/ct-unconditional-2.edn[] [[ct-unconditional-2]] //.The indirect unconditional-jump instruction, JALR @@ -550,7 +566,7 @@ is sign-extended and added to the address of the branch instruction to give the target address. The conditional branch range is ±4 KiB. -include::images/wavedrom/ct-conditional.adoc[] +include::images/wavedrom/ct-conditional.edn[] [[ct-conditional]] //.Conditional branches @@ -581,7 +597,7 @@ a conditional branch instruction with an always-true condition. RISC-V jumps are also PC-relative and support a much wider offset range than branches, and will not pollute conditional-branch prediction tables. -[TIP] +[NOTE] ==== The conditional branches were designed to include arithmetic comparison operations between two registers (as also done in PA-RISC, Xtensa, and @@ -666,7 +682,7 @@ even though the load value is discarded. The EEI will define whether the memory system is little-endian or big-endian. In RISC-V, endianness is byte-address invariant. -[TIP] +[NOTE] ==== In a system for which endianness is byte-address invariant, the following property holds: if a byte is stored to memory at some address @@ -686,7 +702,7 @@ significance. Loads similarly transfer the contents of the greater memory byte addresses to the less-significant register bytes. ==== -include::images/wavedrom/load_store.adoc[] +include::images/wavedrom/load-store.edn[] [[load-store,load and store]] //.Load and store instructions @@ -731,7 +747,7 @@ by address misalignment result in a contained trap (allowing software running inside the execution environment to handle the trap) or a fatal trap (terminating execution). -[TIP] +[NOTE] ==== Misaligned accesses are occasionally required when porting legacy code, and help performance on applications when using any form of packed-SIMD @@ -775,7 +791,7 @@ are aligned. [[fence]] === Memory Ordering Instructions -include::images/wavedrom/mem_order.adoc[] +include::images/wavedrom/mem-order.edn[] [[mem-order]] //.Memory ordering instructions @@ -853,7 +869,7 @@ Base implementations shall treat all such reserved configurations as normal fences with _fm_=0000, and standard software shall use only non-reserved configurations. -[TIP] +[NOTE] ==== We chose a relaxed memory model to allow high performance from simple machine implementations and from likely future coprocessor or @@ -865,6 +881,7 @@ ignore the _predecessor_ and _successor_ fields and always execute a conservative fence on all operations. ==== +[[ecall-ebreak]] === Environment Call and Breakpoints `SYSTEM` instructions are used to access system functionality that might require privileged access and are encoded using the I-type instruction @@ -875,7 +892,7 @@ described in <<csrinsts>>, and the base unprivileged instructions are described in the following section. -[TIP] +[NOTE] ==== The SYSTEM instructions are defined to allow simpler implementations to always trap to a single software trap handler. More sophisticated @@ -883,7 +900,7 @@ implementations might execute more of each system instruction in hardware. ==== -include::images/wavedrom/env_call-breakpoint.adoc[] +include::images/wavedrom/env-call-breakpoint.edn[] [[env-call]] //.Environment call and breakpoint instructions @@ -906,7 +923,7 @@ to reflect that they can be used more generally than to call a supervisor-level operating system or debugger. ==== -[TIP] +[NOTE] ==== EBREAK was primarily designed to be used by a debugger to cause execution to stop and fall back into the debugger. EBREAK is also used @@ -924,7 +941,7 @@ to distinguish a semihosting EBREAK from a debugger inserted EBREAK. .... slli x0, x0, 0x1f # Entry NOP ebreak # Break to debugger - srai x0, x0, 7 # NOP encoding the semihosting call number 7 + srai x0, x0, 7 # Exit NOP .... Note that these three instructions must be 32-bit-wide instructions, @@ -986,7 +1003,7 @@ HINT space is reserved for standard HINTs. The remainder of the HINT space is designated for custom HINTs: no standard HINTs will ever be defined in this subspace. -[TIP] +[NOTE] ==== We anticipate standard hints to eventually include memory-system spatial and temporal locality hints, branch prediction hints, thread-scheduling @@ -1063,3 +1080,5 @@ hints, security tags, and instrumentation flags for simulation/emulation. |SLTU |_rd_=`x0` |latexmath:[$2^{10}$] |=== +TIP: When allocating `slli x0, x0, 0x1f` or `srai x0, x0, 7` as custom HINTs, +take note of their use in semihosting calls, as described in <<ecall-ebreak>>. |