Skip to content

Getting Started for RV32G porting

qjivy edited this page Apr 12, 2022 · 2 revisions
  • 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.