X87
Images are sometimes not shown due to bandwidth/network limitations. Refreshing the page usually helps.
You are currently reading a thread in /g/ - Technology
You are currently reading a thread in /g/ - Technology
If x86 has really stagnated why doesn't Intel develop a new architecture?
They could even include a single core x86 on die for backwards compatibility, that they can eventually phase out.
>>54198435
is this bait? :^)
>>54198435
>x87
Is a (deprecated) thing.
>If x86 has really stagnated why doesn't Intel develop a new architecture?
MUH BACKWARDS COMPATIBILITY
They had the chance to fix things with 64-bit, removing old shit and stuff, but they didn't.
can you really fuck a pineapple?
>>54198491
Follow your dreams, anon.
>>54198467
Well that's why I was thinking they could include an x86 core for the first few gens on the new processors for backwards compatibility.
VIA was working on a hybrid x86/ARM processor iirc, why couldn't Intel do something similar?
>>54198435
>x87
>>54198544
Too complex and consumes power from hell
Apple made rosetta, a translator for translating PowerPC instructions to x86. But Intel will never do anything like this.
>>54198649
So desktops will be merged into laptops because Intel doesn't want to develop a new arch?
>>54198676
Intel is moving away from desktops, haven't you heard? They're sacking 12,000 employees (11% of their staff) that work on desktop computer related stuff.
The future generations of laptops will be ARM64. Much more power-efficient.
>>54198435
>why doesn't Intel develop a new architecture?
They've tried to kill off x86 with something newer and better before. First iAPX432 in the 80s and then IA-64 (Itanium) in the 90s. Didn't work. One, yeah, backward compatibility is a thing. Even the people who can recompile all their shit for a new architecture don't really want to. Two, compilers targeting x86 have gotten really, really, disturbingly good. Both of the above attempts foundered on difficulties getting compilers to produce good code. Especially with Itanic, the kind of compiler needed to get the most out of the chip turned out to be basically impossible to write. (One of the chip's features was that it gave control over instruction ordering to the compiler (or poor bastard writing assembly) so as to save die space on the fiendishly complex branch-prediction and reordering hardware. Compilers couldn't predict runtime codepaths well enough to use it.)
>>54198491
I don't see why not
>>54198467
>>They had the chance to fix things with 64-bit, removing old shit and stuff, but they didn't.
The "old shit" (real-mode and virtual-86 support and such) doesn't actually take up much die space at all. Especially since that stuff just has to work correctly and needn't be fast. I remember reading that backward-compatibility was about 3% of die area, I'll see if I can find the source on that
>>54198745
>The "old shit" (real-mode and virtual-86 support and such)
I'm talking about legacy shit such as x87 support. Who have developed anything using x87 the last 30 years?
Also, it's not only about real estate, but also complexity and instruction set.
>>54198435
What the fuck is x87?
Is that Intel's version of x86_64?
>>54198435
because it's so fast already that there's no need to, and in applications where it isn't enough there's already the well established POWER and SPARC architectures
>>54198467
Intel tried this already with the Itanium and it failed miserably, you could argue that it was the quirks of the VLIW architecture that did it in, but even if they started over with a more conventional RISC/CISC design the maybe 10% you'd gain in theoretical peak performance in certain applications would be worthless when you have to lobotomize your established software base to do it
tl;dr progress for the sake of progress is fucking dumb and you should stop being so bitter about the reality that ripping functionality out of a system for the sake of being hip is a stupid idea
>>54198813
>What the fuck is x87?
Floating point coprocessor from the stone ages.
It has been deprecated since forever.
>>54198854
>Intel tried this already with the Itanium and it failed miserably
Not really, because Itanium wasn't an x86 replacement, it was always intended to be for high-end servers.
>maybe 10% you'd gain in theoretical peak performance in certain applications would be worthless when you have to lobotomize your established software base to do it
I'm already arguing that they need to do some kind of translation like Apple did with Rosetta.
>tl;dr progress for the sake of progress is fucking dumb and you should stop being so bitter about the reality that ripping functionality out of a system for the sake of being hip is a stupid idea
It's not for the sake of being hip, it's for the sake of saving power. Performance per watt is everything.
>>54198759
>but also complexity and instruction set.
the thing is 99% of programmers never get that far down in the weeds. Compiler developers do, and there's a few niches where assembly still gets written, but by and large a complex instruction set is a headache for the people designing the chip and the people writing the compiler, and almost nobody else.
Power and die space overhead from the x86 instruction set gets significant when you're talking about a chip that's going in a phone. But much above that, it gets lost in the noise - it's miniscule even for a ten-watt laptop chip.
>>54198813
Floating-point instruction set. Along with the 8086 and later 8088, there was the 8087 FP coprocessor. Since not many people needed FP back then, it was an optional extra. First chip to have that integrated was the 486 (some models, the SX didn't have it), and it wasn't till the Pentium era that it was a thing all chips came with.
x87 was even more of an abomination of an ISA. the registers were stack-based, you couldn't just go to a particular register number and operate on it, you had to exchange it with the thing on top of the stack. Most FP instructions operated on the item at the top of the stack, or the top two items.
It hasn't actually been implemented that way in decades, though, modern x86 breaks everything down to micro-ops and decides for itself how to execute them. It's like an old and clunky API that everyone uses, but with a modern implementation under it that you can't see.
>>54198881
>Power and die space overhead from the x86 instruction set gets significant when you're talking about a chip that's going in a phone. But much above that, it gets lost in the noise - it's miniscule even for a ten-watt laptop chip.
Well, it's very significant for servers too.
>>54198878
>>Not really, because Itanium wasn't an x86 replacement, it was always intended to be for high-end servers.
It was always meant to go into high end servers first, but it was also always meant to move down into the mainstream market later on.
>During development, Intel, HP, and industry analysts predicted that IA-64 would dominate in servers, workstations, and high-end desktops, and eventually supplant RISC and Complex Instruction Set Computing (CISC) architectures for all general-purpose applications.[4][5]
https://en.wikipedia.org/wiki/Itanium
>it's not for the sake of being hip, it's for the sake of saving power. Performance per watt is everything.
Ripping everything up at the foundations and building something completely new is very disruptive and expensive. If the switching costs exceed the power you save by doing that, you don't do it. Hence why ARM has done fine in phones where there was no x86 installed base and still hasn't made much of a dent at all in desktops and servers where there is.
>>54198898
>Well, it's very significant for servers too.
Sure, they love PPW because they pay twice for electricity, once to use it and once for the air-con to take out the heat. What they love even more is avoiding complexity though, and putting a different architecture in your datacenter causes you headaches. Not all your servers are the same anymore, you can't migrate VMs from one to the other, they need different versions of the software they run, and there'll be some things where there isn't a non-x86 version. Only when dealing with that, and all the expensive staff time that it entails, starts costing less than the power it'll save will they start doing it.
>>54198953
It may be expensive, but it is inevitable and it should have been done a long time ago.
ARM already did it for their 64-bit version.
>>54198997
>>It may be expensive, but it is inevitable and it should have been done a long time ago.
Yeah and in 1992 Tannenbaum was telling Linus that writing an OS for i386 was silly because that architecture was obviously a dead end that was sure to be replaced in about five years or so.
Nothing's ever inevitable.
>>54199015
>Yeah and in 1992 Tannenbaum was telling Linus that writing an OS for i386 was silly because that architecture was obviously a dead end that was sure to be replaced in about five years or so.
That's not exactly what he told him, though. He argued that Torvalds would be better off designing a portable kernel rather than one specific for the i386, while Torvalds argued that since he designed it specifically for i386 he could use features in 386 that previous kernels didn't.
>>54199034
Yes, and why did he think it should be portable? Because he thought that x86 was going away. Which didn't happen.
>Tanenbaum argued that since the x86 architecture would be outdone by other architecture designs in the future, he did not need to address the issue, noting "Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5."
https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate
>>54198759
>I'm talking about legacy shit such as x87 support. Who have developed anything using x87 the last 30 years?
Skyrim used it, which was partly why AMD CPUs performed poorly in Goyimtech's 800x600 benchmarks :^)
Intel still has dedicated x87 hardware while AMD only emulates it nowadays.
>>54199068
Tanenbaum was right though, x86 is outdone by other architecture designs.
This is why Intel is moving away from desktops.
>>54199243
See >>54198881
It's not actually being used on the hardware level.
>>54199249
No, Intel's moving away from desktops because consumers don't want to buy them. It's a shrinking market. Architectural concerns don't even play into it - they want to focus their resources on markets where there are the most potential buyers for their chips, and desktop sales, though not going away anytime soon, are on a long slow decline.
>>54198717
how do you even learn shit like that
>>54199281
No, it's because in the future desktops will be using ARM.
Intel is losing money on Apple because of their discounts. Sooner or later, Apple will decide switching over to ARM.
>>54199259
Your point?
Intel still has dedicated hardware for x87 instructions, while AMD emulates them in software.
>>54199304
>Intel still has dedicated hardware for x87 instructions
It's not being used.
>>54199299
I can see arm making it's way into laptops, but not desktops. I fail to see how a 3w arm chip can compete with an i7.
>>54199299
>>No, it's because in the future desktops will be using ARM.
Well the only reason someone buys a desktop is because they want more computing power and are willing to sacrifice portability in order to get it. In exchange for being larger and tethered to a wall outlet, the desktop has a much larger thermal envelope than any portable device.
Using a higher thermal envelope to obtain higher performance is to the advantage of x86 over ARM, and long has been. PPW, if its even relevant, might be equal or better than ARM, especially in this case, since although the Intel chip uses a lot more power per unit time, it also gets a lot more done in that amount of time.
>>54199304
>>54199319
The instruction decoder obviously understand x87 instructions in both cases, but neither company's processors guarantee anything about the under-the-hood implementation. They don't still implement a register stack, they implement what they want and then the instruction decoder handles the "API".
>>54198491
You can fuck anything you can stick your dick into.
>>54199652
Anything?
>>54199731
Yes
>>54198544
>VIA
They're still around?
So... When are we getting x88?
>>54201357
1979
>>54198628
I bought that when it came out
>>54198878
>Not really, because Itanium wasn't an x86 replacement, it was always intended to be for high-end servers.
The revisionism is strong, famalam.
Intel in the late 90s was saying Itanium (known as Merced) would be the next desktop processor.
>>54199359
ARM was designed as a desktop processor. It's just coming home.
>>54198881
>but by and large a complex instruction set is a headache for the people designing the chip and the people writing the compiler, and almost nobody else.
x86 instructions are hard to decode and get worse with each new extension, but it's not just instructions, it's segments, memory models, concurrency, virtualization, paging, I/O, interrupts, protection, and all of that stuff. There are cleaner ways to do all of that which would make operating systems simpler, smaller, and more secure.
>>54203940
In the not too distant future, I can see a lot of people using ARM workstations that have most of their processing grunt done in the cloud. Perhaps even as a totally dumb thin client that links to your mobile/tablet.
