-
Notifications
You must be signed in to change notification settings - Fork 31
Getting Started for RV32G porting
-
Set the code base
- follow the Get-the-Source
- in the v8 directory:
bash git remote add riscv-v8 https://github.com/riscv-collab/v8 && git fetch riscv-v8 && git checkout RV32G
-
make a simulator build by cmd line:
tools/dev/gm.py riscv32.debug
-
prepare a hello.js case as:
console.log("hello")
-
launch the d8 shell and test the hello.js
cd ./out/riscv32.debug && ./d8 hello.js
-
What's expected for the d8 shell running? Because we haven't port any backend code yet, the instruction-selector, code-gen and macro-assembler would still generate RV64 instructions but the ported simulator can't support these 64bit instructions, so simulator would abort due to unsupported instructions, logging out something like:
Sim: Unsupported instruction. Func:DecodeRVIType Line:4647
Trace/breakpoint trap
Yes, this abort message is uninformative, hard to diagnose the details.
- How to get more info?
With this PR, the modify in src/diagnostics/riscv32/disasm-riscv32.cc opens the disassembler for RV64 instructions, and the modify in src/execution/riscv32/simulator-riscv32.cc outputs the disassembled instruction with both binary and human readable string for debug.
After this PR merged, if you build and run d8 again, you will get another abort info like this:
Sim: Unsupported instruction. Func:DecodeRVIType Line:4647 000aba03 ld s4, 0(s5)
Trace/breakpoint trap
Yes, now we know a 64bit ld is generated, this is what we need to check and modified in next steps.
- How to get more and more info then? We can use the helpful debug options of d8:
./d8 --trace-sim hello.js
then we will get a verbose logging like:
CallImpl: reg_arg_count = 6 entry-pc (JSEntry) = 0xf4d53860 a0 (Isolate-root) = 0x57e35780 a1 (orig_func/new_target) = 0x9882339 a2 (func/target) = 0x2e3d36dd a3 (receiver) = 0x2e3c35b9 a4 (argc) = 0x2 a5 (argv) = 0xffffffffffd569c0
0x0000f4d53860 fcc10113 addi sp, sp, -52 ffffffffe9ce7f8c (1) int64:-372342900 uint64:18446744073337208716
0x0000f4d53864 02112823 sw ra, 48(sp) (2) int32:-2 uint32:4294967294 --> [addr: ffffffffe9ce7fbc]
0x0000f4d53868 02812623 sw fp, 44(sp) (3) int32:0 uint32:0 --> [addr: ffffffffe9ce7fb8]
0x0000f4d5386c 03b12423 sw s11, 40(sp) (4) int32:0 uint32:0 --> [addr: ffffffffe9ce7fb4]
0x0000f4d53870 03a12223 sw s10, 36(sp) (5) int32:0 uint32:0 --> [addr: ffffffffe9ce7fb0]
0x0000f4d53874 03912023 sw s9, 32(sp) (6) int32:0 uint32:0 --> [addr: ffffffffe9ce7fac]
0x0000f4d53878 01812e23 sw s8, 28(sp) (7) int32:0 uint32:0 --> [addr: ffffffffe9ce7fa8]
0x0000f4d5387c 01712c23 sw s7, 24(sp) (8) int32:0 uint32:0 --> [addr: ffffffffe9ce7fa4]
0x0000f4d53880 01612a23 sw s6, 20(sp) (9) int32:0 uint32:0 --> [addr: ffffffffe9ce7fa0]
0x0000f4d53884 01512823 sw s5, 16(sp) (10) int32:0 uint32:0 --> [addr: ffffffffe9ce7f9c]
0x0000f4d53888 01412623 sw s4, 12(sp) (11) int32:0 uint32:0 --> [addr: ffffffffe9ce7f98]
0x0000f4d5388c 01312423 sw s3, 8(sp) (12) int32:0 uint32:0 --> [addr: ffffffffe9ce7f94]
0x0000f4d53890 01212223 sw s2, 4(sp) (13) int32:0 uint32:0 --> [addr: ffffffffe9ce7f90]
0x0000f4d53894 00912023 sw s1, 0(sp) (14) int32:0 uint32:0 --> [addr: ffffffffe9ce7f8c]
0x0000f4d53898 fa010113 addi sp, sp, -96 ffffffffe9ce7f2c (15) int64:-372342996 uint64:18446744073337208620
......
0x0000f4d538b8 03413027 fsd fs4, 32(sp) (23) dbl:0.000000e+00 --> [addr: ffffffffe9ce7f4c]
0x0000f4d538bc 01313c27 fsd fs3, 24(sp) (24) dbl:0.000000e+00 --> [addr: ffffffffe9ce7f44]
0x0000f4d538c0 01213827 fsd fs2, 16(sp) (25) dbl:0.000000e+00 --> [addr: ffffffffe9ce7f3c]
0x0000f4d538c4 00913427 fsd fs1, 8(sp) (26) dbl:0.000000e+00 --> [addr: ffffffffe9ce7f34]
0x0000f4d538c8 00813027 fsd fs0, 0(sp) (27) dbl:0.000000e+00 --> [addr: ffffffffe9ce7f2c]
0x0000f4d538cc d2000cd3 fcvt.d.w fs9, zero_reg 0000000000000000 (28) dbl:0.000000e+00
0x0000f4d538d0 00050b13 mv s6, a0 0000000057e35780 (29) int64:1474516864 uint64:1474516864
......
Sim: Unsupported instruction. Func:DecodeRVIType Line:4647 000aba03 ld s4, 0(s5)
Trace/breakpoint trap
From the log we can know that the execution flow is at builtin JSEntry, which can be further referred to src/builtins/riscv32/builtins-riscv32.cc's Generate_JSEntryVariant. Then we can check how the ld come from in this function.
- Home
- Getting Started
- Project Management
- For Developers
- RISC-V Backend Design Doc
- Community operation