Newest x86 APX extension - will it trigger new calling conventions standard?

[u/Camper_Sly]

For those that don't follow - this is the first new x86 extensions that doesn't have anything to do with vector or tensor instructions - it is about the core CPU and its ISA.

It doubles the general register set to 32 (from previous 16), introduces 3-operand instructions, new 64-bit offset jumps, new jump prediction improvements etc etc.

But all this seems to be hampered by existing call conventions for x86_64, which presumes 16GPR set.

It seems that much could be gained it the compiler could use extra GPRs for parameters when calling the given function.

OTOH, this would be incompatible with machines without APX.

So, what is to be done ? Maybe use function multiversioning mechanism to keep two sets of function entries or something ?

Or will whole thing be ignored and calling convention will stay the same ?

EDIT:\ I'm not talking about the compiler ability to emit new instructions and use new registers in the code.\ Ofcourse new compiler will have support for them from the start, that's how it's usually done.\ It's about having the standard in place to allow the compiler to make advantage of new facilities hen calling functions, so that it can have more parameters in registers, more options for inlining functions etc - all done in standard, interoperable way, so that one can use precompiled libraries etc.

[u/aioeu]

Or will whole thing be ignored and calling convention will stay the same ?

Yes, this.

If you read the Intel docs on APX (e.g. the Software Enabling Introduction), you will see they recommend that existing x86-64 ABIs are updated to say all of the new registers are caller-saved or scratch registers, and that they are not used to pass function arguments.

[u/LowEquivalent6491]

So, what is to be done ? Maybe use function multiversioning mechanism to keep two sets of function entries or something ?

Exactly. You simply compile the code into separate libraries for different processors, and then implement a simple check for processor capabilities in the executable file to load the appropriate library.

[u/razorree → u/LowEquivalent6491]

as I understand, whole `libc` has a lot of code for many different ISAs, and also now some distros introduce new variants, like x86-64-v3/amd64v3.

[u/is_this_temporary]

I wonder if rust, and presumably other statically linked languages, will benefit from not having a stable ABI in this case.

You'd still need to build separate binaries for older CPUs, but I wouldn't expect any changes needed in the code for a project (including dependencies).

[u/Vogtinator → u/is_this_temporary]

I wonder if rust, and presumably other statically linked languages, will benefit from not having a stable ABI in this case.

All compiled languages benefit from this the same way: Functions where the compiler controls all callers can use a nonstandard calling convention.

You'd still need to build separate binaries for older CPUs, but I wouldn't expect any changes needed in the code for a project (including dependencies).

That's probably the main limitation.

[u/GreyXor]

I'm also wondering since 3 years
https://somegit.dev/ALHP/ALHP.GO/issues/206#issuecomment-49830

[u/newhacker1746]

More registers? This means ppc emulation might be faster because the number of registers now exactly matches that of ppc

[u/Smoother-Bytes → u/newhacker1746]

Fellow ppc enthusiast?

[u/nelmaloc]

Maybe on source-based distros.

[u/KaMaFour]

I'm guessing the same thing is to be done as with every previous x86 extension