Intel considering making new CPUs 64 bit only

[NiHaoMike]

https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.html
My take is that as a slightly more conservative step, keep an Atom or Quark core for the 16 and 32 bit compatibility. Then once running in 64 bit mode, that legacy core gets reused for simple tasks like power management or audio DSP.

[ataradov]

The thing that always happens in the moves like this is the result gets smeared with a thick coat of DRM and other proprietary BS so that no code runs without company's blessing and signed startup code along with the backdoors.. And then the company loses interest and the hardware dies because it has no longevity  outside of the corporate interest.

And there is no chance that current design driven purely by corporate interests would result in anything that is in the interest of the consumers.

[SiliconWizard]

Well, going to 64-bit only would make sense for future CPUs.

The only thing I'm thinking of is that everytime Intel has tried to break backwards compatibility, even when it appeared to make complete sense, it has bitten them sharply.

[ataradov]

Sure, I'd love to have a simplified and straightforward boot process. But the last time  they simplified the boot process instead of a straightforward BIOS we ended up with UEFI crap. I have zero confidence that they likewise don't screw up the hardware part of it.

And of course all the limitations would be for "our protection". Think of the children and all that.

I wonder why even ask for public comments? Would they even listen?

[floobydust]

Consult the Intel Management Engine for the answer 
The X86-S spec is already 46 pages of spaghetti.
At some point they need to dump the old antique 80x86 legacy, have you ever looked at a i7 CPU manual for example, it's so complicated that any competitor offering simple will simply flatten their balls.
Bus width is not the issue, unless you want to calm down investors as Intel stock sucks for some time now, and appear to have a plan or something.
Intel is so off course, high on their laurels that I don't think they can pull off anything successful.

[brucehoult]

If they're only thinking about this now, then by the time anything hits the market both Arm and RISC-V will be fully caught up in performance.

Where would AMD stand in this? Is it just another attempt to cut them out? Like "Oh no, Mr Judge, Pentium isn't called 'x86' and so AMD's x86 licence doesn't apply". Like Itanium.

[Ed.Kloonk]

Wouldn't they go better making sure their microcode is water tight.

[Berni]

Yep the move from BIOS to UEFI just made things more complicated instead. This would probably end up doing the same.

Backwards compatibility is the main reason why Intel doing so well. There is plenty of software out there that is still 32bit. The piece of software written to run on a 386 can still just simply be run natively from an executable file on the latest CPU that Intel and AMD makes.

Tho with how fast computers are getting it makes sense to instead emulate for backwards compatibility. But that work has to be put in by the OS developers like Microsoft, they wouldn't really get anything in return for that work, they would just make Intels life easier.

[David Hess]

Intel has made x86 processors in the past which dropped legacy support for the embedded market.

Besides backwards compatibility being a feature, it does not cost very much in die area or performance, and the technical debt is largely already paid for.

[eutectique]

Termina Itanium 2 : Le Jugement dernier. And revive the compiler, as well.

[tszaboo]

I don't see a big issue. Do you really want to run a 32 bit OS?
Because applications will just get a translation layer, and run the 64 bit equivalent of the 32 bit instruction.
What's the big deal? Your int will be 8 bytes long in c?

[ataradov]

It is not the idea itself that is bad. The ability of current Intel to implement it properly is questionable. The end result is likely to be crap and we will be stuck with it.

Plus the part they want to remove is minimal and trivial. You still would be stuck with x64. I see no point in taking that risk unless you want to do something else on the side. Just wait for subscription CPUs that stop working when you stop paying.

[SiliconWizard]

But, you will own nothing and be happy!

[Ed.Kloonk]

I don't see a big issue. Do you really want to run a 32 bit OS?

I would have, yes.

For a number of years, to run any of the preferred latest version of Linux I can tolerate meant that they wont boot on old hardware if the CPU in the laptop doesn't have certain 64-bit flags.

I suspect this is just Intel once again following the market instead of leading the market. Linux kernels booted just fine on the raspberry pi 32-bit until the foundation finally got around to bringing out 64-bit.

My dubious understanding is for the Intel is that along with the 64-bits you get better native crypto and virtualization.

[bw2341]

Where would AMD stand in this? Is it just another attempt to cut them out? Like "Oh no, Mr Judge, Pentium isn't called 'x86' and so AMD's x86 licence doesn't apply". Like Itanium.

Well, since the Intel® 64 architecture is a licensed version of AMD64, I don't think Intel will have much leverage.

