[HN Gopher] Envisioning a Simplified Intel Architecture
___________________________________________________________________
Envisioning a Simplified Intel Architecture
Author : ruik
Score : 58 points
Date : 2023-05-19 20:24 UTC (2 hours ago)
(HTM) web link (www.intel.com)
(TXT) w3m dump (www.intel.com)
| dathinab wrote:
| 64Bit (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.
| ngneer wrote:
| The only thing growing faster than the number of transistors is
| the number of pages in the specification. Ditching legacy is a
| good thing.
| userbinator wrote:
| You mean the number of pages in the specification for the
| _newly added_ features.
| tedunangst wrote:
| This would be an interesting claim to back up with real
| numbers.
| formerly_proven wrote:
| > Since its introduction over 20 years ago, the Intel(r) 64
| architecture became the dominant operating mode.
|
| Okay that's a bit heavy on the retcon, don't you think?
| r00fus wrote:
| Why? Because it's really just AMD-64?
| dathinab wrote:
| probably
|
| but also it's a stretch in general as for personal computers
| arm is the dominant platform since years (there are way more
| phones, tablets, etc. then x86 laptops/desktops by now, all
| of which fit the original definition of personal computer)
| epylar wrote:
| It's saying that the 64-bit mode became dominant over other
| Intel modes.
| jhallenworld wrote:
| 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 mess
| around with drivers).
|
| More evidence: IBM 360 mainframe software still works in Z/OS.
|
| It might be worth it for non-generic computing devices like cell
| phones, but Intel missed the boat there already.
| TazeTSchnitzel wrote:
| 16-bit x86 code is ancient enough that a software emulation
| solution can be fast, efficient, and perfectly compatible, so
| there's no need to keep support for it in hardware at this
| point.
|
| Microsoft could have used emulation to keep old 16-bit x86 apps
| working with Windows for AMD64 (in fact they had done this
| before for non-x86 architectures) but I guess they weren't
| interested. WINE and DOSBox did it though.
| dathinab wrote:
| 16 bit code is most times braking due to Windows being itself
| incompatible so you need to emulate it anyway.
|
| And if you have very old but important windows legacy software
| you either want to also run old hardware and windows OS anyway
| or run enumeration anyway.
|
| On linux this is somewhat already the case, most distroes are
| by now for OS 64bit only with at most 32bit application support
| but not always enabled by default.
| manuelabeledo wrote:
| Legacy systems and architectures can't be around forever.
|
| How many people in the PC market still use 16-bit applications?
| MrBuddyCasino wrote:
| Question is, what is the cost of keeping the old cruft
| around?
| userbinator wrote:
| Essentially none. It's all make-work (or, since they're
| intent on breaking things more than fixing them, break-
| work.)
| manuelabeledo wrote:
| I wouldn't say "none". Real estate in CPUs is extremely
| expensive.
| akira2501 wrote:
| 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.
| userbinator wrote:
| ...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.
| jhallenworld wrote:
| >Legacy systems and architectures can't be around forever.
|
| Why not? The bits don't decay.. Yes, this leads to an
| architectural mess, but I'm talking about a competitive
| business advantage.
| manuelabeledo wrote:
| > Why not?
|
| > Yes, this leads to an architectural mess
|
| Right there.
|
| There's no notable advantage in supporting a very small
| minority of the applications out there, at the cost of
| keeping units useless for the 99%.
| PrimeMcFly wrote:
| Out of curiosity why are you still using a 16bit DOS CAD
| application?
| userbinator wrote:
| 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
| competitive CPUs out there like ARM, MIPS, RISC-V, etc. that are
| not distant in performance.
|
| Intel has made SoCs for phones, tablets, and other miscellaneous
| devices, but they weren't PC-compatible. Not surprisingly, they
| were not well-received.
|
| Related: https://news.ycombinator.com/item?id=8091290
|
| Maybe it's time for a CISC-V...?
|
| Edit: apparently respecting history is not a popular opinion.
| AdamH12113 wrote:
| > Since its introduction over 20 years ago, the Intel(r) 64
| architecture became the dominant operating mode.
|
| *cough*[1]
|
| [1] https://en.wikipedia.org/wiki/X86-64#History
| jhallenworld wrote:
| Passive voice, "mistakes were made" (Itanium), etc.
| mananaysiempre wrote:
| 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).
| kinghajj wrote:
| `amd64` is still what Debian and Kubernetes use.
| IntelMiner wrote:
| Good fun when my dyslexia misreads "arm64" as "amd64" or
| vice-versa when going to grab software these days :(
| hinkley wrote:
| I still can't have a coherent conversation about EC2 arm
| versus Epyc instances. m6a machines are arm processors,
| right? Nope.
| post-it wrote:
| It's happened to me at least twice.
| nsajko wrote:
| Golang, too: https://go.dev/doc/install/source
| loeg wrote:
| For 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).
| KerrAvon wrote:
| 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.
| dathinab wrote:
| 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.
| aforty wrote:
| It seemed pretty obvious to me from one of the graphics that
| they would remove 32-bit mode as well.
| dathinab wrote:
| 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.
| loeg wrote:
| > It seemed pretty obvious to me from one of the graphics
| that they would remove 32-bit mode as well.
|
| I don't believe it's that simple (or obvious, since you seem
| to be mistaken).
| muricula wrote:
| Looks like you will still be able to run 32 bit user mode
| applications under a 64 bit kernel. I'm not sure, but I think
| 32 bit guest kernels get the ax as well.
|
| " 3.3 Removal of 16-Bit and 32-Bit Protected Mode
|
| 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.
| ... "
| jcranmer wrote:
| > I'm not sure, but I think 32 bit guest kernels get the ax
| as well.
|
| This is somewhat beyond my knowledge of system programming,
| but my read is that it's just possible to support 32-bit
| guest kernels in the VM with some more emulation of the de-
| supported instructions. I don't know how many of those
| instructions already cause VM exits.
| jcranmer wrote:
| > It's not clear to me if 32-bit mode would be axed as well, or
| if it would be retained (maybe partially).
|
| I've been reading the detailed pdf to see more details. It
| looks to me like 32-bit mode, specifically in the sense of a
| 32-bit distribution of modern software, is being retained.
| Segments would be converted more towards their 64-bit extremely
| attenuated mode, rather than the more robust functionality they
| have right now. So most 32-bit software shouldn't be affected,
| unless you're getting really dirty with the segmentation
| features or trying to support something like Win16.
| xorcist wrote:
| 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.
| hinkley wrote:
| 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.
| AtlasBarfed wrote:
| Ok, so maybe you do that in boot order or some boot motdes. But
| ... remove it?
|
| There is SO MUCH silicon these days, honestly I think CPUs
| should start putting instruction set compatibility cores in, so
| you still dedicate .5% to a 16 bit compatibility core, 1% to
| the 32 bit mode, and maybe even an ARM mode.
|
| Honestly, since all CPUs are basically fronted by microcode,
| why can't modern CPU microcode be compatible with multiple
| instruction sets? Or provide some sort of programmable
| microcode section so emulators aren't done in software?
|
| While I'm bitching, what happened to actually running multiple
| OSes at once? I have like 16 cores, gigabytes of RAM, multiple
| display outputs ... why can't I actually run both Linux and
| Windows and OSX all at once without some bad virtualization
| container inside one overarching OS? Like, can't Intel manage
| that with chipset and CPU logic?
|
| Intel (and AMD) are DESPERATE to figure out things to get
| people to use all their extra cores and silicon for. Well, how
| about making multiple OS on the same machine an actually
| pleasant experience? Hell, I would love to run a smartphone OS
| as well.
___________________________________________________________________
(page generated 2023-05-19 23:01 UTC)