How about removing obsolete stuff from 86x CPUs to make the platform perform better? If someone need to execute old programs/OSes they can use emulators for that...
> As of November 2020, all supercomputers on TOP500 are 64-bit, mostly based on CPUs using the x86-64 instruction set architecture (of which 459 are Intel EMT64-based and 22 are AMD AMD64-based. The few exceptions are all based on RISC architectures). Thirteen supercomputers, including the no 2. and no. 3 are based on the Power ISA used by IBM POWER microprocessors, three on Fujitsu-designed SPARC64 chips. One computer uses another non-US design, the Japanese PEZY-SC (based on the British ARM[8]) as an accelerator paired with Intel's Xeon.
There are non-x86 architectures in the TOP500, including ones which have less cruft than x86, but the x86 chips keep on being used in some of the fastest machines on the planet. My hypothesis is that x86 cruft doesn't really matter, and you'd need to go to a cruft level that was orders-of-magnitude worse for the ISA choice to dominate performance.
It really doesn't matter. The biggest benefit of ARM are the fixed length instructions and only Apple is actually taking advantage of this by decoding 8 instructions at once. The big question is whether decoding that many instructions is actually a benefit. It's entirely possible that branch prediction and other factors are greater bottlenecks that have to be tackled first to take advantage of the faster instruction decoding.
Intel's Pentium processors (the original ones) were doing pretty badly because they made the pipeline too deep at the expense of other things.
I think the original Pentium had the pretty much canonical 5 stage pipeline. It did pretty well. Its successor, the Pentium Pro, an OoO design, was deeper but also did amazingly well.
You are probably thinking of the Pentium 4 which was designed as a speed demon with a very deep pipeline and failed to reach its target frequency.
Anandtech's article indicates they have an out-of-order buffer of around 630 entries (Zen 3 is only 256 entries). The M1 has 7 integer math ports and 4 FP/SIMD math ports plus several bunch of load/store/branch ports . It seems like they could completely saturate those decoders given the right code.
Fair points, but I think we can be 100% certain that Apple has modelled this and made their architectural decisions based on this modelling - especially as they are no the 10th or so iteration of their designs.
That and that their CPUs are designed to run one OS and apps are developed against one set of libraries. This frees them to tune the hardware to the needs of the software much more than any other manufacturer can do (a PC needs to run Word and Autocad equally well)
They have certainly optimised against some key aspects of their software (eg Rosetta and reference counting) but that is not at the expense of other software. The M1 Arm CPUs are just very fast general purpose CPUs.
It's probably that x86 has a better cost/performance than others. If you can get the job that'd require, say, 200 POWERs or 250 SPARC64s with 300 Xeons that cost half per socket than a POWER, x86 will still be a better choice. This could be for many reasons - from intrinsic performance of the CPU to the quality of the code generated by the compiler and/or architectural fitness to the task at hand.
Also, take into account the CPUs are not always the more expensive part of the compute node - GPUs, HBM, lots of DDR4, and fast networking gear are also pretty expensive and will be more or less constant as you change CPU architectures.
And while counting architectural registers is something, in reality modern out-of-order processors do something called "register renaming" so that more registers can be used on-the-fly as it dynamically creates a data flow dependency graph. Yes, inside each processor.
There have been attempts to move the register renaming out of the processor and into the program through VLIW architectures such as the Itanium, but it failed because (1) they require “sufficiently smart compilers” that weren’t available in the day, and (2) putting it in the silicon allows new architecture revisions to benefit older programs (putting it in code means it can’t benefit from newer register renaming algorithms without a recompile).
Also, if it’s in the silicon and there’s a bug in the algorithm, a microcode update can fix it for everyone. If the bug was in the compiler, you’d need to recompile everything to fix it.
The only successful VLIW architectures run JIT compilers on an existing ISA. Transmeta did this for x86 but Intel brought them to court them which gave Intel time to release superior chips (through superior manufacturing). The other example is Nvidia's Project Denver.
A very debatable level of "successful" on that. It shipped in a product, yes, but it wasn't very good either. It ran ARM code, but not very well, and was a horrible nightmare to work on. The JIT'd aspect completely breaks profilers. ie, what do you mean this simple field access took 20ms?? Oh, because the CPU wasn't running my code, it just silently went out to lunch to JIT some random shit, cool, thanks. There's then also the questionable security design of a globally read/write/executable chunk of memory where security is "enforced" by the JIT which is a complex bit of microcode, totally nothing can go wrong there...
It's only noteworthy "feature" was that it was able to ship ARMv8 support before ARM had a proper ARMv8 CPU design. Time to market for a new ISA was fast, but that's about it.
Project Denver lives on in NVIDIA's Carmel cores shipping in Tegra 194 (Xavier) chips today. Though they seem to be giving up on it, as they'll be using Cortex "Hercules" A78 cores in the successor named Orin.
Essentially every device that does not use a x86 cpu did that. There's no point in waiting an entire development cycle to get a new smaller x86-alike when you could solder an ARM chip or similar to the board today.
The vast majority of CPUs shipped are not x86 compatible.
Statista claims 23.5 billion microcontrollers are shipped annually.
I know microchip (the PIC people) made press releases roughly annually as they shipped another billion flash microcontrollers. Google found the one from 2011 when they shipped their tenth billion PIC chip.
I find it difficult to get x86 sales figures. Intel gross revenue is high because they have their fingers in everything. AMD financial statements claim about $2B/quarter total revenue, so if you figure the average shipped price of a AMD cpu is $200 and they made all their revenue off CPUs, that would be 40 million CPUs shipped per year, which seems both ridiculously high AND about a 25th the quantity of microchip PICs shipped.
One way to look at the number of ARM CPUs shipped is the licensing / holding company has made enough licensing fees to pay for about "a hundred and fifty billion" ARM chips in its lifetime.
You mean remove backwards compatibility and ruin the whole reason people use x86? Not to mention that when AMD64 (“long mode”) was introduced, a big amount of cruft was disabled in the new mode (but is still available in 16-bit (“real mode”) and 32-bit (“protected mode”) for compatibility).
There is also "32 bit realmode", which is not mentioned in the official documentation but simply a combination of existing states. Ditto for real mode paging and the like --- which finds more applications as emulator acid-tests than anything else.
I thought the 80286 had 32-bit protected mode, but it was badly implemented (the only way to get back to real mode was a reboot), so they fixed it with the 80386. Unless, are you referring to “unreal mode”?
No, most people forget about it (I had to be reminded by the above comment), but the 80286 did have a 16-bit protected mode. Quoting Wikipedia (https://en.wikipedia.org/wiki/Protected_mode): "[...] Acceptance was additionally hampered by the fact that the 286 only allowed memory access in 16 bit segments via each of four segment registers, meaning only 4*2^16 bytes, equivalent to 256 kilobytes, could be accessed at a time. [...]"
I am still upset after all this time, at what AMD recklessly did --- out of what might be the same misguided notion as the GP comment, they made instructions like LAHF invalid and removed much of segmentation, only to be forced to put much of it back later because people were actually using them. I suspect Intel was actually working on a more consistent extension to 64 bits too, but AMD beat them to it.
If you don’t need backwards compatibility (such as on servers), there’s not much reason to go x86. For that reason, ARM servers exist. IIRC, AWS and Azure have some.
What obsolete stuff could you remove? If you want to actually meaningfully cut out a large amount of space on the processor, you'll have to cut into the actual instruction space and remove instructions that take up space in your execution units.
Removing the 16-bit and 32-bit modes don't actually remove any instructions from the platform (save the binary-coded decimal instructions)--you're largely saving only a few bits of decoder table entries at best. Furthermore, processors reset into 16-bit mode on startup for compatibility reasons, so killing 16-bit and 32-bit mode would introduce major compatibility headaches.
ISA extensions can be more easily removed since there's already a CPUID bit that tells operating systems and applications whether or not they are used. The MPX extension for bounds checking is now regarded as a mistake, and Intel has already confirmed that they are removing it from future processor generations. The TSX extension for transactional memory is apparently on the hit list because of Spectre, and was removed from some processor generations.
The only significant processor execution unit space that is truly obsolete I can think is the x87 floating-point execution unit logic, with the concomitant MMX execution unit logic--SSE is just strictly better for everything here, except if you're trying to actually get the 80-bit precision. But the existence of 80-bit floating point in the 64-bit ABI (i.e., long double) means you'd have a hard ABI break that would potentially break software even written today, and the pain of breaking that ABI is probably not worth whatever savings you get out of it.
> Furthermore, processors reset into 16-bit mode on startup for compatibility reasons, so killing 16-bit and 32-bit mode would introduce major compatibility headaches.
Didn't the switch to UEFI effectively reduce the scope of this problem to only apply to motherboard firmware? Operating systems no longer need 16-bit code to boot.
There are a lot of x86 software out there. Even games switched to x64 binary relatively recently. That alone means that you would want to emulate with performance of, let's say i5-2500, if you want a decent framerate, which would be quite chellanging given that modern CPUs are 80% faster at best.
Once you remove a single opcode, it's not really x86 any more, and you need emulation at OS level. But then, once you've done that, why not remove more instructions? Why not remove all of them and start again on a much more power-efficient platform? Why not remove the memory model?
One of the brilliant ideas in the A1 is a flag for whether the current process insists on the slower but more comprehensible x86 memory ordering.
Several CPU features require other ones--for example, AVX requires the XSAVE feature. Additionally, x86-64 implicitly requires several features (most notably SSE2), and the glibc folks have been working on a proposed ABI for x86-64 that groups the feature sets into levels--roughly base (≤SSE2), ≤SSE4.2, ≤AVX2, current skylake-server (a clutch of AVX-512 features), with the BMI and FMA features scattered in there somewhere.
That said, the MMX instructions in particular are so problematic to use (and SSE ubiquitous and strictly better) that I suspect you could introduce a processor that lacks MMX support and break almost nobody, certainly far fewer people than removing x87. I don't know if there is an implicit or explicit actual dependency on MMX anywhere.
We can't really demand compilers to create code that's compatible with all the ancient variations of a currently popular architecture. It's still good manners to include a function that exits with a clear error message about a required architecture feature that's missing.
I had similar issues with PPC software that just blindly assumed I had Altivec on my G3. It wasn't fun.
It doesn't matter. The only meaningful change would be to go with fixed length instructions and maybe get rid of the memory ordering guarantees. If you do that you might as well switch to any other ISA that has these properties. But since Intel has an inferior manufacturing process the new ISA would still suffer from inferior CPUs. However, AMD has shown that x86_64 is still viable so the benefits of switching are miniscule anyway.
