-
Notifications
You must be signed in to change notification settings - Fork 1k
Add support for RISC-V 64 Linux #1267
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v2.1
Are you sure you want to change the base?
Conversation
69d4d75
to
91fc8c5
Compare
91fc8c5
to
1893cf7
Compare
Copy ebuild from the main tree, update to last git commit, then add a patch [1] to support RISC-V. Link: LuaJIT/LuaJIT#1267 [1] Signed-off-by: Puqns67 <me@puqns67.icu>
Copy ebuild from the main tree, update to last git commit, then add a patch [1] to support RISC-V. Link: LuaJIT/LuaJIT#1267 [1] Signed-off-by: Puqns67 <me@puqns67.icu> Closes: #20 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org>
Hi, I've found that the #762 (#1308) affects this PR too. src/luajit -e 'print(pcall(pcall))'
Segmentation fault (core dumped) Instead of
The following patch fixes the issue for me: diff --git a/src/vm_riscv64.dasc b/src/vm_riscv64.dasc
index 791ea510..408d97bb 100644
--- a/src/vm_riscv64.dasc
+++ b/src/vm_riscv64.dasc
@@ -1483,10 +1483,11 @@ static void build_subroutines(BuildCtx *ctx)
| ld TMP1, L->maxstack
| add TMP2, BASE, NARGS8:RC
| bxltu TMP1, TMP2, ->fff_fallback
- | addi NARGS8:RC, NARGS8:RC, -8
+ | addi NARGS8:TMP0, NARGS8:RC, -8
| lbu TMP3, GL->hookmask
| mv TMP2, BASE
- | bxltz NARGS8:RC, ->fff_fallback
+ | bxltz NARGS8:TMP0, ->fff_fallback
+ | mv NARGS8:RC, NARGS8:TMP0
| addi BASE, BASE, 16
| // Remember active hook before pcall.
| srliw TMP3, TMP3, HOOK_ACTIVE_SHIFT |
be597a6
to
73a9765
Compare
I've found one more inconsistency for RISCV VM and JIT:
This happens due to the usage of I've work-arounded this with the following simple-minded patch for the VM and JIT: diff --git a/src/lj_asm_riscv64.h b/src/lj_asm_riscv64.h
index 94de47c6..79aaba08 100644
--- a/src/lj_asm_riscv64.h
+++ b/src/lj_asm_riscv64.h
@@ -1548,9 +1548,22 @@ static void asm_min_max(ASMState *as, IRIns *ir, int ismax)
{
if (irt_isnum(ir->t)) {
Reg dest = ra_dest(as, ir, RSET_FPR);
+ MCLabel l_ret_left, l_end;
Reg right, left = ra_alloc2(as, ir, RSET_FPR);
right = (left >> 8); left &= 255;
- emit_ds1s2(as, ismax ? RISCVI_FMAX_D : RISCVI_FMIN_D, dest, left, right);
+ l_end = emit_label(as);
+
+ if (dest != left)
+ emit_ds1s2(as, RISCVI_FMV_D, dest, left, left);
+ l_ret_left = emit_label(as);
+
+ emit_jmp(as, l_end);
+ if (dest != right)
+ emit_ds1s2(as, RISCVI_FMV_D, dest, right, right);
+
+ emit_branch(as, RISCVI_BNE, RID_TMP, RID_ZERO, l_ret_left, 0);
+ emit_ds1s2(as, RISCVI_FLT_D, RID_TMP, ismax ? right : left,
+ ismax ? left : right);
} else {
Reg dest = ra_dest(as, ir, RSET_GPR);
Reg left = ra_hintalloc(as, ir->op1, dest, RSET_GPR);
diff --git a/src/vm_riscv64.dasc b/src/vm_riscv64.dasc
index 916d662f..4c154694 100644
--- a/src/vm_riscv64.dasc
+++ b/src/vm_riscv64.dasc
@@ -1837,7 +1837,14 @@ static void build_subroutines(BuildCtx *ctx)
| bxgeu RA, RB, ->fff_resn
| checknum CARG2, >7
|6:
- | fpins FARG1, FARG1, FARG2
+ |.if ismax
+ | flt.d TMP0, FARG2, FARG1
+ |.else // min
+ | flt.d TMP0, FARG1, FARG2
+ |.endif
+ | bnez TMP0, >8 // skip swap
+ | fmv.d FARG1, FARG2
+ |8:
| addi RA, RA, 8
| j <5
|7: // Convert integer to number and continue above. |
Happy holidays!
I noticed the NaN issue about |
Other backends, for both interpreter and JIT, have converged on |
73a9765
to
7a40a6b
Compare
Hello @infiWang ,I am currently attempting to compile LuaJIT for the RISCV64 architecture and have applied the recent pull request. However, I am encountering compilation failures during the assembly stage. Could you please provide any guidance or instructions to help resolve these issues? I would greatly appreciate your assistance. Attached below is the compile log for your reference: buildvm_riscv.dasc:682: Error: bad expression |
AFAICT, you're building with Yocto SDK, which I haven't tested yet. This message indicates something is off about your assembler. I've just tested with Debian's GCC cross-toolchain, which works fine. My RISC-V board is down at the moment, but iirc, Clang should work too, though I'm not so sure about What SDK version are you using? I think detailed info about the compiler and assembler would be helpful. |
Also, where does the quotation mark at the end of the line come from? I don't see any complaints about |
Hello @infiWang, thank you for your reply. I am currently using Yocto SDK 3.1.13. Below are my environment variables:
Oh, this was just a mistake when copying and pasting; here is the correct log: Here is my process to compile luajit source:
buildvm_riscv.dasc:682: Error: bad expression buildvm_riscv.dasc:2559: Error: illegal operands I'm trying to compile the 'sysbench' project for my RISCV64 board, but I'm encountering failures when compiling the 'LuaJIT' project. Please help me; thank you very much. |
Please bump your Binutils to 2.37 or preferably higher. This version of Yocto uses Binutils 2.34 by default, while the If you have further questions, please open an issue in our downstream repository. |
Oh, I'm so sorry for my mistakes. I'm using Yocto SDK 3.1.31, not Yocto SDK 3.1.13, but I will try to upgrade binutils to a newer version. Thank you for your help. |
7a40a6b
to
8b01264
Compare
888970f
to
908607f
Compare
Current SIGILL handler appears to have weird issues with libluajit on some platform. Considering 6.6 kernel is becoming more common, switch to HWPROBE for better compatibility.
908607f
to
fd1422f
Compare
@infiWang - thank you for this work! We would like to leverage this directly from the official releases and as such we are very interested in what it will take to have this work merged upstream. |
Hi, I am Ruinland from Andes Technology and is currently serving as the host of System Library WG in RISE project. I am thinking that if I can help with the development here. The working model is that ones (member of RISE) could file a RFP (Request for Proposal) on certain project, for instance, LuaJIT with RISC-V support. TL;DR, Cordially yours, |
Thanks for your attention! Sorry for the late response.
@sabhiram - Upstream integration would ultimately depend on Mike Pall, who maintains a careful review process to ensure stability. While I've developed this v2.1 RISC-V 64 port independently, merging it upstream would need Mike's approval and sponsorship to Mike for ongoing maintenance.
@Ruinland – RISE's involvement would be extremely welcome! Formal sponsorship and a maintenance commitment through RISE could help address Mike's concerns about long-term support. I recognize Mike has also indicated RISC-V support as part of LuaJIT's future roadmap (v3.0). If upstream integration proves challenging under current circumstances, I'm happy to collaborate under RISE's umbrella to establish a downstream fork or upstream-aligned distribution to accelerate RISC-V availability. Would appreciate your guidance on next steps. |
It would be great to see formal sponsorship to accelerate RISC-V (64-bit) availability for projects like LuaJIT. I am personally interested in LuaJIT RISC-V (64-bit) because of Neovim. The latter is part of b-data's/my JupyterLab docker stacks which I intend to extend to I am already building Linux/RISC-V (64-bit) ports of I am also maintaining a triple-arch manifest ( Footnotes
|
This patchset adds full interpreter and backend support for RISC-V 64 G(IMAFD) with LP64D ABI on Linux, with compile-time/runtime extension support for RVC, Zba, Zbb, Zicond, XTheadBa, XTheadBb, XTheadCondMov and XTheadMac.
Thanks to Mike Pall, LuaJIT is well renowned for its accomplishments and performance in JIT compilers. As an undergraduate interested in RISC-V and compilers, I'm honored to have a chance to contribute to a production compiler. I also want to express my gratitude for the internship opportunity provided by PLCT Lab, ISCAS, which enabled me to this endeavor.
I would greatly value a review of my patch to catch my misses and for a better polish; Your feedback would be invaluable. Thank you for your time and consideration.