New Intel Simplified Architecture

[BSDUser97]

Hi Jose !

Always good to read your posts.


It follows from your post in this way.

• The X86S whitepaper purposely omits any mention of AMD.
• You rightly point out AMD's contribution to the story (thank you).
• Now that AMD is part of the conversation, I'm making a prediction as to how AMD might respond to the adoption of X86S.

We're both talking about compatibility. You're emphasizing x86 compatibility. I'm emphasizing amd64 vs x86-64 compatibility.

Put another way - Intel adopting amd64 into their processors marked the end of a battle, not the war. What followed were competing enhanced instruction sets and special VMM register bits. amd64 and x86-64 are compatible to a point. My cynicism comes from code fragments in FreeBSD like this:

freebsd-src/sys/amd64/vmm/vmm.c at 9cc67e43610e34a692398a65adcc5e8846e84250 · freebsd/freebsd-src

The FreeBSD src tree publish-only repository. Experimenting with 'simple' pull requests.... - freebsd/freebsd-src

github.com

It would be nice if x86s reduced the amount of "if (amd) {} else if (intel) {}" logic. We'll see.

I should add, I'm not trying to cast shade on AMD or Intel. They are for-profit corporations doing what they think best. I expect this competition to result in new bits of if/else logic in the FreeBSD kernel. It is what it is.

Regards.

Intel and AMD form advisory group to reshape x86 ISA

Linus Torvalds, Broadcom, Dell, HPE, and Lenovo on the list

www.theregister.com

 

[BSDUser97]

Just in case no one has heard yet:

https://www.intel.com/content/www/u...visioning-future-simplified-architecture.html

I'm curious as to how this could impact FreeBSD. Perhaps it's not a question that will really come up until Intel produces a real product line with the "simplified" architecture or Microsoft and AMD show some interest in it.

Andrew Lankford

Updated June 2024 spec for x86s:

Envisioning a Simplified Intel Architecture for the Future

PC computing rests heavily on Intel Architecture processors with an enormous installed base, and cloud computing is synonymous with Intel Architecture.

www.intel.com

 

[T-Aoki]

Possibly kmods having 32bit blob (is there any?) would no longer work on X86S. And also, BIOS (legacy) boot is promised to stop working on X86S.

As already mentioned, emulators for 16bit X86 using CPU mode switching (per process) shoule move to full emulation (32bit ones could have chance to keep usable as is if it is actually running on compat32 and do not require kmods).

And at least installer should have checks for CPU not to allow installing as legacy (BIOS) boot on X86S CPUs.

 

[cy@]

This shouldn't affect FreeBSD except for removing 32-bit compatibility. You can already do this with a buildworld knob.

The simplified mode is the next progression. Nobody uses 16-bit modes (real or 286-protected) anymore, except for maybe FreeDOS. 32-bit modes are not supported by most Linux distros nor by Windows 11. FreeBSD has deprecated 32-bit mode in the kernel, i.e. no more support for 32-bit hardware, but there is still support for 32-bit apps on a 64-bit platform. With SIA there can be no 32-bit support whatsoever. Yeah, the libraries might still be installed by the installer (default for legacy hardware) but they'd use valuable space on hardware that doesn't support it. Thus I'd expect 32-bit mode to be deprecated in FreeBSD 16 or 17.

EDIT: It appears they will still support IA32e in ring 3. No 32-bit support in kernel mode but 32-bit apps are still supported. As long as all our 32-bit libraries thunk to 64-bit we'd be ok in that department. Though, I'd still be in favour of deprecating 32-bit userland entirely to simplify FreeBSD's sources.

One has to ask, why would Intel do this? This frees up space on the die, reducing power requirements, making CPU chips smaller, and freeing space for new features.

The next question is, will AMD follow suit? If they do this will cement Intel's decision. If they don't AMD could capture more of the market. In that case Intel may reverse course. They won't want to give market share away to AMD. Or if they do go ahead with this, it will only be for some esoteric applications. We do need to find out more though.

 

[Jose]

Intel and AMD form advisory group to reshape x86 ISA

Linus Torvalds, Broadcom, Dell, HPE, and Lenovo on the list

www.theregister.com

Yep, they feel ARM's hot breath over their shoulder:

With that said, a more consistent ISA could help stave off the growing number of Arm-compatible CPUs finding homes in cloud datacenters.

It's probably too little, too late, as one of the El Reg commenters says.

One has to ask, why would Intel do this? This frees up space on the die, reducing power requirements, making CPU chips smaller, and freeing space for new features.

Maybe? From TFA:

We have no doubt that either team's SoC designers would relish the opportunity to reclaim all that die area currently consumed by the NPU.

They're talking about AVX-512 in that paragraph, but it does seem die area might be at a premium. If it is, how about getting rid of widely despised security fails like the IME?

 

[unitrunker]

Seems Intel has dropped this idea.

Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end

A pivot here, a pivot there.

www.tomshardware.com

 

[T-Aoki]

Seems Intel has dropped this idea.

Intel terminates x86S initiative — unilateral quest to de-bloat x86 instruction set comes to an end

A pivot here, a pivot there.

www.tomshardware.com

Maybe Intel noticed that this could be the revival of their mistakes on IA64.
At the moment, if Intel could ship Itanium to be able to run x86 codes far more faster than the fastest native ones, that could appear within the timespan Itanium was first shipped, with its emulation codes. But it was just a dream.
Market chose amd64, which is a natural extention to 32bit x86, far more faster than emulations on Itanium, far less expensive and the compatibilities was almost perfect on ancient modes.
Once written, softwares are used far more longer than hardware vendors want.