| Message ID | 20190523150803.31504-1-richard.henderson@linaro.org |
|---|---|
| Headers | show |
| Series | target/rx: Improvements to disassembly | expand |
On Fri, 24 May 2019 00:07:57 +0900, Richard Henderson wrote: > > Here's a sample of the new output, taken from u-boot.bin: > > IN: > 0xfff8000a: fb 12 00 01 00 00 mov.l #0x00000100, r1 > 0xfff80010: fb 32 f0 13 00 00 mov.l #0x000013f0, r3 > 0xfff80016: 43 13 sub r1, r3 > 0xfff80018: fb 22 00 ea f9 ff mov.l #-398848, r2 > 0xfff8001e: 7f 8f smovf > 0xfff80020: ef 01 mov.l r0, r1 > 0xfff80022: 05 1e 32 00 bsr.a fff83240 > > IN: > 0xfff83240: 72 11 5c fb add #-1188, r1 > 0xfff83244: 75 21 f0 and #-16, r1 > 0xfff83247: 02 rts > > Obviously there are still a few inconsistencies in the > format strings used for the immediates, but the format > is readable and it is easy to look at the opcode to see > how our decode compares to the manual. > Hmm. The output of the immediate value should be the same as the output of objdump. I do not think that it is the proper format, but I did that because it was useful for comparing the results. > > r~ > > > Richard Henderson (6): > target/rx: Disassemble rx_index_addr into a string > target/rx: Replace operand with prt_ldmi in disassembler > target/rx: Use prt_ldmi for XCHG_mr disassembly > target/rx: Emit all disassembly in one prt() > target/rx: Collect all bytes during disassembly > target/rx: Dump bytes for each insn during disassembly > > target/rx/disas.c | 366 +++++++++++++++++++++------------------------- > 1 file changed, 166 insertions(+), 200 deletions(-) > > -- > 2.17.1 > -- Yosinori Sato
On May 27, 2019 5:44 PM, "Yoshinori Sato" <ysato@users.sourceforge.jp> wrote: > > On Fri, 24 May 2019 00:07:57 +0900, > Richard Henderson wrote: > > > > Here's a sample of the new output, taken from u-boot.bin: > > > > IN: > > 0xfff8000a: fb 12 00 01 00 00 mov.l #0x00000100, r1 > > 0xfff80010: fb 32 f0 13 00 00 mov.l #0x000013f0, r3 > > 0xfff80016: 43 13 sub r1, r3 > > 0xfff80018: fb 22 00 ea f9 ff mov.l #-398848, r2 > > 0xfff8001e: 7f 8f smovf > > 0xfff80020: ef 01 mov.l r0, r1 > > 0xfff80022: 05 1e 32 00 bsr.a fff83240 > > > > IN: > > 0xfff83240: 72 11 5c fb add #-1188, r1 > > 0xfff83244: 75 21 f0 and #-16, r1 > > 0xfff83247: 02 rts > > > > Obviously there are still a few inconsistencies in the > > format strings used for the immediates, but the format > > is readable and it is easy to look at the opcode to see > > how our decode compares to the manual. > > > > Hmm. > The output of the immediate value should be the same as the output of objdump. > I do not think that it is the proper format, but I did that because > it was useful for comparing the results. > We in MIPS also use objdump output as the reference and desired output for QEMU disassembler (not that we are always succeeding in doing that) Inventing propriatery QEMU output for some instructions is in my view counterproductive and confusing. Sincerely, Aleksandar > > > > r~ > > > > > > Richard Henderson (6): > > target/rx: Disassemble rx_index_addr into a string > > target/rx: Replace operand with prt_ldmi in disassembler > > target/rx: Use prt_ldmi for XCHG_mr disassembly > > target/rx: Emit all disassembly in one prt() > > target/rx: Collect all bytes during disassembly > > target/rx: Dump bytes for each insn during disassembly > > > > target/rx/disas.c | 366 +++++++++++++++++++++------------------------- > > 1 file changed, 166 insertions(+), 200 deletions(-) > > > > -- > > 2.17.1 > > > > -- > Yosinori Sato >
On Tue, 28 May 2019 02:47:40 +0900, Aleksandar Markovic wrote: > > On May 27, 2019 5:44 PM, "Yoshinori Sato" <ysato@users.sourceforge.jp> > wrote: > > > > On Fri, 24 May 2019 00:07:57 +0900, > > Richard Henderson wrote: > > > > > > Here's a sample of the new output, taken from u-boot.bin: > > > > > > IN: > > > 0xfff8000a: fb 12 00 01 00 00 mov.l #0x00000100, r1 > > > 0xfff80010: fb 32 f0 13 00 00 mov.l #0x000013f0, r3 > > > 0xfff80016: 43 13 sub r1, r3 > > > 0xfff80018: fb 22 00 ea f9 ff mov.l #-398848, r2 > > > 0xfff8001e: 7f 8f smovf > > > 0xfff80020: ef 01 mov.l r0, r1 > > > 0xfff80022: 05 1e 32 00 bsr.a fff83240 > > > > > > IN: > > > 0xfff83240: 72 11 5c fb add #-1188, r1 > > > 0xfff83244: 75 21 f0 and #-16, r1 > > > 0xfff83247: 02 rts > > > > > > Obviously there are still a few inconsistencies in the > > > format strings used for the immediates, but the format > > > is readable and it is easy to look at the opcode to see > > > how our decode compares to the manual. > > > > > > > Hmm. > > The output of the immediate value should be the same as the output of > objdump. > > I do not think that it is the proper format, but I did that because > > it was useful for comparing the results. > > > > We in MIPS also use objdump output as the reference and desired output for > QEMU disassembler (not that we are always succeeding in doing that) > > Inventing propriatery QEMU output for some instructions is in my view > counterproductive and confusing. > > Sincerely, > Aleksandar I also considered it. Although the opcodes of RX were licensed as GPLv3, they were not usable as they were. > > > > > > > r~ > > > > > > > > > Richard Henderson (6): > > > target/rx: Disassemble rx_index_addr into a string > > > target/rx: Replace operand with prt_ldmi in disassembler > > > target/rx: Use prt_ldmi for XCHG_mr disassembly > > > target/rx: Emit all disassembly in one prt() > > > target/rx: Collect all bytes during disassembly > > > target/rx: Dump bytes for each insn during disassembly > > > > > > target/rx/disas.c | 366 +++++++++++++++++++++------------------------- > > > 1 file changed, 166 insertions(+), 200 deletions(-) > > > > > > -- > > > 2.17.1 > > > > > > > -- > > Yosinori Sato > > -- Yosinori Sato
On 5/27/19 10:39 AM, Yoshinori Sato wrote: > On Fri, 24 May 2019 00:07:57 +0900, > Richard Henderson wrote: >> Obviously there are still a few inconsistencies in the >> format strings used for the immediates, but the format >> is readable and it is easy to look at the opcode to see >> how our decode compares to the manual. >> > > Hmm. > The output of the immediate value should be the same as the output of objdump. > I do not think that it is the proper format, but I did that because > it was useful for comparing the results. This is a fair comment. Of course, we could also simultaneously fix inconsistencies in objdump. I doubt that any of these cases are intentionally different. Something for later, perhaps. r~