IRC channel logs

<matrix_bridge><gtker> stikonas: Interesting. I wasn't aware that the RISC-V implementation had special behavior in that way. I'm not entirely sure that it would work 100%. The aarch64 instructions don't really have a predictable encoding so we would need several different "rd_x0" defines that would be required for different instructions. I personally won't be doing any major changes. With bas we have a GAS-compatible assembler...

<matrix_bridge>... available immediately after cc_*, so I don't really see a reason for further complicating M1

<matrix_bridge><Andrius Štikonas> gtker: do you how does GAS then decide which hex to use then?

<matrix_bridge><Andrius Štikonas> a lot of if/else?

<matrix_bridge><gtker> stikonas: Basically yes, https://codeberg.org/gtker/bas/src/commit/9d5db8c4e9ef07e3bcb2c59ec179798fe5f6425d/src/aarch64.c#L1503 There are some categories but it is essentially just figuring out how that specific instruction is encoded https://codeberg.org/gtker/bas/src/commit/9d5db8c4e9ef07e3bcb2c59ec179798fe5f6425d/src/aarch64.c#L1372.

<stikonas>well, bas is better than . operator anyway

<matrix_bridge><gtker> That's what I'm thinking. It also prevents applications from having to manually handle e.g. RISC-V loading immediates with 2 instructions

<stikonas>on riscv opcodes have specific value that is then just xored with register value (which depends on position but still just 3x number of registers)

<matrix_bridge><gtker> Yeah, the RISC-V instructions pretty neatly fit into a few categories. The aarch64 ones do not 😄

<stikonas>oh yes, loading immediates is annoying with low level M1 defines

<stikonas>I haven't looked that much into aarch64 instruction encoding...

<stikonas>but on the other hand, early RISC-V hex programs are very hard to write

<stikonas>updating e.g. hex0_x86.hex0 is much easier

<matrix_bridge><gtker> Even updating codegen for M2-Planet can at times be pretty daunting for armv7l and aarch64 😄

IRC channel logs

2025-10-22.log