IMO hiding such a little operation behind a macro/function just hurt readability. Furthermore, considering that this function is only used once in the provided patch and that word ordering on RISC-V is not about to change anytime soon, it is perfectly fine to inline the code.

[–] FizzyOrange@programming.dev 0 points 1 month ago (1 children)

this is about non-generic code in generic header.

(a << 16) | b is about the most generic code you can get. How is that remotely RISC-V specific?

[–] zygo_histo_morpheus@programming.dev 11 points 1 month ago* (last edited 1 month ago) (1 children)

Making a u32 ~~pointer~~ from two u16's isn't a generic operation because it has to make assumptions about ~~how the pointers work~~ endianess

Edit: Actually, I'm wrong, didn't think this through properly. See the replies

[–] FizzyOrange@programming.dev 2 points 1 month ago (1 children)

What makes you think it's making a pointer? Nobody said anything about that.

[–] zygo_histo_morpheus@programming.dev 2 points 1 month ago (1 children)

Oh my bad I don't know where I got that from lol

[–] FizzyOrange@programming.dev 3 points 1 month ago

Nw. You're also wrong about endianness. This function would be written exactly the same irrespective of endianness:

uint32_t u16_high_low_to_u32(uint16_t high, uint16_t low) {
  return (high << 16) | low;
}

That is endian agnostic.