Skip to content
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

TriCore instruction loop16 #2386

Open
arkup opened this issue Jun 10, 2024 · 5 comments
Open

TriCore instruction loop16 #2386

arkup opened this issue Jun 10, 2024 · 5 comments
Labels
Milestone

Comments

@arkup
Copy link
Contributor

arkup commented Jun 10, 2024

Hi, while decoding the TriCore instruction loop16, the second operand is displayed in the format of a relative jump (not absolute), which is inconsistent with other instructions and, in my opinion (IMHO), makes it harder to read.

0x80000492: 04 FF | ld.bu d15, [a15+]
0x80000494: 24 4F | st.b [a4+], d15
0x80000496: FC 2E | loop a2, #-4               ;<===

Expected, preferred output:

0x80000492: 04 FF |  ld.bu d15, [a15+] 
0x80000494: 24 4F |  st.b [a4+], d15
0x80000496: FC 2E |  loop a2, 0x80000492       ;<===
Questions Answers
OS/arch/bits Windows x64 etc.
Architecture CS_ARCH_TRICORE, CS_MODE_TRICORE_162
Source of Capstone git clone,
Version/git commit v5.0.1, commit/3f87ce0f6a665abb2675adada507362985bb46a4

Instruction bytes giving faulty results

unsigned char loop_chars[] =
{
  0xFC, 0x2E
};

Expected results

loop16          a2, 0x...(absolut address)
@XVilka
Copy link
Contributor

XVilka commented Jun 11, 2024

@imbillow could you please take a look when you have time?

@Rot127 Rot127 added this to the v6 milestone Jun 12, 2024
@imbillow
Copy link
Contributor

Hi, while decoding the TriCore instruction loop16, the second operand is displayed in the format of a relative jump (not absolute), which is inconsistent with other instructions and, in my opinion (IMHO), makes it harder to read.

0x80000492: 04 FF | ld.bu d15, [a15+]
0x80000494: 24 4F | st.b [a4+], d15
0x80000496: FC 2E | loop a2, #-4               ;<===

Expected, preferred output:

0x80000492: 04 FF |  ld.bu d15, [a15+] 
0x80000494: 24 4F |  st.b [a4+], d15
0x80000496: FC 2E |  loop a2, 0x80000492       ;<===

Questions Answers
OS/arch/bits Windows x64 etc.
Architecture CS_ARCH_TRICORE, CS_MODE_TRICORE_162
Source of Capstone git clone,
Version/git commit v5.0.1, commit/3f87ce0f6a665abb2675adada507362985bb46a4

Instruction bytes giving faulty results

unsigned char loop_chars[] =
{
  0xFC, 0x2E
};

Expected results

loop16          a2, 0x...(absolut address)

The instruction you mention is LOOP (SBR), and its second operand is interpreted as a relative offset rather than an absolute address.

For more information, see TriCoreTM TC1.6.2 core architecture manual - Instruction set on page 3-179.

image

@imbillow
Copy link
Contributor

There is indeed another instruction with the same name LOOP in a different format but it has [0..7]=0xfd

@imbillow
Copy link
Contributor

imbillow commented Jun 16, 2024

I'm sorry I do not get it. But it is fixed in the next branch. @arkup

@arkup
Copy link
Contributor Author

arkup commented Jun 16, 2024

I'm sorry I do not get it. But it is fixed in the next branch. @arkup

OK, thanks. My point was that it's harder to read 'loop $reg, #-disp4' when I have to subtract disp4 from the loop $pc address in my head, instead of having an absolute address. In IDA/Ghidra, it's already formatted as an absolute address 'loop $reg, 0x???'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

4 participants