Intel considering making new CPUs 64 bit only

[tszaboo]

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.

You can run old OSes on VMs. They have better compatibility overall. I haven't seen the need to install desktop linux for the past decade, because I could just run them in VMs.

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.

I know they stated that the backward compatibility is only a few million transistors. On the other hand they must have a good reason to do this. Could be that the parts cannot be clocked faster without reworking this part. And nobody remembers how it works anymore, or dares touching it. Or they slow down the boot time.

[David Hess]

MIPS, HPPA, SPARC, PowerPC were superior architectures and had 64-bit back in the 2000s!

Um, yes, register windows, branch delay slots, and lack of shorter width ALU operations (Alpha) were marvelous successes.

Sure, they failed, and it happened only because x86 was cheaper and full of crappy cheap software made by crappy companies like Microsoft.

The other RISC processors failed because Intel could spend 10 times more than every RISC developer combined on research and development.  The reason so many RISC processors were developed at that time was that a small design team could do it and for a while yield performance comparable or marginally better than x86 with a tenth of the budget.

Some of the RISC processors survived.  Power had IBM's deep pockets and customers.  ARM did what Intel did, and was less of a RISC processor to start with.

[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

for example, the MIPS4 R10K was introduced in January 1996 at clock frequencies @175 MHz and @195 MHz as superscalar, pipelined, and 64bit CPU!

2023 - 1996 -> more than 20 years ahead of this "x86-64-bit-only" news 

Programming it is pure fun! Supporting it (even with firmware like YaMon, a kind of "Yaboot" but for MIPS) is of several years ahead, and its ecosystem is clean, coherent, and solid! Plus the manual is only 120 pages, covering everything, from SMP to ISA, to multi-processing!

Only 120 pages!!!

You said they had 64 bit 20 years ahead, not lacked backwards compatibility 20 years ahead  . And BTW Intel Itanium was 64 bit only in 2001 and did not have backwards compatibility to anything as it was entirely new architecture .

[wraper]

Windows XP ran on 64 bit only Itanium since 2001. So you could use 64 bit only Intel and Windows for more than 2 decades if you had such wish.  https://betawiki.net/wiki/Windows_XP_64-Bit_Edition

[bw2341]

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.

What's the opposite of backward compatibility? The 32-bit apps on the App Store that weren't upgraded to 64-bit are gone forever as older iPhones are retired.

Apple did the same thing on the Mac. MacOS 10.14 Mojave was the last to support 32-bit Intel Mac software. MacOS 10.15 Catalina can't run 32-bit Intel Mac software at all. There's no hardware reason for this as Apple uses normal Intel processors. Just like on the iPhone, this leaves abandoned 32-bit Intel Mac software stuck on older Mac hardware and older versions of macOS.

They most likely did this to simplify the switch to the M1 processor. MacOS 11 Big Sur uses Rosetta 2 to run Intel Mac software on the M1. Since they just got rid of 32-bit Intel Mac software support, a 64-bit only design for Rosetta 2 would be a lot simpler in hardware and software.

[brucehoult]

Apple did the same thing on the Mac. MacOS 10.14 Mojave was the last to support 32-bit Intel Mac software.

There shouldn't be much 32 bit Intel Mac software -- Apple only sold 32 bit hardware for a short time, mostly in 2006: 1.83 and 2.0 GHz Core Duo iMac from January to September,  13" MacBook from May to November, 15" and 17" MacBook Pro from January to October. There was a Core Solo Mac Mini from February to September, and Core Duo from February 2006 until August 2007.

None of them can run anything newer than Snow Leopard, not Lion (July 2011).

[Someone]

Apple did the same thing on the Mac. MacOS 10.14 Mojave was the last to support 32-bit Intel Mac software.

There shouldn't be much 32 bit Intel Mac software -- Apple only sold 32 bit hardware for a short time, mostly in 2006: 1.83 and 2.0 GHz Core Duo iMac from January to September,  13" MacBook from May to November, 15" and 17" MacBook Pro from January to October. There was a Core Solo Mac Mini from February to September, and Core Duo from February 2006 until August 2007.

None of them can run anything newer than Snow Leopard, not Lion (July 2011).

Its more that there was nothing forcing software developers/distributors from pushing out 32bit code, so it persisted well beyond when it was necessary (Adobe being an easy target, but first party apps did it too).

[brucehoult]

Apple did the same thing on the Mac. MacOS 10.14 Mojave was the last to support 32-bit Intel Mac software.

There shouldn't be much 32 bit Intel Mac software -- Apple only sold 32 bit hardware for a short time, mostly in 2006: 1.83 and 2.0 GHz Core Duo iMac from January to September,  13" MacBook from May to November, 15" and 17" MacBook Pro from January to October. There was a Core Solo Mac Mini from February to September, and Core Duo from February 2006 until August 2007.

None of them can run anything newer than Snow Leopard, not Lion (July 2011).

Its more that there was nothing forcing software developers/distributors from pushing out 32bit code, so it persisted well beyond when it was necessary (Adobe being an easy target, but first party apps did it too).

I actually checked my father's laptop for 32 bit software last month (on my first visit to my parents' house since before COVID ... though I'd seen them elsewhere plenty of times), preparatory to upgrading him past Mojave sometime soon.

I found the following (ignoring apps that had not been run in more than 10 years):

TextWrangler: discontinued, replace with BBEdit

Harmony Assistant: update. Need to email them with old license number to replace it with a new one.

PAW2U -- genealogy software (free). The author was promising to update it to 64 bit in 2018, but no sign of it.

NZSG Kiwi Collection / Kiwi Index: More genealogy. There is some update, but it's now a subscription service not a one-time payment.

iDVD: discontinued

emacs: I must have installed it for myself sometime. Update

So, sadly, there are two things he uses every day that prevent upgrading.

I plan to set up a Snow Leopard virtual machine to run the old stuff in. Haven't done it yet.

[james_s]

The other RISC processors failed because Intel could spend 10 times more than every RISC developer combined on research and development.  The reason so many RISC processors were developed at that time was that a small design team could do it and for a while yield performance comparable or marginally better than x86 with a tenth of the budget.

Some of the RISC processors survived.  Power had IBM's deep pockets and customers.  ARM did what Intel did, and was less of a RISC processor to start with.

The RISC concept came about because at the time silicon was expensive and software was cheap in the sense that you write it once and then make as many copies as you need. The idea was to simplify the hardware thus reducing its cost at the expense of making the software more complex. The cost of silicon fell to the point where it didn't really make sense to focus so much on simplifying the hardware. Over time RISC CPUs became more complex and traditionally CISC CPUs started to adopt some of the features developed with RISC CPUs and the line blurred.

Bottom line is it is irrelevent, absolutely no normal person cares one bit what CPU architecture they're using. They care about compatibility, performance and cost. x86 dominates because it is the best all around compromise and has by far the largest library of supported software.

[james_s]

What's the opposite of backward compatibility? The 32-bit apps on the App Store that weren't upgraded to 64-bit are gone forever as older iPhones are retired.

I was annoyed by this. When Apple dropped 32 bit support on iOS I lost use of several older apps that I had paid for and was using. I gained nothing tangible, the only visible difference was that functionality I had paid for and was using was taken away.

[james_s]

You said they had 64 bit 20 years ahead, not lacked backwards compatibility 20 years ahead  . And BTW Intel Itanium was 64 bit only in 2001 and did not have backwards compatibility to anything as it was entirely new architecture .

He has no idea what he's talking about, it's just a strong emotional dislike of x86, there is no rational logic behind it. He thinks people should spend more on hardware to get less functionality for purely ideological reasons that 99.999% of the population doesn't care about at all because I guess there is some reason a user should give a rat's ass how the CPU in their computer works. 

[james_s]

x86 and, worse still, its x86-ecosystem, from x86-only-hardware to x86-oriented-software, technically sucks, every technical people knows it, and it's defacto standard only thanks to people like you, who are fine with dog excrement as long as it's at a very low cost.

MIPS, HPPA, SPARC, PowerPC were superior architectures and had 64-bit back in the 2000s! More than 20 years ahead of x86! Sure, they failed, and it happened only because x86 was cheaper and full of crappy cheap software made by crappy companies like Microsoft.

People like me are the vast majority of the population, and people like you that feel strongly about this are fringe outsiders. The sooner you realize this, the easier your life will be. My x86 machines work just fine, they're only "dog excrement" in your mind, the rest of us can't see these nebulous flaws you continually rant about. Frankly this is starting to have the appearance of some sort of mental illness. No rational person cares what CPU architecture is in their computer so long as it runs the software they need. Do you care what microcontroller core is in your multimeter too? Does the brand of driver IC in your LED lightbulbs keep you up at night?

[langwadt]

The other RISC processors failed because Intel could spend 10 times more than every RISC developer combined on research and development.  The reason so many RISC processors were developed at that time was that a small design team could do it and for a while yield performance comparable or marginally better than x86 with a tenth of the budget.

Some of the RISC processors survived.  Power had IBM's deep pockets and customers.  ARM did what Intel did, and was less of a RISC processor to start with.

The RISC concept came about because at the time silicon was expensive and software was cheap in the sense that you write it once and then make as many copies as you need. The idea was to simplify the hardware thus reducing its cost at the expense of making the software more complex. The cost of silicon fell to the point where it didn't really make sense to focus so much on simplifying the hardware. Over time RISC CPUs became more complex and traditionally CISC CPUs started to adopt some of the features developed with RISC CPUs and the line blurred.

I'm guessing CPU speed vs. memory speed also had a hand in going less RISC.

[james_s]

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.

Windows ARM was a spectacular failure that cost the company billions. It was a product called "Windows" that didn't support the vast library of "legacy" Windows software, it was blindingly obvious to me when I first heard it announced that it was going to fail. People buy Windows precisely because it has the largest library of software. If it doesn't support that software then there's no reason to bother with Windows. It's one of those "you had one job" situations. The ONLY reason for Windows to exist is the software that works under it, and running software is the entire reason most people have a computer. The entire world population of people that write BIOS or do bare metal programming for personal computers could probably fit in one room.

[james_s]

Computer piracy, that's it! The 90s-2000s fashion of sharing commercial programs between users was/is one of the driving reasons for not having promoted systems like IRIX or HPPA, where things worked under license, and cracking them was impossible at the time.

So, to me, from x86 datasheets to the "PeeeeeeCeeeeee-culture", everything that revolves around x86 is rotten and only deserves to die as soon as possible so as not to ruin computing again.

Nonsense. I had a couple of SGI machines for a while that ran IRIX and I still have several Sun machines with Solaris, have you looked at what those workstations cost at the time? They were 10 times the cost of a comparable x86 machine, and after a while they lost their performance edge. In the real world you can't expect someone to pay 10 times as much for tools when something cheaper does the same thing better. People buy tools to get work done, not to marvel at the tools.

Seriously, seek help, find a good therapist, I think it could really help you think more rationally and feel less angry. Computing hasn't been "ruined", it has evolved. Computers are cheap, ubiquitous, mature commodities. They're everywhere, and Linux has made internal architecture less relevant than ever. The 90s and earlier eras of personal computing are gone forever. We're never going to see a revolutionary new CPU architecture that is greatly superior to another again. Virtually all gains going forward are going to be either reducing cost or reducing power consumption.

[SiliconWizard]

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.

Windows ARM was a spectacular failure that cost the company billions.

Was? It's not dead. There is a version of Windows 11 for ARM. They're just waiting for the market to open.
MS has not been very successful on anything mobile, where ARM dominates. So unless there's a miracle there, they'll have to wait till ARM becomes more common on the desktop.
It may or may not happen. As I said earlier, Apple has at least shown everyone that ARM-based CPUs for desktop computing was a credible option. Will other vendors follow to make non-Apple, ARM-based CPUs able to compete with current x86 ones? I don't know yet. Some think (or hope?) that RISC-V will eventually take that segment rather than ARM.

Software-wise, that's of course another matter. What proportion of software vendors are ready to build/port their software to ARM CPUs? It's hard to tell.
Anything Java-based is probably not going to be a problem, but otherwise that is not unlikely to give headaches for many vendors.
That's just what you pay when you've been sticking to a single platform for several decades. Changing is hard.
But it eventually happens. Always.

Intel has always had troubles trying to get rid of the x86 ISA. So many would consider trying it again a mistake. Heck, here we're not even talking about Intel's new CPUs being a different ISA, but just getting rid of the 32-bit mode, and it already looks like a major hurdle. Yet, if they don't end up with something brand new, they will eventually die.

That's the conundrum of almost all large companies with an established business and standard. IBM has been in the same boat. And many others.
You can't really innovate, yet if you don't, you'll die. That's somehow what's called being a victim of your own success.

"The Innovator's Dilemma" talks about this in great lengths.

[nctnico]

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?

Interestingly int is still 32 bit on many 64 bit architectures. Beyond that, there is quite a bit of software that may rely on a unsigned integer wrapping to 0 when going beyond 32 bits.

IOW: You have to be really careful with what is going to be 64 bit and what is not. Typically it is only the pointers that get affected by running on a 32 or 64 bit machine. So dumping 32 bit support more or less means dumping support to run software in a memory spaces limited to 4GB.

[nctnico]

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.

Windows ARM was a spectacular failure that cost the company billions. It was a product called "Windows" that didn't support the vast library of "legacy" Windows software, it was blindingly obvious to me when I first heard it announced that it was going to fail. People buy Windows precisely because it has the largest library of software.

I agree. But this was already the case with Windows CE that had some kind of translation layer to mimic Windows. It wasn't Windows at all; you'd have to rewrite all your code. There where stupid limits like being able to wait for 1 semaphore at a time or something like that. And no filesystem support as well. Linux OTOH has always been the real deal on any platform which makes cross platform development using Linux so easy and productive.

[alm]

People like me are the vast majority of the population, and people like you that feel strongly about this are fringe outsiders. The sooner you realize this, the easier your life will be. My x86 machines work just fine, they're only "dog excrement" in your mind, the rest of us can't see these nebulous flaws you continually rant about. Frankly this is starting to have the appearance of some sort of mental illness. No rational person cares what CPU architecture is in their computer so long as it runs the software they need. Do you care what microcontroller core is in your multimeter too? Does the brand of driver IC in your LED lightbulbs keep you up at night?

You never read a book written by Andrew S. Tanenbaum.
You never played with x86 assembly. Enjoy my ignore list.

Thanks for so eloquently making James's point 

[DiTBho]

people like you that feel strongly about this are fringe outsiders. The sooner you realize this, the easier your life will be. My x86 machines work just fine.
No rational person cares what CPU architecture is in their computer so long as it runs the software they need.

For a living, I design and support ICEs; debuggers are the most important tools for developers, they help with writing and testing software, without software we don't have working computers, but only a few care about the work of people like me.

When you are in close contact with the hardware, when you have to write a disassembler or deal with it for the ICE you have to support your customers, you really care if the architecture in front of you makes your life easier or not. And they're all products that we sell, and that developers use!

x86 and intel products are all frustrating because too difficult to support, and it's frankly a pity that in a technical forum, people don't care too much about debuggers and architectures and I don't feel at all comfortable.

I mean, I can accept that people don't care/have different priorities, but I really don't like James's tone above even because he insists on deliberately ignoring given technical points.

That's as annoying as useless. So, I deleted all my posts on this topic and I won't give more.
Good continuation.

[David Hess]

It may or may not happen. As I said earlier, Apple has at least shown everyone that ARM-based CPUs for desktop computing was a credible option. Will other vendors follow to make non-Apple, ARM-based CPUs able to compete with current x86 ones? I don't know yet. Some think (or hope?) that RISC-V will eventually take that segment rather than ARM.

Apple has shown that MacOS running on their own ARM based desktops are a viable desktop option, but Apple is not a microprocessor company and their developments and economy of scale are not available to others who might use their processors but not their hardware and operating system.

Intel does not have to fight a single ARM behemoth, but a bunch of incompatible ARM midgets, which also describes the RISC era.

Software-wise, that's of course another matter. What proportion of software vendors are ready to build/port their software to ARM CPUs? It's hard to tell.

Historically that was a big problem for RISC and an advantage for x86.  "Just recompile" failed almost every time.  Apple and IBM managed it.

That's just what you pay when you've been sticking to a single platform for several decades. Changing is hard.
But it eventually happens. Always.

Before when we changed, we gained something significant.  What is an alternative going to give me now that my current x86 workstation lacks?  More memory?  Better expansion?  Higher performance?  So far all of the alternatives are worse in all of those.

We already had the change so many want.  People who used x86 PCs for applications which did not require that much performance now use their phones instead, and the x86 PC market survived and remained viable, even for gamers.

[brucehoult]

The RISC concept came about because at the time silicon was expensive and software was cheap in the sense that you write it once and then make as many copies as you need. The idea was to simplify the hardware thus reducing its cost at the expense of making the software more complex.

The chief idea of RISC was to increase performance by a factor of maybe five by enabling simple instructions to be pipelined at one instruction per clock cycle, instead of having microcode and/or sequencers execute them in half a dozen clock cycles per instruction. RISC also enables superscalar execution with multiple instructions executing at the same time, and even Out of Order.

All of this was present in the first RISC computer (though the term wasn't invented for another 15+ years), Seymour Cray's CDC6600 in 1964.

The cost of silicon fell to the point where it didn't really make sense to focus so much on simplifying the hardware.

CISC came about not because of the cost of hardware, but the cost of programmers, and the fact that, contrary to what you write, people did NOT "write it once and then make as many copies as you need". On the contrary, almost every program was custom-written within the organisation in which it was used.

Over time RISC CPUs became more complex and traditionally CISC CPUs started to adopt some of the features developed with RISC CPUs and the line blurred.

CISC or RISC is a property of instruction sets, not of CPUs.

The most complex RISC instruction sets were the FIRST ones ... ARM, SPARC, PA-RISC. RISC ISAs developed after 1990 -- DEC Alpha, ARM Aarch64, RISC-V -- have notably pure and simple instructions. The Arm a little less so than the other two, no doubt due to a desire to be more compatible with its predecessor, especially as both had to run on the same pipeline and register set for the first ten years.

[brucehoult]

The other RISC processors failed because Intel could spend 10 times more than every RISC developer combined on research and development.  The reason so many RISC processors were developed at that time was that a small design team could do it and for a while yield performance comparable or marginally better than x86 with a tenth of the budget.

Some of the RISC processors survived.  Power had IBM's deep pockets and customers.  ARM did what Intel did, and was less of a RISC processor to start with.

The RISC concept came about because at the time silicon was expensive and software was cheap in the sense that you write it once and then make as many copies as you need. The idea was to simplify the hardware thus reducing its cost at the expense of making the software more complex. The cost of silicon fell to the point where it didn't really make sense to focus so much on simplifying the hardware. Over time RISC CPUs became more complex and traditionally CISC CPUs started to adopt some of the features developed with RISC CPUs and the line blurred.

I'm guessing CPU speed vs. memory speed also had a hand in going less RISC.

For a time, ROM was faster than RAM, and ROM filled with microcode was a reasonable design decision. But then SRAM became faster than ROM and the microcode was copied from ROM (or floppy disk) into SRAM at boot time. Then some companies started to allow users to add their own microcode, but that was an extremely difficult and error-prone process.

Once you had a few KB of that fast SRAM, using it as instruction cache -- and making the instructions simple enough to be their own microcode -- became the way to go.

[james_s]

For a living, I design and support ICEs; debuggers are the most important tools for developers, they help with writing and testing software, without software we don't have working computers, but only a few care about the work of people like me.

When you are in close contact with the hardware, when you have to write a disassembler or deal with it for the ICE you have to support your customers, you really care if the architecture in front of you makes your life easier or not. And they're all products that we sell, and that developers use!

This illustrates my point exactly. You are a fringe outsider that does something for a living that an extraordinarily small number of people does. You have to realize that only maybe 0.000002% of computer users worldwide are in close contact with the hardware. Absolutely zero users interact directly with the hardware, and only an incredibly small minority of professional software developers ever does that. Every modern operating system has a HAL for a reason, people developing software don't have to care how the computer works, they only have to understand the APIs. Hundreds of millions of people use computers without having a clue how they work at all, even most professional developers are never going to touch assembly. I've spent my entire career in the software industry and even way back when I worked for a certain large tech company everyone has heard of, I never actually met any of the guys that did the low level stuff, everyone I worked with used C++.  I can understand why you would care about the underlying architecture, but my point is you simply cannot expect the vast majority of computer users to know or care, or value any of the traits that you value. The architecture is simply not relevant to them. 

[james_s]

CISC or RISC is a property of instruction sets, not of CPUs.

This is being rather pedantic. The instruction set and CPU are inextricably linked, so by being a property of the instruction set, it is by extension a property of the CPU. It is perfectly valid to refer to a "RISC CPU", it means "a CPU that has a reduced instruction set.

I'm not old enough to remember the developments of the 60s-70s, the first time I ever heard of a RISC CPU was sometime in the 90s when I learned about the Sun Sparc and later PowerPC.