3 ms·
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
by 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 agoCould 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 agoPossibly, 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