Intel considering making new CPUs 64 bit only - Page 1
Forum section: electronics / general

author: NiHaoMike
author_rank: Super Contributor
timestamp: May 21, 2023, 09:07:34 pm
content: https://www.intel.com/content/www/us/en/developer/articles/technical/envisioning-future-simplified-architecture.htmlMy 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 21, 2023, 09:33:51 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 21, 2023, 09:40:04 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: May 21, 2023, 09:44:05 pm
content: 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?

author: floobydust
author_rank: Super Contributor
timestamp: May 21, 2023, 10:14:29 pm
content: Consult the Intel Management Engine for the answerThe X86-Sspecis 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 22, 2023, 12:46:33 am
content: 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.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: May 22, 2023, 03:27:40 am
content: Wouldn't they go better making sure their microcode is water tight.

author: Berni
author_rank: Super Contributor
timestamp: May 22, 2023, 05:35:52 am
content: 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.

author: David Hess
author_rank: Super Contributor
timestamp: May 22, 2023, 08:59:25 am
content: 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.

author: eutectique
author_rank: Frequent Contributor
timestamp: May 22, 2023, 07:03:48 pm
content: TerminaItanium 2 : Le Jugement dernier. And revive the compiler, as well.

author: tszaboo
author_rank: Super Contributor
timestamp: May 22, 2023, 07:37:54 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: May 22, 2023, 08:08:08 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 22, 2023, 08:16:08 pm
content: But, you will own nothing and be happy!

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: May 22, 2023, 08:21:54 pm
content: Quote from: tszaboo on May 22, 2023, 07:37:54 pmI 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.

author: bw2341
author_rank: Regular Contributor
timestamp: May 22, 2023, 09:10:07 pm
content: Quote from: brucehoult on May 22, 2023, 12:46:33 amWell, since theIntel® 64 architectureis a licensed version ofAMD64, 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.

author: Someone
author_rank: Super Contributor
timestamp: May 22, 2023, 09:20:35 pm
content: Quote from: tszaboo on May 22, 2023, 07:37:54 pmThere 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?

author: langwadt
author_rank: Super Contributor
timestamp: May 22, 2023, 10:09:56 pm
content: Quote from: Someone on May 22, 2023, 09:20:35 pmwhat does Apple do with their ARM?

author: james_s
author_rank: Super Contributor
timestamp: May 23, 2023, 12:58:16 am
content: Quote from: DiTBho on May 21, 2023, 10:45:34 pmYou'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.

author: james_s
author_rank: Super Contributor
timestamp: May 23, 2023, 01:00:33 am
content: Quote from: langwadt on May 22, 2023, 10:09:56 pmI 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 23, 2023, 02:49:08 am
content: Quote from: Someone on May 22, 2023, 09:20:35 pmUgh 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:2.795 sec Mac Mini M1 @ 3.4 GHz2.810 sec Mac Mini M1 arm64 Ubuntu in VM2.872 sec i7 6700K @ 4.2 GHz2.925 sec Mac Mini M1 @ 3.2 GHz x86_64 Rosetta <=== x86_64 emulation on Arm3.223 sec Threadripper 2990WX @ 4.2 GHz3.448 sec Ryzen 5 4500U @ 4.0 GHz WSL23.725 sec AWS C7g graviton3 A64 @ 2.6 GHz <=== the fastest non-Apple Arm6.757 sec M1 Mini, qemu-riscv64 in UbuntuVM <=== emulating just a RISC-V app9.692 sec RISC-V Fedora in qemu in VM on M1 <=== emulating the whole RISC-V OS, MMU etc10.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 A6414.885 sec VisionFive 2 U74 _zba_zbb @ 1.5 GHz <=== cheaper RISC-V SBC ($60-$80)

author: brucehoult
author_rank: Super Contributor
timestamp: May 23, 2023, 03:16:34 am
content: 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:6.935 sec M1 mini qemu-riscv64 in Arm ubuntu VM11.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.

author: Berni
author_rank: Super Contributor
timestamp: May 23, 2023, 05:18:56 am
content: 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.

author: Someone
author_rank: Super Contributor
timestamp: May 23, 2023, 06:55:50 am
content: Quote from: brucehoult on May 23, 2023, 02:49:08 amQuote from: brucehoult on May 23, 2023, 03:16:34 amAs 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 23, 2023, 08:02:30 am
content: Quote from: Someone on May 23, 2023, 06:55:50 amWell, 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.

