3 ms·

Perhaps standardizing the byte as 8 bits, for one example. Edit: Actually, they specifically call out little-endianness as a priority.

twoodfin 6y ago
Surely the standard wouldn’t drop support for big-endian? And I don’t see what you’d gain in exchange. Defined semantics for casting int* to short*? Woo? These are smart, system-software-focused engineers, so there must be some interesting directions being blocked off by insistence that the standard be byte-order agnostic (and word-size agnostic, since they’re so keen on 64-bit)...
- dodobirdlord 6y ago
  As with most of the things the authors describe, the advantage would be a simpler compiler and a simpler language for static analysis. There are a lot of things in the standard that the authors just don’t have any use for that they would prefer to see removed in the interest of faster compiles, easier compiler development, and more performance optimizations. Removing support for big-endian might actually significantly speed up compilation. I’m sure it adds a ton of branching to hot code paths to check some architecture endianness enum every time the compiler wants to reason about things like bit shifts and known-bits.
  - gray_-_wolf 6y ago
    Could you not just produce basically two compilers, one for big and one small endian? I think that could be done with templates and such. Sure, bigger code size, but that does not seem something that would pain people from google (as I can tell looking at golang).
    - dodobirdlord 6y ago
      Possibly, I'm no professional compiler author. But I imagine doing so would require templatizing a lot of logic, and would significantly slow down the compilation of the compiler itself, which is an important metric for development velocity of compiler improvements. (The linux kernel is famous for taking about the same amount of time to compile through its history. If compile times get long enough people start paying attention to optimizing compile time instead of performance.) It was eye-opening when I read this blog post and learned that LLVM spends about 0.4% of all compilation time reading the bytes of the string "null-pointer-is-valid" over and over. Hot code paths can be pretty hot. https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html

twoodfin 6y ago

Surely the standard wouldn’t drop support for big-endian? And I don’t see what you’d gain in exchange. Defined semantics for casting int* to short*? Woo? These are smart, system-software-focused engineers, so there must be some interesting directions being blocked off by insistence that the standard be byte-order agnostic (and word-size agnostic, since they’re so keen on 64-bit)...

dodobirdlord 6y ago
As with most of the things the authors describe, the advantage would be a simpler compiler and a simpler language for static analysis. There are a lot of things in the standard that the authors just don’t have any use for that they would prefer to see removed in the interest of faster compiles, easier compiler development, and more performance optimizations. Removing support for big-endian might actually significantly speed up compilation. I’m sure it adds a ton of branching to hot code paths to check some architecture endianness enum every time the compiler wants to reason about things like bit shifts and known-bits.
- gray_-_wolf 6y ago
  Could you not just produce basically two compilers, one for big and one small endian? I think that could be done with templates and such. Sure, bigger code size, but that does not seem something that would pain people from google (as I can tell looking at golang).
  - dodobirdlord 6y ago
    Possibly, I'm no professional compiler author. But I imagine doing so would require templatizing a lot of logic, and would significantly slow down the compilation of the compiler itself, which is an important metric for development velocity of compiler improvements. (The linux kernel is famous for taking about the same amount of time to compile through its history. If compile times get long enough people start paying attention to optimizing compile time instead of performance.) It was eye-opening when I read this blog post and learned that LLVM spends about 0.4% of all compilation time reading the bytes of the string "null-pointer-is-valid" over and over. Hot code paths can be pretty hot. https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html