While we don't have any details of the licence agreement between them, the only arrangement that makes sense would be a very liberal licence both ways.

Something like "You can use all of my past, present and future ISA stuff for free if I can use all of your past, present and future ISA stuff for free."

Any attempt by Intel to squeeze AMD would result in the termination of the base AMD64 licence. If AMD tried to squeeze Intel, they would lose the right to newer Intel extensions such as AVX.

[Someone]

I don't see a big issue. Do you really want to run a 32 bit OS?
Because applications will just get a translation layer, and run the 64 bit equivalent of the 32 bit instruction.
What's the big deal? Your int will be 8 bytes long in c?

There is more to an instruction than just the data word, such things as the carry flag and keeping the higher bits clean for later comparisons. I wonder which legacy instructions are difficult to replace with microcode, surely dropping legacy performance by 3-10x would be better than killing it entirely?

[langwadt]

I don't see a big issue. Do you really want to run a 32 bit OS?
Because applications will just get a translation layer, and run the 64 bit equivalent of the 32 bit instruction.
What's the big deal? Your int will be 8 bytes long in c?

There is more to an instruction than just the data word, such things as the carry flag and keeping the higher bits clean for later comparisons. I wonder which legacy instructions are difficult to replace with microcode, surely dropping legacy performance by 3-10x would be better than killing it entirely?

what does Apple do with their ARM?

[james_s]

x86{realmode, protected mode, long mode, whatever mode} _MUST_ die

intel has ruined the whole computer science with their garbage CPUs, including 8085, i960, PXA-arm, and 8031/51, for years!

I hope they go bankrupt and I'll laugh heartily reading the news in the papers.

 

You're going to be waiting a while. x86 is the defacto standard and runs more than 90% of the personal computers in the world. It's not going away any time soon, but thankfully for those with an irrational obsession with CPU architecture, there are other options.

[james_s]

what does Apple do with their ARM?

I don't know about arm, but when they went from PowerPC to Intel they had a seamless emulation layer built into the OS. Seems like the same could be done to get 31 and 16 bit compatibility on other processors, most of that old software is not going to require maximum performance anyway. Of course actually implementing that may be easier said than done when you don't have the tight control over the OS and hardware that Apple has.

[brucehoult]

I don't see a big issue. Do you really want to run a 32 bit OS?
Because applications will just get a translation layer, and run the 64 bit equivalent of the 32 bit instruction.
What's the big deal? Your int will be 8 bytes long in c?

There is more to an instruction than just the data word, such things as the carry flag and keeping the higher bits clean for later comparisons. I wonder which legacy instructions are difficult to replace with microcode, surely dropping legacy performance by 3-10x would be better than killing it entirely?

Ugh microcode.

If you're happy with a 3-10x performance drop then a simple portable JIT emulator such as QEMU is in that range.

Apple's "Rosetta 2" x86 emulator on Arm has a lot less penalty than that compared to native.

