diff options
Diffstat (limited to '')
| -rw-r--r-- | results/scraper/box64/56 | 3 | ||||
| -rw-r--r-- | results/scraper/box64/562 | 2 | ||||
| -rw-r--r-- | results/scraper/box64/568 | 14 |
3 files changed, 19 insertions, 0 deletions
diff --git a/results/scraper/box64/56 b/results/scraper/box64/56 new file mode 100644 index 000000000..746ad196d --- /dev/null +++ b/results/scraper/box64/56 @@ -0,0 +1,3 @@ +oray_sunloginclient +I tried to install this software on my system, but it requires libgtk3, because of the dependencies of the package, I cannot install it. So I used packages.debian.org to manually search for the library files I needed. Its took me an afternoon. In the end, although I completed all the runtime libraries,but I still got an error. This is the output. +[a.txt](https://github.com/ptitSeb/box64/files/6815990/a.txt) diff --git a/results/scraper/box64/562 b/results/scraper/box64/562 new file mode 100644 index 000000000..e53d83085 --- /dev/null +++ b/results/scraper/box64/562 @@ -0,0 +1,2 @@ +[RV64] Implementing CALL/JMP +Seems that implementing CALL/JMP is quite challenging, as it involves dealing with cache and native call handling. @ptitSeb, would you be able to help us in implementing these instructions? For instance, if you could implement one of the CALL and JMP family instructions, then @xctan and I could proceed with implementing the rest. \ No newline at end of file diff --git a/results/scraper/box64/568 b/results/scraper/box64/568 new file mode 100644 index 000000000..2b378d8f2 --- /dev/null +++ b/results/scraper/box64/568 @@ -0,0 +1,14 @@ +[RV64] Problematic handling of overflow flag with ORI instruction +Upon reviewing my code of `emit_sar32c()`, I found that flags are forgotten to be shifted, and then discovered the fact that setting OF with ORI instruction is causing headache. + +RISC-V spec says that: + +> ANDI, ORI, XORI are logical operations that perform bitwise AND, OR, and XOR on register rs1 and the sign-extended 12-bit immediate and place the result in rd. + +Unfortunately, the overflow flag of x86 FLAGS register is located at the 12th least significant bit. If we try to do ORI with 0x0800, the immediate operand is actually 0xFFFFFFFFFFFFF800 (sign extend 0x0800 to 64 bits), thus destroying flags in higher bits. + +I've discussed some ideas with @ksco: + +1. `CLEAR_FLAGS` still works, and all flags are cleared. +2. 3 reserved flags exists in lower flag bits, so we may hack one of these. +3. flags higher than OF are not so useful, is there any chance that we can safely ignore them? \ No newline at end of file |