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

71–80 of 86 posts

Re: Envisioning a Simplified Intel Architecture

#71

Post by hinkley »

userbinator wrote: post #69
jcranmer wrote: post #60

Earlier quoted context omitted.

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 muc…

where having to support all the fun things like real mode or virtual 8086 mode is much more painful If they're going to still support virtualisation to run legacy code, which is what the article is implying, they'll still need the logic to deal with all the existing modes being used inside a VM. ...and those modes are honestly not hard to support. (Protected mode) segmentation is far simpler than paging, and realmode…

Clock cycles are dictated by the gate timing of the slowest fractional instruction. If they’re getting rid of conditional logic, that could just reduce heat a bit, or if this is now the tall tent pole, it could allow them to clock the chip a little higher at the same gate pitch.

Or, they are adding something new that puts them over that budget, and cleaning up the conditional branching lets them stay under it.

Re: Envisioning a Simplified Intel Architecture

#72

Post by snvzz »

userbinator wrote: post #61
mepian wrote: post #58

Earlier quoted context omitted.

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

...and everything else that made the PC great.

When was the PC ever great?

I must be missing something, as while popular, it is and has always been a mess.

Re: Envisioning a Simplified Intel Architecture

#73

Post by userbinator »

StillBored wrote: post #65
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. Uh, isn't that the point? X86 has been "emulated" since the P6/nexgen 586. That is why people talk about the architecture not mattering much anymore in the face of very similar OoO microarchitectures running arm/ppc/x86/etc code. Or I guess you could look at it another way, CISC won because it turns out that implementing specific high level functions like…

Fun fact: VIA's "alternate instruction set" that gives access to the uops shows that it's basically a slightly modified MIPS, with more useful x86-ish addressing modes and instructions.

Maybe we'll see RISC-V backends with x86 frontends in the future.

Re: Envisioning a Simplified Intel Architecture

#74

Post by jcranmer »

userbinator wrote: post #69
jcranmer wrote: post #60

Earlier quoted context omitted.

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 muc…

where having to support all the fun things like real mode or virtual 8086 mode is much more painful If they're going to still support virtualisation to run legacy code, which is what the article is implying, they'll still need the logic to deal with all the existing modes being used inside a VM. ...and those modes are honestly not hard to support. (Protected mode) segmentation is far simpler than paging, and realmode…

From what I can tell, they're not supporting them in virtualization. Instead, they're set up to cause processor traps, which the hypervisor could catch and use to emulate those instructions if necessary.

> ...and those modes are honestly not hard to support.

I have to imagine that there's a decent amount of extra logic in the load/store units to use the current processor mode to work out memory semantics, and now I'm thinking about questions like "what would happen if one thread is in virtual 8086 mode while the hyperthread partner isn't". That's a noticeable burden in things like validation.

And even if the implementation of segmentation is simpler than paging, that's not the issue; the issue is that it's a different pathway, and potentially one that cuts deep into the execution unit. If it's the sort of thing where eliminating support for anything other than paging means getting an L1 cache hit back one cycle faster... then sign me up.

Re: Envisioning a Simplified Intel Architecture

#75

Post by MrBuddyCasino »

FullyFunctional wrote: post #54
userbinator wrote: post #51

Earlier quoted context omitted.

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.

Sad.

Re: Envisioning a Simplified Intel Architecture

#76

Post by AshamedCaptain »

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…

> vm86 mode doesn't work in 64-bit mode.

vm86 doesn't work in 64-bit mode, but you can simply temporarily switch down to 32-bit mode, and them vm86 works just fine. Early amd64 Linux would do this, and there was even a kernel module to do it after they dropped support for it.

Microsoft had other reasons to drop 16-bit support in Windows 64.

Re: Envisioning a Simplified Intel Architecture

#77

Post by sillywalk »

kinghajj wrote: post #14
mananaysiempre wrote: post #12

Earlier quoted context omitted.

I guess we should be thankful they aren’t still calling it EM64T :) I’ve also heard that the term AMD64 also originated from marketing—the internal name during development was x86-64 (which everybody but Microsoft ended up calling it anyway).

`amd64` is still what Debian and Kubernetes use.

and OpenBSD

Re: Envisioning a Simplified Intel Architecture

#79

Post by userbinator »

AshamedCaptain wrote: post #76
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…

> vm86 mode doesn't work in 64-bit mode. vm86 doesn't work in 64-bit mode, but you can simply temporarily switch down to 32-bit mode, and them vm86 works just fine. Early amd64 Linux would do this, and there was even a kernel module to do it after they dropped support for it. Microsoft had other reasons to drop 16-bit support in Windows 64.

Microsoft had other reasons to drop 16-bit support in Windows 64

Namely, planned obsolescence. They realised that forcing people to consume could squeeze a little more $$$ from them.

Re: Envisioning a Simplified Intel Architecture

#80

Post by anticensor »

dathinab wrote: post #30
KerrAvon wrote: post #3

Earlier quoted context omitted.

The PDF goes into detail on this. tl;dr: > 16-bit and 32-bit protected mode are not supported anymore and cannot be entered. The CPU always operates in long mode. The 32-bit submode of Intel64 (compatibility mode) still exists.

Yes but there is a bit of a catcher due to some 32bit programs abusing certain instructions created for handling segmentation. And segmentation support will be partially removed. But no idea if the instruction in question will be gone.

Removed instructions and pseudocode of changing instructions are explicitly documented.
Post reply on HN