Linux Kernel Looks To Remove 32-bit Xen PV Guest Support

[phoronix]

Phoronix: Linux Kernel Looks To Remove 32-bit Xen PV Guest Support

Coming soon to a kernel near you could be the removal of 32-bit Xen PV guest support as better jiving with Xen's architectural improvements and more of the Linux/open-source community continuing to shift focus to 64-bit x86 with trying to finally sunset 32-bit x86...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Drop-32-bit-Xen-PV-Guest

[uid313]

If they (Intel or AMD) made a x86-64 CPU without the old 32-bit instructions, would that improve the CPU by reducing amount of instructions and silicon and could that result in a better CPU?

[Azrael5]

When all the 32 bit software is deprecated, will be the evolution day.

[Neraxa]

If they (Intel or AMD) made a x86-64 CPU without the old 32-bit instructions, would that improve the CPU by reducing amount of instructions and silicon and could that result in a better CPU?

Basically, no. 32-bit backwards compatibility does not harm performance because both modes use most of the same circuitry. In 64 bit mode uses the same arithmetic and addressing circuitry as 32 bit mode, additional circuits are just go online when 64 bit mode is enabled. Intel engineers mentioned for a long time that 32 bit compatibility has an insignificant effect on the chip. Or in other words, 32 bit mode just uses a subset of the circuits that 64 bit mode uses.

[stormcrow]

If they (Intel or AMD) made a x86-64 CPU without the old 32-bit instructions, would that improve the CPU by reducing amount of instructions and silicon and could that result in a better CPU?

They did. It was called Itanium. No one wanted it. If you mean x86-64, then no, they can't because the "old" 32-bit instructions (architecture) is the core of the CPU and the "64" are extensions added to the legacy IA32 core. If you wanted a clean break from legacy IA32 then you shouldn't have continued investing in merely an extension to a CPU architecture that's about 40 years old now. UEFI secure boot, RAM, and storage size aside, you can still run MSDOS on a modern Intel Skylake CPU, because the core architecture is the same as it was 40 years ago, and all software that runs on this architecture depends on similar assumptions whether it's IA32 native or x86-64 native.

That's a drastic oversimplification of what x86-64 is, naturally, but it answers an imprecise question well enough.

Edit to add: For an example of why this is impossible for x86-64, take the single register RAX: the initial register was "AX" which is 16 bit (from the original AT 8086), when it became 32 bit the register was simply Extended to "EAX", so EAX is AX + another 16 bits. For RAX in x86-64 it's AX + the 16 bits added with EAX in the 386 + another 32 bits added in the x86-64 transition = 64 bit RAX. Each of the older registers is still there and you can still reference them by their name. And before you suggest "Just drop *AX", that's impossible. It's a core register that everything uses, same as AX & EAX. They're all still in use as core expectations of the architecture guaruntees. That's just one of the various registers that've been so extended over the years that were present in the AT x86 architecture and still required to be there.

[uid313]

They did. It was called Itanium. No one wanted it. If you mean x86-64, then no, they can't because the "old" 32-bit instructions (architecture) is the core of the CPU and the "64" are extensions added to the legacy IA32 core. If you wanted a clean break from legacy IA32 then you shouldn't have continued investing in merely an extension to a CPU architecture that's about 40 years old now. UEFI secure boot, RAM, and storage size aside, you can still run MSDOS on a modern Intel Skylake CPU, because the core architecture is the same as it was 40 years ago, and all software that runs on this architecture depends on similar assumptions whether it's IA32 native or x86-64 native.

That's a drastic oversimplification of what x86-64 is, naturally, but it answers an imprecise question well enough.

Edit to add: For an example of why this is impossible for x86-64, take the single register RAX: the initial register was "AX" which is 16 bit (from the original AT 8086), when it became 32 bit the register was simply Extended to "EAX", so EAX is AX + another 16 bits. For RAX in x86-64 it's AX + the 16 bits added with EAX in the 386 + another 32 bits added in the x86-64 transition = 64 bit RAX. Each of the older registers is still there and you can still reference them by their name. And before you suggest "Just drop *AX", that's impossible. It's a core register that everything uses, same as AX & EAX. They're all still in use as core expectations of the architecture guaruntees. That's just one of the various registers that've been so extended over the years that were present in the AT x86 architecture and still required to be there.

Thanks for an interesting post.

Apple's ARM CPU only does 64-bit and does not do 32-bit. ARM Cortex-A77 only supports 32-bit for unprivileged applications, all privileged applications must use 64-bit.

I heard some of the recent ARM processors have similar or higher IPC than Intel Skylake. I would really like a desktop computer with a high-end ARM or RISC-V processor.

[stormcrow]

Thanks for an interesting post.

Apple's ARM CPU only does 64-bit and does not do 32-bit. ARM Cortex-A77 only supports 32-bit for unprivileged applications, all privileged applications must use 64-bit.

I heard some of the recent ARM processors have similar or higher IPC than Intel Skylake. I would really like a desktop computer with a high-end ARM or RISC-V processor.

I don't know a lot about the ARM ecosystem. But the reason it's easier to do what you're saying with ARM is because there is little in the way of technical debt hanging on in the mobile space. Many of the companies in the mobile and IoT space don't expect backwards compatibility so it's not holding much back. ARM hasn't had a significant presence in the desktop space since the old Acorn systems, and far as I know, they were never a presence in the server space. If they had been, it's possible they'd have the same problem as the PC desktop has with lingering architecture issues and newly revealed security implications those decisions made 30 years ago affect us now.

RISC-V... I don't think it's going to be the silver bullet to the current problem with extreme complexity, closed and/or undocumented designs and features, etc. While the *core* of the ISA is open, there's nothing in the spec that says any extensions have to be published, nor is there any prohibition on the firmware being closed. I suspect it's going to end up fragmented with vendor specific extension flavors as ARM.

[tildearrow]

If they (Intel or AMD) made a x86-64 CPU without the old 32-bit instructions, would that improve the CPU by reducing amount of instructions and silicon and could that result in a better CPU?

I would like to defend and reiterate my stance on compatibility!

Breaking compatibility is never a good thing, and although it's been ~16 years since x86_64 was release, 32-bit-only applications were still made for a long time, until like 2015-2017 when they began shipping just 64-bit versions.

So, if you drop support for 32-bit instructions, you may be dropping support some 2-5 years old applications, of which I totally do not want to see.

[tildearrow]

Apple's ARM CPU only does 64-bit and does not do 32-bit. ARM Cortex-A77 only supports 32-bit for unprivileged applications, all privileged applications must use 64-bit.

You already know how Apple behaves regarding compatibility. You can leave them alone.

I heard some of the recent ARM processors have similar or higher IPC than Intel Skylake. I would really like a desktop computer with a high-end ARM or RISC-V processor.

Please note that ARM is a RISC, while x86 is a CISC. This means that although ARM may have a higher IPC than x86, it may actually run slower than x86 for some tasks.

[jabl]

Thanks for an interesting post.

Apple's ARM CPU only does 64-bit and does not do 32-bit. ARM Cortex-A77 only supports 32-bit for unprivileged applications, all privileged applications must use 64-bit.

I heard some of the recent ARM processors have similar or higher IPC than Intel Skylake. I would really like a desktop computer with a high-end ARM or RISC-V processor.

64-bit ARM (aarch64) is a cleaner break from the past than x86-64, so by doing an aarch64-only chip the designers can leave behind more of the old idiosyncrasies (as opposed to x86-64 which retains much of the original x86 craziness like the partial register semantics or x87). And like stormcrow said, it's a different market with much less emphasis on backward compatibility.