http://wccftech.com/intel-developin g-new-x86-uarch-succeed-

>currytech
ENOUGH

File: Itanium Sales Forecasts.png (36KB, 1042x708px) Image search: [Google]

36KB, 1042x708px

>not backward compatible

>>58206523
Couldn't you just emulate the old shit if the new shit was so much faster?

File: cec.png (185KB, 405x532px) Image search: [Google]

185KB, 405x532px

>>58206080

>>58206080
>Pajeettech
Please seek the nearest building to jump off of immediately so we can eliminate that cancer.

>>58206523
>forever stuck using x86 binary blobs on win95

wew

>>58206080
for only two grand per chip.

>>58206655
Except emulation is slow as fuck and the new uarch won't be that much faster.

It will probably be enough to run everyday programs, but say goodbye to games and professional software.

Now, since Windows survives only because of games and niche software, it will be fun watching Microsoft and Intel fight each other for survival.

>>58207571
More like they will strike a deal and it will be users who will be fighting to survive.

>>58206223
Its currytech copying bitsandchips. The author is well known on SemiAccurate. Hes got some friends deep in with some OEMs and some foundry Chinks.

Hes been wrong plenty of times before though. Intel will need a radically new arch sometime soon, and X86 can't last forever. I just don't see this happening in the time frame he states.

>>58206655
In theory yes. How this works in practice is another question. You could make an arch that emulates 100% of X86 code with 1:1 accuracy so nothing would ever break. This same hypothetical arch could have much higher throughput than any existing X86 core today.
The caveat is that this arch would need to be astoundingly faster in order to pull off this emulation without major performance impacts.

It would require a substantial push to try and get software vendors to update their products to support the new arch. Emulation is for the transitional period in adoption, and for niche legacy things. Its bound to happen sometime.
We already have ARM emulating 32bit Windows programs with Qualcomm's latest chips, though it is pretty slow.

>>58207571
>Except emulation is slow as fuck and the new uarch won't be that much faster.

who the fuck cares if it's some rare as fuck instruction that 99% of applications don't use

>>58207773

>You could make an arch that emulates 100% of X86 code with 1:1 accuracy so nothing would ever break.
Transmeta did something like that. Made their own VLIW instruction set that had a built in dynamic binary translator that would interpret all x86 instructions. Supposedly had good performance at the time... and then they went away, never to be heard from again.

>>58207768
Hardly. It's users that control the demand and many of them hate Microsoft with passion after the all the fuckups. That should force Microsoft's hand since they can't ignore their surest market.

>>58207773
It's the transitional period that's hard to get right. Considering the state of x86 market, where 5 years old CPUs are still competitive, performance gains are minimal, and the push to upgrade is mostly marketing, it might prove harder than Intel expects.

>>58207938
Users suck dick. They hated win10 and yet Kaby Lake+ will not have drivers for any other Windows version. And everyone seems to be ok with that.

File: toot.jpg (305KB, 581x542px) Image search: [Google]

305KB, 581x542px

>>58206080
>See the thing is, any Streaming SIMD Extension (SSE) can be emulated by a higher order SSE. And since Intel is working on removing legacy SIMDs, these can be easily emulated if they are ever called by the OS when needed. The upside is, however, that you will be freeing up space on the die for smaller and more efficient cores and consequently a much more streamlined x86 architecture.

What a load of crap. Isn't the x86 ISA just a scripting language with this interpreted by the silicon itself, broken down into RISC like micro ops? Registers like mm0 don't even exist on the silicon, right? The actual chip has nothing to do with the isa front end, right? So why break backwards compatibility?

File: amd3.jpg (66KB, 568x612px) Image search: [Google]

66KB, 568x612px

>>58206080
DELET

>>58206080
I recall them trying this several times before.

And they all failed.

Anyone remember Itanium?

>>58208063
>So why break backwards compatibility?
You just answered your own question.

>>58208111
No, I didn't. Are you implying that intel plans to return to CISC? No more micro ops?

>wccf
>"Reportedly"

Hapless rumour. Move on.

>>58208091
Itanium isn't x86 compatible and silicon didn't hit a wall back then.

>>58206080
>leaner
I sure am looking forward to the $500 dual cores

>>58208188
It's actually better to have a high performance dual core than a low performance octa core

>>58209327
depends on the workload tho brah

File: 3.jpg (70KB, 344x400px) Image search: [Google]

70KB, 344x400px

>>58206080
>x86

why even bother if you can only install a 32-bit operating system. AMD will keep leaching on intel because otherwise it would be a monopoly and you all know what then happens with the goy.

>>58206080
When people talk about competition being good for the industry, this is what they mean. Intel wouldn't be doing this if Zen didn't exist.

>2019-2020
It'll never come out and will be forgotten.

>>58209609
>Implying zen is the trigger
Delusional amdfag.

>AMD makes a decent CPU
>Intel starts working ob something brand new instead of shrinking and rebranding the same shit with 1-5% improvements
We told you faggots, competition is good.

>>58206080
>The reason for doing so is simple, by no longer guaranteeing backward compatibility, Intel could save precious die space by removing the hardware for legacy SIMDs and other legacy features.

Are these curries retarded? x86 is the cpu frontend and get's decoded into microops

Backwards compatibility for 30 years is literally one of x86s biggest selling points

>>58209849
>implying it is not

>>58206523
>>not backward compatible
so this is how they get the 2500k owners to upgrade

>>58209902

It's the only selling point. x86 is long overdue to die and be replaced by a proper RISC architecture. I'm hoping that OPENPower initiative takes a solid footing

>>58206080
>amd can't compete
>you pay more for intel now because no competition

you're happy why?