3 ms·

Risc-v is cool, I just wish there was an easier way to simulate it and try your code on. At the moment, I use a vscode extension but it’s very limited. The wor

Risc-v is cool, I just wish there was an easier way to simulate it and try your code on. At the moment, I use a vscode extension but it’s very limited. The workflow from writing your code to trying it in your microprocessor is slow.

brucehoult 3y ago
Weird thing to say! What do you call slow? bruce@i9:~$ cat hello.c #include <stdio.h> int main(){ printf("Hello world!\n"); return 0; } Cross-compiling and running in a local emulator: bruce@i9:~$ time (riscv64-unknown-elf-gcc hello.c -o hello; qemu-riscv64-static ./hello) Hello world! real 0m0.082s user 0m0.025s sys 0m0.010s Cross-compiling, copying to VisionFive 2 board, and running there: bruce@i9:~$ time (riscv64-unknown-elf-gcc hello.c -o hello; scp hello vf:;ssh vf ./hello) hello 100% 23KB 1.9MB/s 00:00 Hello world! real 0m0.812s user 0m0.086s sys 0m0.000s Compiling and running directly on the VisionFive 2: user@starfive:~$ time gcc hello.c -o hello real 0m0.193s user 0m0.149s sys 0m0.044s user@starfive:~$ time ./hello Hello world! real 0m0.006s user 0m0.002s sys 0m0.004s So cross compile and emulate on i9-13900HX is about twice faster than native compile and native run directly on the $50 RISC-V board ... under 0.1s vs almost exactly 0.2s. Adding in two invocations of OpenSSH (at ~0.35s each) to cross compile then run on the board does make it slower, but it's still under 1 second. This becomes the preferred method for very large programs.
- Alifatisk 3y ago
  I appreciate the examples you sent, I don't know why I didn't think of using the qemu emulator! The codebase I was in didn't use C but were pure risc-v assembly. The workflow from each change to running it consisted of the following steps: - Make your change (not too because you want to easily see when something went wrong) - Run the build script that compiles the code and sends it to the microcontroller - Restart the microcontroller - See the change This is what I had to do on every change I did on the code, debugging was even harder because I couldn't directly print out to the console because it was running on a microcontroller, not on my laptop. Your suggestions might improve the workflow further though. The closest thing I could get to debugging was to replicate the relevant assembly in vscode and using the risc-v simulator and walk through each step. But comparing this experience with, let's say, how you develop in Flutter, the feedback is instant.

brucehoult 3y ago

Weird thing to say! What do you call slow? bruce@i9:~$ cat hello.c #include <stdio.h> int main(){ printf("Hello world!\n"); return 0; } Cross-compiling and running in a local emulator: bruce@i9:~$ time (riscv64-unknown-elf-gcc hello.c -o hello; qemu-riscv64-static ./hello) Hello world! real 0m0.082s user 0m0.025s sys 0m0.010s Cross-compiling, copying to VisionFive 2 board, and running there: bruce@i9:~$ time (riscv64-unknown-elf-gcc hello.c -o hello; scp hello vf:;ssh vf ./hello) hello 100% 23KB 1.9MB/s 00:00 Hello world! real 0m0.812s user 0m0.086s sys 0m0.000s Compiling and running directly on the VisionFive 2: user@starfive:~$ time gcc hello.c -o hello real 0m0.193s user 0m0.149s sys 0m0.044s user@starfive:~$ time ./hello Hello world! real 0m0.006s user 0m0.002s sys 0m0.004s So cross compile and emulate on i9-13900HX is about twice faster than native compile and native run directly on the $50 RISC-V board ... under 0.1s vs almost exactly 0.2s. Adding in two invocations of OpenSSH (at ~0.35s each) to cross compile then run on the board does make it slower, but it's still under 1 second. This becomes the preferred method for very large programs.

Alifatisk 3y ago
I appreciate the examples you sent, I don't know why I didn't think of using the qemu emulator! The codebase I was in didn't use C but were pure risc-v assembly. The workflow from each change to running it consisted of the following steps: - Make your change (not too because you want to easily see when something went wrong) - Run the build script that compiles the code and sends it to the microcontroller - Restart the microcontroller - See the change This is what I had to do on every change I did on the code, debugging was even harder because I couldn't directly print out to the console because it was running on a microcontroller, not on my laptop. Your suggestions might improve the workflow further though. The closest thing I could get to debugging was to replicate the relevant assembly in vscode and using the risc-v simulator and walk through each step. But comparing this experience with, let's say, how you develop in Flutter, the feedback is instant.