• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Question Zen 6 Speculation Thread

Page 398 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.
Win2012R2 said:
3% extra isn't worth the risks associated with dropping even 16 bit stuff, never mind 32 bit that is still very actively used - MAYBE 30% would have been justifiable, but there is no way dropping that stuff will get more than very little - internally it must be all mapping to existing hardware stuff anyway, and simple remap can't be very expensive.

The main thing you'd gain is a bunch of short opcodes that can be repurposed for new stuff, but is decoding really the biggest problem right now?

Anyway, it (dropping 32 bit stuff) is all academic - this ain't going to happen in x86 like EVER.
Click to expand...
I would take that 3% in a heartbeat. Any 16 or 32 bit software I have I'd jettison or if really necessary now and then run in compatibility mode. It's been hanging on long enough.

I understand it's really only the front end, and decode in particular that would be affected but there is a lot of inefficiencies going on with many of those 32 bit and especially 16 bit instructions going on that the decode has to deal with and then the backend has to execute.

If you're still stuck with 16/32 bit baggage there is always emulation. But again, this is just my preference.

Of course this assumes any 16/32 bit legacy instructions built into the OS would be immediately jettisoned, like booting would have to immediately be fully 64 bit.

So if that was the path then yes, I'd take the 3% to move on and make life eventually easier for hardware and software developers.
 
Last edited:
Hulk said:
I understand it's really only the front end, and decode in particular that would be affected but there is a lot of inefficiencies going on with many of those 32 bit and especially 16 bit instructions going on that the decode has to deal with and then the backend has to execute.
Click to expand...
No, because the 64-bit instructions use the same encodings. All the inefficiencies remain even after old instructions are dropped. The only win for dropping backwards compatibility on x86 is in validation. There are no performance gains to be had for dropping a few legacy decoder paths.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top