svaarala
port to RISC-V
Is anybody aware of any existing ports or plans to port Duktape to RISC-V architecture?
It's quite likely that Duktape will compile and work out-of-the-box for RISC-V.
Let me know if something fails. I'll try to see if I can get an environment running easily with e.g. https://wiki.qemu.org/Documentation/Platforms/RISCV.
I'll add explicit detection for RISC-V in any case, it'll also be useful if something doesn't work out of the box.
Any idea what would be the best preprocessor macros to detect RISC-V - e.g. these https://github.com/riscv/riscv-toolchain-conventions#cc-preprocessor-definitions?
I will try running it on 32bit RISC-V core with 64KiB of RAM. Will keep code here: https://github.com/drom/duktape-v
With that amount of memory you should use low memory options, especially ROM built-ins.
Also if you're running some minimal embedded OS, you may need to provide some missing libc functions (sometimes they omit math functions etc) or change the libc provider.
The QEMU RISC-V emulation seems very slow at present but I got it running and I can test basic compilation on a Linux RISC-V target hopefully tonight.
Ok, then the most important factor is getting the minimum required libc functions and IEEE math compatibility. The architecture has a smaller impact.
The first board that I want to try is: https://www.sifive.com/boards/hifive1-rev-b I can also try https://www.sifive.com/boards/hifive-unleashed Are you interested in getting these boards to try?
It might be easiest to first try compiling and running on the Linux-based large memory board just to see that the architecture itself works correctly, and then tackle the low memory board.
I was able to compile Duktape for RISC-V 64-bit on Qemu at least so the architecture probably doesn't need anything special. The 32-bit variant will by default use a packed duk_tval representation (8 bytes per value) which relies on IEEE double specifics. But as long as the compiler respects IEEE doubles, that shouldn't be an issue.
Re: boards, I'll be happy to help with e.g. testing or debugging a base port, with the time I have available (I work on Duktape on my free time).
@svaarala No, did not have a chance to produce anything useful. I tried it on my free time and got distracted. I still think RISC-V port would be a very healthy idea. And I hope I will get to it one day.
To my knowledge RISC-V should work out of the box, so I'm just lacking that confirmation :)