RFR: 8285711: riscv: RVC: Support disassembler show-bytes option

[Xiaolin Zheng]

On Fri, 29 Apr 2022 03:11:57 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> When RVC (under which instruction size could become 2-byte) is enabled currently, the disassembler 'show-bytes' output is not right, for `Assembler::instr_len` doesn't get adjusted.
>> 
>> Using `-XX:+UnlockExperimentalVMOptions -XX:+UseRVC -XX:+UnlockDiagnosticVMOptions -XX:+PrintAssembly -XX:PrintAssemblyOptions=no-aliases,numeric,show-bytes -XX:+PrintAssembly`
>> 
>> Before: (wrong)
>> 
>> ...
>> 0x000000401354f9bc: 9722 4107  | auipc  x5,0x7412                               ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>>   0x000000401354f9c0: e780 4210  | jalr  x1,260(x5) # 0x000000401a961ac0
>>   0x000000401354f9c4: 1571 06e0  | c.addi16sp  x2,-224
>>   0x000000401354f9c6: 06e0 16e4  | c.sdsp  x1,0(x2)
>>   0x000000401354f9c8: 16e4 1ae8  | c.sdsp  x5,8(x2)
>>   0x000000401354f9ca: 1ae8 1eec  | c.sdsp  x6,16(x2)
>>   0x000000401354f9cc: 1eec 22f0  | c.sdsp  x7,24(x2)
>>   0x000000401354f9ce: 22f0 26f4  | c.sdsp  x8,32(x2)
>>   0x000000401354f9d0: 26f4 2af8  | c.sdsp  x9,40(x2)
>> ...
>> 
>> 
>> After: (right)
>> 
>> 0x0000004013546c2c: 97a2 4107  | auipc  x5,0x741a                               ;   {runtime_call handle_exception_from_callee Runtime1 stub}
>>   0x0000004013546c30: e780 42b9  | jalr  x1,-1132(x5) # 0x000000401a9607c0
>>   0x0000004013546c34: 1571    | c.addi16sp  x2,-224
>>   0x0000004013546c36: 06e0    | c.sdsp  x1,0(x2)
>>   0x0000004013546c38: 16e4    | c.sdsp  x5,8(x2)
>>   0x0000004013546c3a: 1ae8    | c.sdsp  x6,16(x2)
>>   0x0000004013546c3c: 1eec    | c.sdsp  x7,24(x2)
>>   0x0000004013546c3e: 22f0    | c.sdsp  x8,32(x2)
>>   0x0000004013546c40: 26f4    | c.sdsp  x9,40(x2)
>> 
>> 
>> The [RISC-V ISA manual](https://github.com/riscv/riscv-isa-manual/blob/04cc07bccea63f6587371b6c75b228af3e5ebb02/src/intro.tex#L630-L635) reads, 
>>> We have to fix the order in which instruction parcels are stored in memory, independent of memory system endianness, to ensure that **the length-encoding bits always appear first in halfword address order**. This allows the length of a variable-length instruction to be quickly determined by an instruction-fetch unit by examining only the first few bits of the first 16-bit instruction parcel.
>> 
>> Instructions are stored in little-endian order, and in that only the first 16-bit matters, we could just check if the lowest 2 bits of it to detect the instruction length. 
>> (48-bit and 64-bit instructions are not supported yet in the current backend)
>> (extracting an `is_compressed_instr`, for this might get used in the future)
>> 
>> Thanks,
>> Xiaolin
>
> src/hotspot/cpu/riscv/assembler_riscv.hpp line 277:
> 
>> 275:   static bool is_compressed_instr(address instr) {
>> 276:     if (UseRVC && (((uint16_t *)instr)[0] & 0b11) != 0b11) {
>> 277:       // 16-bit instructions end with 0b00, 0b01, and 0b10
> 
> Looks like the comments is not correct here? We are checking the start instead of the end of the instruction encoding here. Suggestion: 
> "16-bit instruction encoding starts with 0b00, 0b01, and 0b10"

Thank you! The viewpoint might be different -- I was looking at the encoding graph, and it's bits `31 30 ... 3 2 1 0` so I used 'end with'; but 'start with' is also definitely correct because it's bits 0 and 1. So I checked the manual and was wondering if using its words ['lowest two bits'](https://github.com/riscv/riscv-isa-manual/blob/04cc07bccea63f6587371b6c75b228af3e5ebb02/src/intro.tex#L478-L482) might be more official?

-------------

PR: https://git.openjdk.java.net/jdk/pull/8421