Here are some data points from my primes benchmark (http://hoult.org/primes.txt):

Code: [Select]


 2.795 sec Mac Mini M1 @ 3.4 GHz
 2.810 sec Mac Mini M1 arm64 Ubuntu in VM
 2.872 sec i7 6700K @ 4.2 GHz
 2.925 sec Mac Mini M1 @ 3.2 GHz x86_64 Rosetta  <=== x86_64 emulation on Arm
 3.223 sec Threadripper 2990WX @ 4.2 GHz
 3.448 sec Ryzen 5 4500U @ 4.0 GHz WSL2
 3.725 sec AWS C7g graviton3 A64 @ 2.6 GHz   <=== the fastest non-Apple Arm
 6.757 sec M1 Mini, qemu-riscv64 in UbuntuVM  <=== emulating just a RISC-V app
 9.692 sec RISC-V Fedora in qemu in VM on M1  <=== emulating the whole RISC-V OS, MMU etc
10.443 sec Sipeed LM4A TH1520 4x C910 @1.85 GHz  <=== the fastest RISC-V SBC ($119)
12.115 sec Pi4 Cortex A72 @ 1.5 GHz A64
14.885 sec VisionFive 2 U74 _zba_zbb @ 1.5 GHz <=== cheaper RISC-V SBC ($60-$80)


[brucehoult]

I just realised I don't have a result for M1 emulating x86_64 in QEMU instead of Rosetta.  So I just did that now, in Arm Ubuntu in docker. I also repeated QEMU RV64 just to check.

Code: [Select]


 6.935 sec M1 mini qemu-riscv64 in Arm ubuntu VM
11.045 sec M1 mini qemu-x86_64 in Arm ubuntu VM

"There is more to an instruction than just the data word, such things as the carry flag and keeping the higher bits clean for later comparisons."

Yes, and this is exactly why QEMU is much slower emulating x86_64 than emulating riscv64. Making Rosetta all the more remarkable.

[Berni]

Yep apples rosetta compatibility layer is surprisingly fast.

But since Apple makes both the hardware and the OS they had the motivation to put work into it. They no doubt had to have a sizable team of very bright people working on it.

Yet for Microsoft there is not much incentive to develop a high performance compatibility layer. They don't benefit anything from making Intel and AMDs life easier. Once they started messing with ARM they instead pushed for .Net JIT since that's the tech they already had available, so it takes the minimum amount of effort from there side to make apps run on non x86 systems.

[Someone]

I don't see a big issue. Do you really want to run a 32 bit OS?
Because applications will just get a translation layer, and run the 64 bit equivalent of the 32 bit instruction.
What's the big deal? Your int will be 8 bytes long in c?

There is more to an instruction than just the data word, such things as the carry flag and keeping the higher bits clean for later comparisons. I wonder which legacy instructions are difficult to replace with microcode, surely dropping legacy performance by 3-10x would be better than killing it entirely?

Ugh microcode.

If you're happy with a 3-10x performance drop then a simple portable JIT emulator such as QEMU is in that range.

Apple's "Rosetta 2" x86 emulator on Arm has a lot less penalty than that compared to native.

Here are some data points from my primes benchmark (http://hoult.org/primes.txt):

Code: [Select]

2.795 sec Mac Mini M1 @ 3.4 GHz
 2.810 sec Mac Mini M1 arm64 Ubuntu in VM
 2.872 sec i7 6700K @ 4.2 GHz
 2.925 sec Mac Mini M1 @ 3.2 GHz x86_64 Rosetta  <=== x86_64 emulation on Arm
 3.223 sec Threadripper 2990WX @ 4.2 GHz
 3.448 sec Ryzen 5 4500U @ 4.0 GHz WSL2
 3.725 sec AWS C7g graviton3 A64 @ 2.6 GHz   <=== the fastest non-Apple Arm
 6.757 sec M1 Mini, qemu-riscv64 in UbuntuVM  <=== emulating just a RISC-V app
 9.692 sec RISC-V Fedora in qemu in VM on M1  <=== emulating the whole RISC-V OS, MMU etc
10.443 sec Sipeed LM4A TH1520 4x C910 @1.85 GHz  <=== the fastest RISC-V SBC ($119)
12.115 sec Pi4 Cortex A72 @ 1.5 GHz A64
14.885 sec VisionFive 2 U74 _zba_zbb @ 1.5 GHz <=== cheaper RISC-V SBC ($60-$80)

I just realised I don't have a result for M1 emulating x86_64 in QEMU instead of Rosetta.  So I just did that now, in Arm Ubuntu in docker. I also repeated QEMU RV64 just to check.

Code: [Select]

6.935 sec M1 mini qemu-riscv64 in Arm ubuntu VM
11.045 sec M1 mini qemu-x86_64 in Arm ubuntu VM


As much as microcode might be unpleasant, it's already there in both major x86 vendors so would be a "small" change that retains the software compatibility. How much area/power would it save? probably very little.

[brucehoult]

As much as microcode might be unpleasant, it's already there in both major x86 vendors so would be a "small" change that retains the software compatibility. How much area/power would it save? probably very little.

Well, enough that Apple took 32 bit compatibility out of their chips starting with the iPhone 8 in 2017 (A11). Arm is not including 32 bit support in any of their ARMv9 cores, except for the Cortex-A710 which supports 32 bit in EL0 only. I'm not 100% sure, but I think the A55 is the most recent core that can boot 32 bit OSes.

[wraper]

MIPS, HPPA, SPARC, PowerPC were superior architectures and had 64-bit back in the 2000s! More than 20 years ahead of x86!

What? Intel had 64 bit Itanium launched in 2001 and it eventually completely died a few years ago as it did not gain enough popularity. As of 64-bit x86, AMD launched Opteron and Athlon 64 in 2003 and Intel followed soon after by launching 64 bit Xeon and Prescott Pentium 4 "F" in 2004.
Also I have doubts about claims of superiority. Apple and Gaming consoles ditched PowerPC in favor of x86.