Date: Sat, 30 Aug 2025 06:49:27 +0200
> 1st pre-compiler directives for major cpu architectures should have a standard name. I.e. pre-compiler directives that tells you if you are emitting instructions for an Arm64, Risc-V, x86_64, etc…
What kind of compiler directives? Are we talking about preprocessor directives?
Can you show some concrete example of the kind of code you want to write?
> 2nd All supported data types that make sense that makes sense to perform operations (or register types) should a well-defined type. No “unsigned int” or “float”, more of a “uint16”, “ieee_fp32”, or “AVX_512_fp64”
This seems a bit unreasonable. Keep in mind that compilers nowadays
sometimes come with builtin vector types for SIMD, so this old style
of __mm256i or whatever is not a great fit for standardization; it's
too low-level. AVX intrinsics often require you to reinterpret these
vector types as something else, like when you do a bit-masking
operation on what was a bunch of f64s just a moment ago. This doesn't
fit well into C++'s strict aliasing.
> 3rd All function that make sense on a specific architecture (things that the CPU provide specific instructions for) should be put in a library collection that is only available on a specific architecture being targeted.
Isn't it obvious that it comes with a huge maintenance burden if you
need to maintain a set of intrinsics for all sorts of architectures,
many of which depend on various CPU extensions? We operate on a
three-year cycle and this seems very difficult to keep up. Which ones
do we maintain? RISC-V, x86_64, ARM, WASM at the very least, and all
their possible extensions?
Remember that we're on a three-year cycle, so if Intel releases a new
CPU extension in 2026, tough luck, you're waiting until 2029 until
that intrinsic is in a C++ standard.
> Not necessarily every single instruction but most intrinsics should probably end-up there. I’m talking stuff like “cupid” (on arm or x86), AVX instructions, AES or CRC instructions.
If it's not simply one intrinsic per instruction, this sounds like an
ungodly amount of bikeshedding over which instruction wrappers to stan
> The intel intrinsics library does a very good job to make this more or less portable, but I’m talking a similar thing for all major architectures. And if the functions do something deterministic, make it constexpr as well.
This works much better in third-party libraries. We don't need this to
be in the standard.
What kind of compiler directives? Are we talking about preprocessor directives?
Can you show some concrete example of the kind of code you want to write?
> 2nd All supported data types that make sense that makes sense to perform operations (or register types) should a well-defined type. No “unsigned int” or “float”, more of a “uint16”, “ieee_fp32”, or “AVX_512_fp64”
This seems a bit unreasonable. Keep in mind that compilers nowadays
sometimes come with builtin vector types for SIMD, so this old style
of __mm256i or whatever is not a great fit for standardization; it's
too low-level. AVX intrinsics often require you to reinterpret these
vector types as something else, like when you do a bit-masking
operation on what was a bunch of f64s just a moment ago. This doesn't
fit well into C++'s strict aliasing.
> 3rd All function that make sense on a specific architecture (things that the CPU provide specific instructions for) should be put in a library collection that is only available on a specific architecture being targeted.
Isn't it obvious that it comes with a huge maintenance burden if you
need to maintain a set of intrinsics for all sorts of architectures,
many of which depend on various CPU extensions? We operate on a
three-year cycle and this seems very difficult to keep up. Which ones
do we maintain? RISC-V, x86_64, ARM, WASM at the very least, and all
their possible extensions?
Remember that we're on a three-year cycle, so if Intel releases a new
CPU extension in 2026, tough luck, you're waiting until 2029 until
that intrinsic is in a C++ standard.
> Not necessarily every single instruction but most intrinsics should probably end-up there. I’m talking stuff like “cupid” (on arm or x86), AVX instructions, AES or CRC instructions.
If it's not simply one intrinsic per instruction, this sounds like an
ungodly amount of bikeshedding over which instruction wrappers to stan
> The intel intrinsics library does a very good job to make this more or less portable, but I’m talking a similar thing for all major architectures. And if the functions do something deterministic, make it constexpr as well.
This works much better in third-party libraries. We don't need this to
be in the standard.
Received on 2025-08-30 04:49:40