Imagine in a few years, when the small companies designing and licensing RISC-V cores are not that small anymore - folks like Amazon (uses ARM cores in their servers) and Apple might have a serious alternative. I believe that's because of the non-ARM stuff that Apple puts in their silicon efforts. aren't getting the same amount of performance. However, notice that Apple is the only one who is getting a lot done with ARM at the high end. Sure - looking at what Apple's silicon team is doing with ARM would make you think that ARM has nothing to worry about for a while. As one of the replies said, I was talking mostly about the IoT space, but I think it's true for the non-IoT laptop/server space as well. The one annoyance in all of the embedded toolkits when trying to use non-C/C++ languages is always CMake companies build component systems and such on top of it which a naive C compiler usage can’t really leverage, which means you end up rebuilding the whole build toolchain again.Įasier to just stick within CMake and use Nim’s C output instead, at least for now (until I get some time to write a nimscript parser for a subset of ESP-IDF’s CMake file format…) That said, if I was on the C3 or any of the RISC-V chips I’d look at using the C toolchain directly: you can easily have “nim c main.nim” call out to a specific C compiler with your specific build and linker flags! With #line macros injected into the compiled C output source files, JTAG debugging and other tools just work, which is quite nice. So the S3 is actually a Xtensa LX7 processor rather than a RISC-V one, but the process is the same: “-compileOnly” to output C sources from Nim, and point CMake to that nimcache output folder.
0 kommentar(er)
