I have been working on patches for compiling Swift 5.6 for RISCV64 with Buildroot. First I compiled the patched compiler (swift, llvm-project and swift-core-tools-support) and then use Buildroot with patched compiler to cross compiler the Swift Stdlib. I have gotten to the point where I can successfully compile libdispatch, the Swift StdLib and runtime's .c, .cpp and .swift files for RISCV64, but the linking stage for the StdLib fails.
ld.lld: error: stdlib/public/core/LINUX/riscv64/Swift.o: cannot link object files with different floating-point ABI
ld.lld: error: Swift.o.text+0x0): relocation R_RISCV_ALIGN requires unimplemented linker relaxation; recompile with -mno-relax
I have tried a lot of Swift compiler flags based on Every Option and Flag /swift (1.2) Accepts Ever · GitHub and passing them via -DSWIFT_STDLIB_EXTRA_SWIFT_COMPILE_FLAGS to cmake for cross compiling the StdLib but none seem to work.
Amazing work!, @ColemanCDA. This has so much potential!
As a matter of fact, I just recently started to get into microcontrollers. In particular I'm supposed to write the firmware for an ESP32-C3 (RISCV32) based device and would love to use Swift rather than C and C++.
How similar are RISCV32 and RISCV64? What would it take to enhance your patch to also support RISCV32?
The issue is, RISCV32 is tipically not Linux capable and lacking MMU. The ISA itself is not an issue, it's the devices you can buy with that ISA not being designed for Linux. If you find a RISCV32 devices that can run Linux, let me know and I'll try to build Swift for it.
I see. Well, the devices I'm interested in are MCUs anyways. I guess what I'm really after is to expand Swift On Arduino to more platforms, i.e. ESP32-C3 (RISCV32).
I've built a patched 5.7.1 compiler and have an example with Buildroot cross compiling the Swift StdLib. libswiftdispatch is currently failing to build.
I don't think we can proceed unless Swift engineers are willing to commit to the implementation as they have a stable ABI that they want to maintain. This likely means proposing doc changes, and getting them reviewed by the Swift community, but maybe more than that. I believe the Swift community should have enough overlap with LLVM that they can confirm they want to maintain what you are proposing.
For more context, today you can compile Embedded Swift for RISC-V 32 bit, but compiling standard Swift, e.g. (for an OS like Linux instead of bare metal) crashes the compiler. My patches add basic support but deliberately reuses the C convention and pins nothing to registers.