author: wraper
author_rank: Unknown
timestamp: May 23, 2023, 09:35:45 am
content: Quote from: DiTBho on May 23, 2023, 09:10:55 amWhat? 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.

author: tszaboo
author_rank: Super Contributor
timestamp: May 23, 2023, 10:10:45 am
content: Quote from: Ed.Kloonk on May 22, 2023, 08:21:54 pmYou 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.Quote from: ataradov on May 22, 2023, 08:08:08 pmI 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.

author: David Hess
author_rank: Super Contributor
timestamp: May 23, 2023, 12:47:40 pm
content: Quote from: DiTBho on May 23, 2023, 09:10:55 amUm, yes, register windows, branch delay slots, and lack of shorter width ALU operations (Alpha) were marvelous successes.QuoteThe 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.

author: wraper
author_rank: Unknown
timestamp: May 23, 2023, 04:21:16 pm
content: Quote from: DiTBho on May 23, 2023, 04:00:21 pmYou 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.

author: wraper
author_rank: Unknown
timestamp: May 23, 2023, 04:35:29 pm
content: 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

author: bw2341
author_rank: Regular Contributor
timestamp: May 23, 2023, 06:03:54 pm
content: Quote from: brucehoult on May 23, 2023, 08:02:30 amWhat'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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 24, 2023, 12:01:35 am
content: Quote from: bw2341 on May 23, 2023, 06:03:54 pmThere 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).

author: Someone
author_rank: Super Contributor
timestamp: May 24, 2023, 01:39:38 am
content: Quote from: brucehoult on May 24, 2023, 12:01:35 amIts 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).

author: brucehoult
author_rank: Super Contributor
timestamp: May 24, 2023, 03:44:00 am
content: Quote from: Someone on May 24, 2023, 01:39:38 amI 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 BBEditHarmony 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: discontinuedemacs: I must have installed it for myself sometime. UpdateSo, 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.

author: james_s
author_rank: Super Contributor
timestamp: May 24, 2023, 06:45:26 pm
content: Quote from: David Hess on May 23, 2023, 12:47:40 pmThe 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.

author: james_s
author_rank: Super Contributor
timestamp: May 24, 2023, 06:48:17 pm
content: Quote from: bw2341 on May 23, 2023, 06:03:54 pmI 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.

author: james_s
author_rank: Super Contributor
timestamp: May 24, 2023, 06:52:27 pm
content: Quote from: wraper on May 23, 2023, 04:21:16 pmHe 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.

author: james_s
author_rank: Super Contributor
timestamp: May 24, 2023, 06:58:48 pm
content: Quote from: DiTBho on May 23, 2023, 09:10:55 amPeople 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?

author: langwadt
author_rank: Super Contributor
timestamp: May 24, 2023, 07:06:41 pm
content: Quote from: james_s on May 24, 2023, 06:45:26 pmI'm guessing CPU speed vs. memory speed also had a hand in going less RISC.

author: james_s
author_rank: Super Contributor
timestamp: May 24, 2023, 07:07:14 pm
content: Quote from: Berni on May 23, 2023, 05:18:56 amWindows 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.

author: james_s
author_rank: Super Contributor
timestamp: May 24, 2023, 07:20:31 pm
content: Quote from: DiTBho on May 23, 2023, 09:10:55 amNonsense. 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 24, 2023, 08:22:34 pm
content: Quote from: james_s on May 24, 2023, 07:07:14 pmWas? 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 24, 2023, 08:23:09 pm
content: Quote from: tszaboo on May 22, 2023, 07:37:54 pmInterestingly 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 24, 2023, 08:27:40 pm
content: Quote from: james_s on May 24, 2023, 07:07:14 pmI 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.

author: alm
author_rank: Super Contributor
timestamp: May 24, 2023, 10:20:45 pm
content: Quote from: DiTBho on May 24, 2023, 10:13:13 pmThanks for so eloquently making James's point

author: DiTBho
author_rank: Super Contributor
timestamp: May 24, 2023, 11:38:56 pm
content: QuoteFor 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.

