Hacker News Reader

Comment by lgeek | Hacker News Reader

> 32-bit fixed encoding makes the decoder simple, but creates the same load-store problem as on SPARC - hello non-existent, synthetic instructions!

I'm not familiar with this. Could you explain the problem or point me in the right direction for background info?

View on HN

If you have 32-bits available to encode the instruction and the operand, how do you encode a load of a 32-bit address, or even a 64-bit address?

That's why the SPARC assembler, as(1), accepts a completely made-up, non-existent, synthetic instruction, ld. In reality, what happens is that as(1) assembles this made-up fantasy into two instructions, sethi and or. This is the cold, hard reality of loading a 32-bit value from memory:

  String0:
  .asciz "Counter is %.2d\\n"
  .align 4

  main: sethi %hi(String0), %l0
        or %l0, %lo(String0), %l0

Looking at the RISC-V spec, you probably should be using the AUIPC instruction to address data in your .text, .data or .bss sections. As a bonus, your code becomes position-independent so you can actually use it in shared libraries. To use arbitrary 32-bit and 64-bit pointers known at compile-time (which should be pretty rare), you also have the option of loading them from memory, i.e. using AUIPC to generate a pointer to the value in your .text and then loading it to a register in addition to your approach.

Reply on news.ycombinator.com