0

As we know, ARM updates the arm architecture continuously with recently releasing v9 I guess.

But is the x86_64 architecture also being updated continuously by Intel or AMD?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
10209
  • 3
  • 2

1 Answers1

4

x86-64 does extensions by name, with only a de-facto policy (by Intel) of having future CPUs support all the extensions previous CPUs did (i.e. backwards compatibility).

Even that is fragmenting some with Intel introducing new ISA extensions in server CPUs but not in contemporary desktop CPUs, or movbe appeared in Atom significantly before mainstream CPUs (Haswell). And continuing to sell Pentium / Celeron CPUs without AVX or BMI1/BMI2. (Although Ice Lake and later Pentium / Celeron may finally handle 256-bit vectors with AVX2 and thus decode VEX prefixes and be able to enable BMI1/BMI2 as well.)

AMD sometimes even drops support for their ISA extensions if Intel never adopts them. (Like XOP introduced in Bulldozer-family, dropped in Zen. And FMA4 again from Bulldozer, officially dropped in Zen but still works in Zen 1, really gone in Zen 2.) See also Agner Fog's blog article Stop the instruction set war.

There unfortunately isn't an agreed-upon mechanism between vendors for architecture versions, so for example atomicity guarantees for aligned stores of various width are guaranteed by Intel in terms of "486 or later", "Pentium and later", "P6-family and later". See Why is integer assignment on a naturally aligned variable atomic on x86?

Note that the common subset of Intel's and AMD's atomicity guarantees for loads/stores to cacheable memory actually comes from AMD in this case: Intel guarantees no tearing for any 2,4, or 8-byte store that doesn't cross a cache-line boundary. But AMD only guarantees atomicity for those sizes within an aligned 8-byte chunk, and multi-socket K10 truly does tear in transfers between sockets.

Nowhere is there a single document that covers the lowest common denominator of functionality and instruction-set extensions across modern x86-64 CPUs.

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847
  • 1
    It's even worse now: Intel is dropping AVX-512 in their next mainstream desktop and laptop processor series (Alder lake) after having them in the prior (Ice Lake, Tiger Lake, Rocket Lake). – BeeOnRope Aug 23 '21 at 16:46
  • 1
    @BeeOnRope: yeah, my browser ate an edit that talked about that. And maybe even some server/client fragmentation with stuff like `enqcmd` in Sapphire Rapids (Golden Cove) if the corresponding desktops / laptops based on the same core don't have that. (Perhaps disabled because the efficiency cores in Alder Lake won't have it, and like with AVX-512 they don't want software to have to deal with some cores having instructions that will fault on other cores.) – Peter Cordes Aug 23 '21 at 17:49
  • 1
    yeah I think it is 100% because they don't yet have a solid story for hetrogeneous ISAs, and given the existing programming model revolving around `cpuid`. E.g, some of have suggested that using AVX512 on the small cores could "simply" fault, the the job gets migrated to the big core, but why would the process use AVX-512 instructions in the first place, unless `cpuid` reported support? And if `cpuid` *does* report support, _almost every_ process ends up using AVX-512 because of use in libc among other places. – BeeOnRope Aug 27 '21 at 03:00
  • Well, I wonder how intel or amd is gonna tackle the arm in apple silicon. Looks like, if some miracle doesn't happen overnight, mainstream laptop and desktop market will slowly move away from x86 to arm... sooner than many expected. – 10209 Oct 04 '21 at 19:31