lenary wrote:
To also respond to something earlier in the thread, where there is a little
complexity:
> The missing part is knowing how to split up that encoding value isn't it. For
> AArch64 you'd just print it because we only have 32-bit, Intel you would roll
> dice to randomly decide what
lenary wrote:
> Doesn't seem the ideal format given that we have a known size, today most
> often 16/32/64, and I guess 48 for funsies.
Standard instructions are right now only 16/32, but custom instructions can be
any multiple of 16. This was the change to llvm-objdump to group bytes like gnu
lenary wrote:
> I didn't realize that the riscv instructions had a scheme for indicating
> their lengths, very convenient.
It "doesn't". LLVM objdump implements the scheme described in the spec, but for
>32-bit instructions, that scheme is not ratified so it could change in the
future (the no
lenary wrote:
> We don't have any big endian riscv ArchSpec entry today or I'd add a big
> endian riscv instruction decoding test too.
We're starting to get Big Endian support for RISC-V in LLVM, but I've asked
that those patches wait until after the branch as there's a lot of work to make
bi
