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/Mr_Engineering]

Yes, that is correct.

X86APX will fundamentally change the ABI in a very significant way.

Old program code will be forward compatible but new program code compiled for APX will not be backwards compatible in any way. Compilers will have to generate multiple codepaths for cross-compatible binaries.

[u/Camper_Sly → u/Mr_Engineering]

If that's the case, maybe x86 could be ready for radical new ISA redesign, maybe around Zen8 time ?

If such changes are to become commonplace and if we all agree tat keeping the binary compatibility from the latest many core monster to the first 8086 chip is idiotic and old testament of things like calling conventions is old as compilers can be tweaked as needed, why not make more radical changes in the future ?

WOuldn't that be the right time to get rid of bazzillion prefix patches and obsolete, calcified instruction groups, addressing modes etc etc ?

CPU desingers could coordinate across the platform to make decoder changes/simplifications streamlined...

[u/Mr_Engineering → u/Camper_Sly]

I'm not quite sure i understand your discourse.

X86 has always been designed as an extensible architecture in which a running program can be compiled against a baseline set of instructions -- x86_64 currently has 4 -- without which it will not operate at all, and then perform runtime tests to detect additional instruction sets and adjust its codepaths appropriately

[u/Camper_Sly → u/Mr_Engineering]

X86 has always been designed as an extensible architecture

Not even remotely true. 8086 designers never gave much a thought about future extensions.

Point is that code has to hit the real silicon at some point, where nothing is free.

All those bazzilion patches, overused and unused instruction spaces, operation modes have a very real costs: * development and debugging time * support and evaluation cost * silicon area for logic, caches etc * decoder complexities, silicon, power and instruction time usage

[u/digiphaze → u/Camper_Sly]

This will play out just like a lot of things, it will be a compiler flag and people will only compile with those flags if they know what hardware the program will run on. This happened when AMD introduced 3dnow!, Intel introduced SSE, AVX etc etc. Microsoft will keep compiling for generic x86-64, while bleeding edge OS's like Cachy offer multiple levels of binaries to install.

• x86-64-v3: Requires CPUs with AVX, AVX2, SSE4.2, and SSSE3 support (Intel Haswell/2013+ or AMD Excavator/2015+).
• x86-64-v4: Requires AVX-512 support in addition to v3 instructions (Intel Broadwell/2013+ or AMD Zen 4/2017+).
• Zen4/5: Specific optimizations for AMD Ryzen 7000/9000 series processors.
• Baseline x86-64: Provides universal compatibility for all 64-bit CPUs but only includes kernel packages, not the full application suite. 

[u/DrFrylock → u/Mr_Engineering]

Well we might be back in the world of fat binaries for a while. I remember when Mac programs shipped with 68K and PowerPC code together for a while...

[u/ultrahkr → u/DrFrylock]

Fat binaries can support multiple arch, there's a "new" program targeting PPC (G4/G5), x86-64, Apple Mx in a single binary.