8000 [RV64_DYNAREC] Added (81/83) SUB opcode by ksco · Pull Request #554 · ptitSeb/box64 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[RV64_DYNAREC] Added (81/83) SUB opcode #554

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Mar 13, 2023
Merged

[RV64_DYNAREC] Added (81/83) SUB opcode #554

merged 1 commit into from
Mar 13, 2023

Conversation

ksco
Copy link
Collaborator
@ksco ksco commented Mar 13, 2023

No description provided.

@ptitSeb ptitSeb merged commit 170ab57 into ptitSeb:main Mar 13, 2023
@ksco ksco deleted the rv64_dynarec_sub branch March 13, 2023 09:33
fengjixuchui added a commit to fengjixuchui/box64 that referenced this pull request Mar 13, 2023
@fengjixuchui
Merge pull request #1 from ptitSeb/main
04342e5 
[RV64_DYNAREC] Added (81/83) SUB opcode (ptitSeb#554)
@ptitSeb
Copy link
Owner
ptitSeb commented Mar 13, 2023 •
edited
Loading

Not sure since when, but the Dynarec is broken on RV64. Trying to run x86_64 7z v16.02 resulat in garbage on screen. I have not debugged yet the issue, and will not be abble to for several hours.

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

I'll take a look later.

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

Do you mean running 7z b? Looks normal on my end, it just stuck forever and takes 100% of the CPU. Exact behavior as version 38a5e55.

Dynarec for RISC-V PageSize:4096 Running on unknown riscv64 cpu with 8 Cores
Params database has 9 entries
Box64 with Dynarec v0.2.3 d70b2ab8 built on Mar 13 2023 17:30:52
Using default BOX64_LD_LIBRARY_PATH: ./:lib/:lib64/:x86_64/:bin64/:libs64/
Using default BOX64_PATH: ./:bin/
Counted 27 Env var
Looking for ../build/7z
argv[1]="b"
Rename process to "7z"
Using native(wrapped) libpthread.so.0
Using native(wrapped) libdl.so.2
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux-x86-64.so.2
Using native(wrapped) libutil.so.1
Using native(wrapped) librt.so.1
Using emulated libstdc++.so.6
Using emulated libgcc_s.so.1
Using native(wrapped) libm.so.6

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,64 bits,8 CPUs Box64 on unknown riscv64 cpu @1000 MHz (5000601),ASM,AES-NI)

Using emulated /root/box64/build/7z.so
          Box64 on unknown riscv64 cpu @1000 MHz (5000601)

@ptitSeb
Copy link
Owner
ptitSeb commented Mar 13, 2023

You need to wait more. It will show cpu speed and then will behave incrorectly.
But I did took a look and I think it's the end of the block that doesn't ask for X_PEND flags on inimplemented opcode. It should do that, so I'm working on a fix and see if it helps.

@ptitSeb
Copy link
Owner
ptitSeb commented Mar 13, 2023

Found the issue with the missing X_PEND at end of block and will push a fix (for ARM64 dynarec too, but it's less used there as the dynarec is mostly complete).

There is an issue with SUB tho.
Look at this dump:
image

0x3fa47b09a1: 83 AD 08 48 00 00 01 sub dword ptr [rbp+0x4808], 0x01
0x3fa47321ec: 12 emited opcodes, inst=2, barrier=2 state=3/0(0), set=3F/80, use=0, need=0/80, sm=0/0, pred=1
        000055b7        lui     a1, 0x5000
        80858593        addi    a1, a1, -2040
        00ba8633        add     a2, s5_rbp, a1
        00063583        ld      a1, 0(a2)
        36b52023        sw      a1, 864(a0)
        00100613        addi    a2, zero, 1
        36c52423        sw      a2, 872(a0)
        03000693        addi    a3, zero, 48
        34d53e23        sd      a3, 860(a0)
        fff58593        addi    a1, a1, -1
        36b52823        sw      a1, 880(a0)
        00b62023        sw      a1, 0(a2)
Stopping block 0x3fa47b099a (3 / 3)
Jump to next
  Table64: 0x3f9c030790
        00000697        auipc   a3, 0
        01c6b683        ld      a3, 28(a3)
  Table64: 0x3fa47b09a8
        00000317        auipc   t1_rip, 0
        01c33303        ld      t1_rip, 28(t1_rip)
        0006b603        ld      a2, 0(a3)
        00030593        addi    a1, t1_rip, 0
        000600e7        jalr    ra, 0(a2)
---- END OF BLOCK ---- (3)
5437|SIGSEGV @0x3fa4732218 (???(0x3fa4732218)) (x64pc=0x3fa47b09a2//root/Games/p7zip64_16/7z.so:"/root/Games/p7zip64_16/7z.so + 0x3999a", rsp=0x102fffca0, stack=0x102800000:0x103000000 own=0x102800000 fp=0x2), for accessing 0x1 (code=1/prot=0), db=0x3fa03a83c0(0x3fa47321e0:0x3fa4732278/0x3fa47b099a:0x3fa47b09a9//root/Games/p7zip64_16/7z.so + 0x3999a:clean, hash:7029a0f/7029a0f) handler=(nil)
RAX:0x00000000317f0000 RCX:0x0000000000000420 RDX:0x0000000000000001 RBX:0x0000003fa4698928 
RSP:0x0000000102fffca0 RBP:0x0000003fa469892c RSI:0x0000003fa4698946 RDI:0x0000003fa46640c8 
 R8:0x0000000062fe0000  R9:0x0000003fa4696bf0 R10:0x0000003fa14fd415 R11:0x0000000000000004 
R12:0x0000003fa46640c8 R13:0x0000000000000001 R14:0x0000000000000001 R15:0x0000003fa4696bf0 
RSP-0x20:0x0000000000000001 RSP-0x18:0x0000000000000001 RSP-0x10:0x0000003fa4696bf0 RSP-0x08:0x0000003fa47b0a49
RSP+0x00:0x0000003fa4664010 RSP+0x08:0x0000000000000004 RSP+0x10:0x0000000000000156 RSP+0x18:0x0000000000000001
`` 
You can see that `a2` is used to compute the `Ed` address, but is also used as a scratch in the sub function, and so it crashes at the `WBACK;`

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

Yes, I see the problem, I'll submit a fix later. It might be tricky with just 3 scratches in hand.

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

Also, just for curious, which RISC-V SBC are you using? I'm considering buy a more performant one.

@ptitSeb
Copy link
Owner
ptitSeb commented Mar 13, 2023

I'm using a Vision Five 2. OS is still young, and not everything works yet, but it's a nice board, and it's usable.

Do we need more scratch register?

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

Do we need more scratch register?

Let me try with 3 first and see how it goes.

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

Can we have 1 more scratch register?

@ptitSeb
Copy link
Owner
ptitSeb commented Mar 13, 2023

Yup. I have just pushed a commit with it (it was free). I can have 1 more, but no more after that I think.

@ksco
Copy link
Collaborator Author
ksco commented Mar 13, 2023

There is an issue with SUB tho.

Ok, one more question, how do I reproduce this?

@ptitSeb
Copy link
Owner
ptitSeb commented Mar 13, 2023

Still using 7z here. With more opcode, things will be easier to reproduce.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@ksco @ptitSeb
0