1. The working state machine of the RISCV processor
When the RISCV processor is working, there are three major working scenarios, namely, normal working, low-power working and debugging. When the transition conditions are met, transitions can occur between different states.
Under normal working conditions, the processor can be divided into three modes (for RISCV IP that implements virtualization "H", there are four).
Note that some state transitions will not occur. For example, the user mode cannot directly enter the low-power state, and the WFI command can be executed in S or M mode to enter. The execution of WFI in S mode also requires mstatus.tw==0.
For example, debugging is not possible in a low-power state, but in normal work, no matter what mode the processor is in, it can be debugged and so on.
2. RISCV processor working mode conversion
3. Thinking about running RV32I program on RV64I bit machine.
With reference to other architectures, there are basically only two paths, hardware and software.
- The processor hardware level is compatible with 32-bit mode. In this way, the software does not need to be changed. The hardware 32-bit mode is the same as the 32-bit processor. For example, AARCH64 is compatible with 32-bit applications. Since the program is still running 32-bit ISA, the previous 32-bit binary can be run directly.
- The software method is more troublesome. It requires that the instruction set of the program is still 64-bit, but the pointer type and long type must be compiled to a 32-bit length, which requires modification of the compiler, kernel, C library, etc. Code, the implementation workload is huge. The advantage is that there is no need to change the hardware. There are x86-32, MIPS n32, ILP32 mode of AACH64, etc. Among them, MIPS is more thorough. Its mips-o32 abi can also ensure that the binary runs on 64-bit machines without modification, and n32 is mainly to solve the problem of using 64 The problem of running 32-bit code with the bit ISA feature.
Basically, the relationship between the instruction sets of RISCV32 and RISCV64 is as follows. Most of the instructions are defined in common with RV64 and RV32, and have exactly the same encoding, but RV64 discards some of the RV32 instructions and frees up the encoding for definition. A new instruction format is introduced, which will cause binary incompatibility.
The definition differences of some instructions under the two architectures:
According to the spec, the high-level mxl of misa can control whether it runs on the 32-bit or 64-bit architecture, but qemu does not support it. I believe most vendors do not support it:
4. About interrupt control and state logic in Supervisor mode.
5. Questions about the compiler and 32/64 bit support
6.The problem of FPU Context protection.
7:context switch , callee and caller reigster.
8: Main interrupt and main exception distribution:
9: Some records about compilation optimization options:
10: RV ISA system register design has an obvious feature, that is, some registers have different names at different run levels, but all correspond to the physical register implementation in the same micro-architecture. The following is a summary.
11: About the pre-processing of entering the exception
12: About delegated exceptions and interruptions
12: Analyze the execution actions of mret and sret from the qemu code.
13: Memory access problem in M mode, observed by qemu code. MMU page table translation function is disabled by default in M mode. However, you can set mstatus.MPRV to 1, and set mstatus.MPP to S in cooperation Mode or U mode to access the virtual address of S mode or U mode through MMU. This accessible form only applies to data access, and has no effect on the instruction fetch. This seemingly alternative design method is actually not uncommon, and it can be seen in SPARC, IBM z/ARCH, and power. It's just that we have less contact.
14: About FS, XS and Context Save/Restore
