• JamonBear@sh.itjust.works
    13·
    3 months ago

    Cmon, this is not about naming, this is about non-generic code in generic header.

    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.devBanned from community
      33·
      3 months ago

      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·
        3 months ago

        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.devBanned from community
              3·
              3 months 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.