author: David Hess
author_rank: Super Contributor
timestamp: May 25, 2023, 12:16:42 am
content: Quote from: SiliconWizard on May 24, 2023, 08:22:34 pmApple 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.QuoteHistorically that was a big problem for RISC and an advantage for x86. "Just recompile" failed almost every time. Apple and IBM managed it.QuoteBefore 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 25, 2023, 01:52:59 am
content: Quote from: james_s on May 24, 2023, 06:45:26 pmThe 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.QuoteCISC 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.QuoteCISC 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.

author: brucehoult
author_rank: Super Contributor
timestamp: May 25, 2023, 01:59:22 am
content: Quote from: langwadt on May 24, 2023, 07:06:41 pmFor 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.

author: james_s
author_rank: Super Contributor
timestamp: May 25, 2023, 05:50:08 am
content: Quote from: DiTBho on May 24, 2023, 11:38:56 pmThis 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.

author: james_s
author_rank: Super Contributor
timestamp: May 25, 2023, 05:54:44 am
content: Quote from: brucehoult on May 25, 2023, 01:52:59 amThis 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.

author: Berni
author_rank: Super Contributor
timestamp: May 25, 2023, 06:27:54 am
content: Quote from: nctnico on May 24, 2023, 08:27:40 pmMicrosoft did have some early success in the mobile ARM space.Not only with Windows CE but also with Windows Mobile/Smartphone. For a bit it did also support MIPS, but that was soon dropped and became ARM only. It was the dominant OS for PDAs and smartphones during about 2000 to 2010Back then the first iPhone was not released yet and Android was not a thing yet. At that time it was an impressive feature for a phone to be able to play back a mp3 file. But Microsofts mobile OS could run native executables and had devices with reasonably powerful hardware. So it soon upped the party trick of a mp3 file onto being able to play most video files that PCs can play, open MS Office files, open desktop wepages (including javascript and flash), supported expandable memory, usb support, hardware accelerated graphics..etc. It had a lot of software ported over to it, game developers even ported entire PC games to it. Fair few companies now make Android phones(HTC, Samsung, LG, Sony) have started off making Windows Mobile devices (but then quickly jumped ship to Android due to Microsofts exorbitant licensing fees).But then the iPhone and Android came around and made Windows Mobiles old simplistic UI look outdated (tho funny enough the Win10 UI now looks similar). So Microsoft came up with a 'brilliant' idea to redo the entire OS and rebrand it as "Windows Phone 7" we all know quickly that ship sank. It threw away all backwards compatibility in exchange for a modern UI and fitting into this Microsofts vision of unified UI across all there products, PC,Mobile,Gaming..etcAs an actual OS it had its good and bad sides. It was a sort of from the ground up imitation of PC Windows. It runs from a file system that you can freely access, it has similar folder structures (Windows, Program Files, My Documents). It runs *.exe executable and loads DLLs, it has a registry, the UI works similar to WinForms, it carries over DirectShow and DirectDraw APIs for hardware graphics and media. They really tried to pack as much Windows-ness into the couple of MB they had available. Later on it got .Net framework and this made the same EXE file run both on WindowsMobile or Windows XP, Keep in mind that years later the iPhone launched and it couldn't even do multitasking for years. But the OS did take shortcuts, memory protection was barely existent, it used persistant RAM as file storage (early versions only), native executables not only had to be compiled specifically for it, but also for the ARM or MIPS variant separately, it did need a reboot every few weeks.Over all Windows CE/Mobile was a pretty good product given the time period and technical limitations. Just that Microsoft ended up running it into the ground with its aggressive business practices.

author: brucehoult
author_rank: Super Contributor
timestamp: May 25, 2023, 07:49:31 am
content: Quote from: james_s on May 25, 2023, 05:54:44 amYou mean "precise". The ISA is the most important interface in a computer -- it is how the programmer speaks to and instructs the hardware.QuoteWhich still makes the instruction set primary.By corollary , a "CISC CPU" is a CPU that has a CISC instruction set.And by extension "a computer that 'has a CISC instruction set' does not 'have RISC underneath'."

author: David Hess
author_rank: Super Contributor
timestamp: May 25, 2023, 05:01:45 pm
content: Quote from: brucehoult on May 25, 2023, 07:49:31 amDoesn't it? CISC legacy instructions are translated into longer fixed width RISC instructions which are then reordered and dispatched into multiple (superscalar) pipelines. That sure seems like RISC underneath.Does your statement mean that RISC chips which support instruction compression are not RISC? What about RISC chips which support instruction fusion?

