The only thing growing faster than the number of transistors is the number of pages in the specification. Ditching legacy is a good thing.
Envisioning a Simplified Intel Architecture
21–30 of 86 posts
Re: Envisioning a Simplified Intel Architecture
#22Earlier 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.
Good fun when my dyslexia misreads "arm64" as "amd64" or vice-versa when going to grab software these days :(
Re: Envisioning a Simplified Intel Architecture
#23Earlier 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.
Golang, too: https://go.dev/doc/install/source
Re: Envisioning a Simplified Intel Architecture
#24Earlier quoted context omitted.
Legacy systems and architectures can’t be around forever. How many people in the PC market still use 16-bit applications?
Question is, what is the cost of keeping the old cruft around?
Essentially none. It's all make-work (or, since they're intent on breaking things more than fixing them, break-work.)
Re: Envisioning a Simplified Intel Architecture
#2564Bit (OS) only and kicking out legacy cruft which doesn't just add complexity but also can in some edge cases can make security harder sound like a very sane idea, just maybe kinda late. I mean they probably could have started pushing this in some areas, like server and high-end CPUS, like 5-10years ago.
Re: Envisioning a Simplified Intel Architecture
#26Re: Envisioning a Simplified Intel Architecture
#27Earlier quoted context omitted.
Essentially none. It's all make-work (or, since they're intent on breaking things more than fixing them, break-work.)
I wouldn’t say “none”. Real estate in CPUs is extremely expensive.
My immediate sense is that the entire vector system easily dwarfs the 16bit system.. as I'm guessing most of the modern 16bit mode is entirely in microcode.
Re: Envisioning a Simplified Intel Architecture
#28For those truly too lazy to click through to the article, x86-S stands for "simplified," with the idea being to boot directly into 64-bit mode instead of booting into 16-bit and bootstrapping to 64-bit mode. 16-bit mode would be removed entirely. It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially).
It seemed pretty obvious to me from one of the graphics that they would remove 32-bit mode as well.
If you mean the graphics relatively at the beginning then no, they refer to boot phases and OS level stuff but that's not fully the same as what you need to run 32bit applications in a 64bit OS.
Re: Envisioning a Simplified Intel Architecture
#29Re: Envisioning a Simplified Intel Architecture
#30For those truly too lazy to click through to the article, x86-S stands for "simplified," with the idea being to boot directly into 64-bit mode instead of booting into 16-bit and bootstrapping to 64-bit mode. 16-bit mode would be removed entirely. It's not clear to me if 32-bit mode would be axed as well, or if it would be retained (maybe partially).
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.