Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Envisioning a Simplified Intel Architecture

intel.com

Post reply on HN
Print view View original

51–60 of 86 posts

Re: Envisioning a Simplified Intel Architecture

#51

Post by userbinator »

FullyFunctional wrote: post #46
userbinator wrote: post #35

Earlier quoted context omitted.

...and taken up mostly by cache and vector execution units. An 8086 has 29000 transistors. A modern CPU has several billion. The amount needed to implement the 16-bit subset of the ISA is an absolutely tiny fraction of the total area.

Ah, I see you don't work in the field. A few of the cost of legacy: * exponential growth in verification space (each feature combines with all other features), * design complexity (effort that could be spent better), * area/power/cycle time overhead (all options require more ports to muxes, more wires to run, etc.) * and most importantly, opportunity costs: some optimization tricks can't be pursued because the assump…

Ah, I see you don't work in the field.

I won't give away too much of my personal history, but it suffices to say I've worked with x86 at the hardware level before.

each feature combines with all other features

They do, but orthogonally.

effort that could be spent better

Effort that has already been spent.

all options require more ports to muxes, more wires to run, etc

It's all ultimately split into uops anyway.

some optimization tricks can't be pursued because the assumptions would break for legacy code

What assumptions in particular?

Re: Envisioning a Simplified Intel Architecture

#52

Post by userbinator »

snvzz wrote: post #45
userbinator wrote: post #32

Do not want. Did they not learn from the https://en.wikipedia.org/wiki/Intel_80376 or the infamous Itanic? The almost 50 years of backwards compatibility (along with the accompanying creation of a huge amount of documentation) is one of the strongest reasons for choosing the x86/PC. With each feature removal, they weaken that argument and push their (prospective) customers towards reconsidering all the other competit…

>Maybe it's time for a CISC-V...? I believe the only path forward for x86 is to be a "x86 accelerator", a x86 mode in some future AMD/Intel RISC-V processors, perhaps limited to unprivileged "usermode". Easing the transition until x86 can be relegated to emulation.

Easing the transition until x86 can be relegated to emulation.

The devil reveals itself. Competitors have infected Intel and are trying to destroy it from within.

x86 without the legacy is just another ISA, and Intel is going to lose if it tries to go down that path.

Re: Envisioning a Simplified Intel Architecture

#53

Post by userbinator »

hinkley wrote: post #41
xorcist wrote: post #31

Earlier quoted context omitted.

If I had to list one hundred ways x86 could be improved, not booting in 16-bit mode wouldn't be on it. It's just an incantation. There's no fallout from it. If we're talking firmware, the gigantic mess that used to be called ACPI, still leave users suffering every day for example.

I think that depends on if the existence of 16 bit mode has effects on IPC rates of the processor. If it's 2% of instruction cost, then kill it with fire. If it's raising the development cost by 1%, kill it with fire. If it's a fixed cost and isn't hurting anything, then meh.

Unless they want to complete eliminate 16-bit operations, it won't matter.

...and eliminating 16-bit operations would be pure ideologically-driven stupidity, given how many classic RISCs with word-width-operations-only suffered greatly and the ones that survived (like ARM) evolved to add them back in.

Re: Envisioning a Simplified Intel Architecture

#54

Post by FullyFunctional »

userbinator wrote: post #51
FullyFunctional wrote: post #46

Earlier quoted context omitted.

Ah, I see you don't work in the field. A few of the cost of legacy: * exponential growth in verification space (each feature combines with all other features), * design complexity (effort that could be spent better), * area/power/cycle time overhead (all options require more ports to muxes, more wires to run, etc.) * and most importantly, opportunity costs: some optimization tricks can't be pursued because the assump…

Ah, I see you don't work in the field. I won't give away too much of my personal history, but it suffices to say I've worked with x86 at the hardware level before. each feature combines with all other features They do, but orthogonally. effort that could be spent better Effort that has already been spent. all options require more ports to muxes, more wires to run, etc It's all ultimately split into uops anyway. some…

Well, everything I said was true but I don't think we can agree on that, so I'll just end it here.

Re: Envisioning a Simplified Intel Architecture

#55

Post by userbinator »

jhallenworld wrote: post #6

This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. One DOS application I use was hurt by this: "old DOS OrCAD". It works well in Windows-XP on a 32-bit machine, but does not work at all in 64-bit Windows. (It's actually a 32-bit DPMI program and has drivers to use Windows GDI so you don't have to mes…

and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode.

You can blame AMD for that and the other dubious decisions in the design of amd64 in general.

Re: Envisioning a Simplified Intel Architecture

#56

Post by kevin_thibedeau »

r00fus wrote: post #9
formerly_proven wrote: post #5

> Since its introduction over 20 years ago, the Intel® 64 architecture became the dominant operating mode. Okay that's a bit heavy on the retcon, don't you think?

Why? Because it's really just AMD-64?

"Intel Architecture 64" is Itanium. Calling x64 "Intel 64 Architecture" is like MS trying to steal the thunder of Open Office ODF with OOXML.

Re: Envisioning a Simplified Intel Architecture

#58

Post by mepian »

userbinator wrote: post #52
snvzz wrote: post #45

Earlier quoted context omitted.

>Maybe it's time for a CISC-V...? I believe the only path forward for x86 is to be a "x86 accelerator", a x86 mode in some future AMD/Intel RISC-V processors, perhaps limited to unprivileged "usermode". Easing the transition until x86 can be relegated to emulation.

Easing the transition until x86 can be relegated to emulation. The devil reveals itself. Competitors have infected Intel and are trying to destroy it from within. x86 without the legacy is just another ISA, and Intel is going to lose if it tries to go down that path.

Intel is going to lose because it ditched Ring 1 and 2, sure.

Re: Envisioning a Simplified Intel Architecture

#60

Post by jcranmer »

userbinator wrote: post #53
hinkley wrote: post #41

Earlier quoted context omitted.

I think that depends on if the existence of 16 bit mode has effects on IPC rates of the processor. If it's 2% of instruction cost, then kill it with fire. If it's raising the development cost by 1%, kill it with fire. If it's a fixed cost and isn't hurting anything, then meh.

Unless they want to complete eliminate 16-bit operations, it won't matter. ...and eliminating 16-bit operations would be pure ideologically-driven stupidity, given how many classic RISCs with word-width-operations-only suffered greatly and the ones that survived (like ARM) evolved to add them back in.

What they're getting rid of is all of the extra fun memory management modes the x86 processor has, condensing everything down into just the paging mode with extremely gimped segment support that's all that's available in x86-64. That suggests to me that someone within Intel is thinking about basically rewriting the memory subsystem, where having to support all the fun things like real mode or virtual 8086 mode is much more painful. The 16-bit data operations are still around, with the 0x66 prefix, and even the ability to default a segment to not needing the 0x66 prefix to get 16-bit registers may still be around, though I'm not savvy enough on the retained features to say for certain.

To be honest, there are two legacy x86 features which I suspect do have a noticeable tax on the support in the execution units: the x87 FPU stuff (due to the 80-bit floating-point types, and a variety of hardware-implemented transcendental instructions that need to be supported), and the legacy addressing modes.

Post reply on HN