author: ejeffrey
author_rank: Super Contributor
timestamp: May 26, 2023, 03:36:12 am
content: Quote from: Berni on May 22, 2023, 05:35:52 amI don't think they are taking about removing the ability to run 32 bit code. 32 bit code is directly l supported in long mode. As far as I can tell they are only talking about removing the non 64 bit operating modes of the CPU - real mode, 16 bit protected mode, 32 bit protected mode, and vm86, and booting directly to long mode. It would only affect the boot sequence and the ability to run 16 and 32 but operating systems.

author: brucehoult
author_rank: Super Contributor
timestamp: May 26, 2023, 05:36:30 am
content: Quote from: David Hess on May 25, 2023, 05:01:45 pmThe µops that current x86 CPUs translate the original x86 code into are nothing like RISC. They are still, for example memory-register operations, not load/store and then register-to-register for arithmetic. For example, in Zen 1 to Zen 3, adding a register or constant to memory (a read-modify-write operation) is just 1 µop, though quite high 6-8 cycle latency. Very much a CISC implementation. On RISC it would be three instructions. On Intel since Core 2 it's 2 µops -- slightly broken down, but not RISC.QuoteWhat do you mean by compression? Two instruction lengths?Almost all the early RISC ISAs had two instruction lengths:- CDC6600: 15 and 30 bits- Cray 1: 16 and 32 bits- IBM 801: 16 and 32 bits- Berkeley RISC II 16 and 32 bits (RISC I was a quick&dirty test chip that didn't work properly anyway)It was only for about ten years from 1985-1995 that RISC ISAs had a single 32 bit instruction length.Two lengths have been the norm both before and after that decade.Hitachi Super-H started with 16-bit instructions only, then added 32 bit. Arm licensed Hitachi's patents for the Thumb 16 bit instructions, MIPS did MIPS16. RISC-V of course was designed from the outset to support both 16 and 32 bit instruction lengths.The only RISC ISA since 1995 that hasn't had two instruction lengths is Aarch64. I was extremely surprised by this when I read the ISA manual in October 2012. It seemed like such a huge mistake after the great success of Thumb2, leading to poor code density. It seemed even more like a mistake after RISC-V appeared a few years later with two instruction lengths and much better code density.QuoteThat is implementation, not ISA. RISC is about ISA.

author: james_s
author_rank: Super Contributor
timestamp: May 27, 2023, 12:49:32 am
content: Quote from: brucehoult on May 25, 2023, 07:49:31 amI still say it's pedantic.The whole RISC vs CISC thing is largely irrelevant today anyway. Traditionally CISC processors have adopted techniques pioneered by RISC processors, while RISC processors have become more complex. Where exactly is the boundary between RISC and CISC anymore? I don't think it's clear cut. Certainly not anything like it used to be. Most software developers today don't directly touch the hardware, they don't care about the instruction set. The entire platform my company builds is written in Python and Javascript.

author: SiliconWizard
author_rank: Super Contributor
timestamp: May 27, 2023, 01:02:02 am
content: Quote from: james_s on May 27, 2023, 12:49:32 amCondolences.

author: brucehoult
author_rank: Super Contributor
timestamp: May 27, 2023, 01:31:27 am
content: Quote from: james_s on May 27, 2023, 12:49:32 amEngineers are required to be pedantic, in order that bridges and planes don't fall down.QuoteRepetition is not proof.QuoteYou're quite right that most developers, let alone users, don't have any reason to care about the instruction set, as long as their computer is fast enough.That is why it doesn't matter that your opinions are wrong. You're not the one designing the bridges and planes.It matters a lot to the people writing the JIT your Javascript requires to run at decent performance.

author: David Hess
author_rank: Super Contributor
timestamp: May 27, 2023, 09:59:53 am
content: Quote from: brucehoult on May 27, 2023, 01:31:27 amLinus Torvalds has talked about that in the past. The ironic thing is that some aspects of available RISC designs, like relaxed memory ordering and paging, make them *slower* than x86 in those sorts of applications. Operating systems like MacOS have the same problems compared to Linux and sometimes even Windows.The rare cases which RISC processors decline to handle can have large effects on performance in practical systems. Some operations are just better handled in hardware.