[HN Gopher] Intel Explores Transition to 64-Bit-Only X86S Archit...
___________________________________________________________________
Intel Explores Transition to 64-Bit-Only X86S Architecture
Author : MR4D
Score : 112 points
Date : 2023-05-20 16:26 UTC (6 hours ago)
(HTM) web link (www.tomshardware.com)
(TXT) w3m dump (www.tomshardware.com)
| vinyl7 wrote:
| I wonder if Intel will still have to pay licensing fees to AMD
| for x64 with this move?
| manuelabeledo wrote:
| They have a cross-licensing agreement.
| EuropeOverlords wrote:
| [flagged]
| monocasa wrote:
| Almost certainly. The underlying form of the IP cross licensed
| is in patents on implementation of x86_64 cores. Those will
| still be on the table for as long as the patent terms last.
| dusted wrote:
| _making a mental note that the 32 bit compatible era is coming to
| an end and I should start thinking about stocking up on hardware_
| londons_explore wrote:
| I see no real benefit to this. The x86 compatibility doesn't get
| in the way in any modern architecture - all the 16/32 bit mode
| stuff is all 'emulated' with microcode, and there are no
| dedicated 16 bit registers anymore...
|
| Nor does it get in the way of software - as soon as you've
| switched to 64 bit mode, you can ignore all legacy stuff.
|
| Thats the right way to maintain legacy compatibility - make sure
| it is all contained and doesn't get in anyone's way, and you can
| leave it there forever.
| rowanG077 wrote:
| Why would Intel propose it if there are is no benefit?
| chx wrote:
| 1. The neutral answer: to decrease validation costs.
|
| 2. The nefarious answer: maybe they found a way in their
| agreements with AMD which would exclude this X86S somehow.
| fwsgonzo wrote:
| Can't help but agree. I especially don't like removing ring3
| I/O port access. It was/is the fastest way to trap out of a VM
| without SYSCALL or some other mechanism that I could measure.
|
| Segmentation also has its uses, and it's a shame that they are
| steadily removing it. Having a way to set up a 1:1 memory range
| without even touching the page tables has always been faster
| than messing with pages. Indeed, it's always been more
| performance to either have a fully static page table or just
| disable it completely and run in 32-bit mode. For certain
| tasks, it's still the fastest.
|
| But these are all niche uses. These days, who thinks about
| anything other than Windows and Linux use cases?
|
| To me though, AMD64 made most problems go away, and the
| architecture is just fine. Perhaps they want to do away with
| many of the now rarely used instructions?
| wmf wrote:
| The proposal is from Intel. How sure are we that we know better
| than Intel?
| moffkalast wrote:
| We ask AMD what they think about it?
| Animats wrote:
| AMD got rid of much of the older baggage when they designed
| 64-bit mode. There's a 32-bit segmented mode with call gates and
| rings nobody uses. That was dropped for 64-bit mode, but it's
| still there in 32 bit mode in shipping processors.
|
| Intel has been burned in the past, though. The Pentium Pro
| (1995), the first good superscalar microprocessor, was a 32-bit
| machine that could also run 16-bit code. Intel thought 16-bit was
| on the way out, so the 16-bit hardware was not fast.
| Unfortunately for Intel, Microsoft Windows users were still
| running too much 16-bit code. It ran Windows NT fine; Windows 95,
| not so much. As a result, the Pentium Pro did not sell well.
| Intel had to come out with the Pentium II (1997), which was
| similar to the Pentium Pro but had better 16-bit performance.
| Narishma wrote:
| I may be remembering things wrong but I thought the reason the
| Pentium Pro didn't sell very well was its price rather than its
| performance.
| kps wrote:
| > _The Pentium Pro (1995), the first good superscalar
| microprocessor_ ...
|
| I thought the i960CA was good.
| kjs3 wrote:
| PPro ran Windows 95 fine, just not at a favorable
| price/performance point. PPro sold fine for what it was: the
| very high end, highest price of the Intel line.
| linusg789 wrote:
| Also see https://news.ycombinator.com/item?id=36006446
| BulgarianIdiot wrote:
| Absolutely. Piling on tech debt forever is like trying to eat
| endlessly and never to go the toilet, pardon the analogy. Legacy
| needs to be dealt with constantly and relentlessly. With a
| suitable overlap window for transition (but we've had enough
| x86-32 compatibility window already).
| CoastalCoder wrote:
| IMHO a similar point could be made about the C++ language spec,
| sadly.
| FpUser wrote:
| Just don't use "legacy parts" and be happy. Backwards
| compatibility is a great asset. Alternatively do something
| like Google's Carbon. Seems like a great product. Just do not
| call it C++. If it gets accepted by wider community you would
| know you are on the right path.
| [deleted]
| CoastalCoder wrote:
| > Just don't use "legacy parts" and be happy.
|
| Maybe that works for some new codebases.
|
| When you need to integrate with other code, you can't
| necessarily understand the code semantics without knowing a
| lot more of the spec.
|
| Also, I challenge any normal programmer to remember all of
| the "good" C++ rules regarding overload resolution in an
| arbitrary context.
| ilyt wrote:
| Yup, it's absolutely true, navigating to the "good parts" is
| a nightmare
| BulgarianIdiot wrote:
| Same point can be made about anything. Never breaking BC is
| easier, and more comfortable, but in the end it's slow and
| inevitable death.
|
| If C++ would have cleaned up legacy, Rust wouldn't need to
| exist for ex.
|
| Java has long had a policy of never breaking BC, but few
| years ago they started marking packages deprecated for
| removal. They're very slow and systematic about it, as they
| should be, but the point is, eventually those packages will
| be removed. And that's good. It means Java has a future.
| delta_p_delta_x wrote:
| There are similar efforts to revamp C++ or replace it with
| another language, too.
|
| Rust is a famous example; there's also Carbon[1] and
| cppfront[2].
|
| Even so, this may be a controversial opinion, but with C++20,
| it has become fairly straightforward to program relatively
| safely and avoid some old footguns.
|
| [1]: https://github.com/carbon-language/carbon-lang
|
| [2]: https://github.com/hsutter/cppfront
| FpUser wrote:
| I use "modern C++" (a subset of it that suits my goals) and
| do not really have any real problems during last 3 years.
| My backend C++ application servers are running along just
| fine.
| pm215 wrote:
| If I'm reading the pdf correctly it proposes dropping 32-bit
| ring 0 (OS) but not 32-bit ring 3 (userspace), so most end-
| users are unlikely to notice much change even if they do have
| 32-bit legacy apps kicking around. I think 32-bit VMs would no
| longer be supported, though.
| FpUser wrote:
| >"Legacy needs to be dealt with constantly and relentlessly"
|
| To make your life easier? The customers may have totally
| different opinion.
| bigdict wrote:
| Ha, literally thought about this 5 days ago.
|
| https://news.ycombinator.com/item?id=35942727
| EuropeOverlords wrote:
| linux community had this thoughts 15 years ago
|
| but these thoughts were rejected because " intel is using this,
| so we can not remove it "
|
| and intel reasoning for not removing it was : " linux is using
| it, so we can not remove it ".
| deaddodo wrote:
| What does linux have to do with anything? They can use 64-bit
| only mode any time they like, and plenty of Linux machines
| for the last 4-5 years have been pure 64. It's mostly people
| using commercial software (games, stuff like Skype) that have
| to have multiarch, but less and less of those are 32-bit as
| time passes.
|
| Additionally, of the three main x86 OSes (Windows, macOS and
| Linux); Linux' solution to dual-mode is easily the worst,
| specifically so it _is_ easy to run it in pure 64 mode.
| pyrolistical wrote:
| Isn't this still makeup on a pig? They will still have a tiny
| risc machine underneath
| mepian wrote:
| They don't have a "tiny risc machine" underneath, that's a
| myth.
|
| EDIT: https://qr.ae/pyvelA
| pengaru wrote:
| > They don't have a "tiny risc machine" underneath, that's a
| myth.
|
| https://stackoverflow.com/questions/5806589/why-does-
| intel-h...
| junon wrote:
| Fabulous. Might actually make me like Intel again. The legacy
| stuff is a nightmare, their segmented memory nonsense was also a
| waste of development time and I'm glad to see them finally
| acknowledge it.
|
| I wonder how this will affect quirks such as A20, IRQ remapping,
| etc. All oversights and mistakes made by Intel over the years -
| none of which really _hurt_ development or performance these days
| per se, but are definitely not _fun_ to work with either.
|
| Something like this is the only thing that would save the x86
| architecture before ARM inevitably took over.
| Sesse__ wrote:
| > I wonder how this will affect quirks such as A20
|
| A20 was removed in Haswell (released pretty much exactly ten
| years ago).
| remexre wrote:
| > Something like this is the only thing that would save the x86
| architecture before ARM inevitably took over.
|
| Eh, this feels like a rounding error in ISA desirability
| compared to pointer authentication, or something like CHERI.
| Sure, it'd be _nice_ to have the legacy stuff cleaned up, but
| it's not costing much human effort to deal with compared to the
| effort spent securing native code.
| pohl wrote:
| What might be their motivation for this, then?
| luma wrote:
| Save die space and thus reduce cost and power budgets.
| Potentially simplify microarch and cache management. Maybe
| reduce attack surface?
| chx wrote:
| Nah, the die space you save here is absolutely minuscule.
| Intel saves on the validation of core designs -- forever.
| JohnBooty wrote:
| It might not make too much of a difference to software
| developers targeting x86, but dumping legacy crap might
| make _Intel 's_ job easier (and/or more profitable, because
| they can reclaim some die space) when it comes to
| implementing their future silicon.
| leoc wrote:
| A cynic might wonder if it would also help to renew the
| Intel/AMD x86 patent moat now that the core x86-64
| specification is over 20 years old. If the plan is
| largely just to strip things out it might be hard to
| shoehorn in patent claims, but I'm sure a way could be
| found.
| remexre wrote:
| It'd make the chips easier to design, I guess. Maybe
| motherboards and BIOSes too?
|
| I could imagine a more user-noticeable effect in VM cold-
| start times, perhaps, though I'd think physical hardware
| boot times would still be dominated by other things (e.g.
| actually loading the kernel into memory); the minimal
| implementation of transitioning from real mode to long mode
| is a few hundred instructions.
| pwg wrote:
| > I wonder how this will affect quirks such as A20, ... All
| oversights and mistakes made by Intel over the years
|
| Well, the A20 gate was actually IBM's creation, in order to
| make the PC-AT system compatible with running real-mode DOS
| programs.
|
| Intel simply, later, incorporated it into the CPU because it
| was already part of the PC architecture (and had been for
| years) at that time.
|
| Now, one could argue Intel had no business incorporating it
| into the x86 ISA, but it wasn't ever their oversight, they were
| just reacting to the reality of the systems in which the vast
| majority of their CPU's were used.
| bitwize wrote:
| Segmented memory was not a "waste of development time" _at the
| time_. It allowed the 8086 to be compatible as far as source
| and machine-translated binaries with the 8080, while expanding
| the address space considerably. It allowed considerable
| advances while retaining some measure of backward
| compatibility.., like x86-64 did.
| Findecanor wrote:
| > their segmented memory nonsense was also a waste of
| development time and I'm glad to see them finally acknowledge
| it.
|
| People tend to remember mostly how difficult it was to program
| with segmentation in 286's 16-bit mode and earlier. But in
| 32-bit mode, user-space code didn't need to bother if the OS
| didn't use it.
|
| I've read several papers lately about schemes with compiler/OS
| co-design for securing the return pointer on the stack,
| function pointers and other sensitive variables from hacking
| attacks. This problem was already mostly solved on x86-32 where
| the stack can be in its own segment.
|
| But to get achieve this in 64-bit mode (and on ARM and RISC-V),
| researchers have resorted to various tricks such as randomising
| addresses regularly [SafeHidden], switching access to the
| (safe) stack on and off with Intel MPK, using the Intel shadow-
| stack (in CET) for storing variables [CETIS], and even running
| user code in privileged mode [Seimi], [InversOS](ARM) ...
|
| Some of these these schemes are _tricks_ using the CPU in ways
| it wasn 't intended, and therefore perhaps broken on future
| CPUs. Several are only available on newer Intel processors with
| certain extensions, and most have considerable run-time
| overhead. Therefore, you will never see any like it in a
| mainstream OS. But the x86-32's safe stack would have been, as
| "Safe Stack" schemes relying on randomisation already got
| widespread adoption.
|
| [SafeHidden]
| https://www.semanticscholar.org/paper/SafeHidden%3A-An-Effic...
|
| [CETIS]
| https://www.semanticscholar.org/paper/CETIS%3A-Retrofitting-...
|
| [Seimi]
| https://www.semanticscholar.org/paper/SEIMI%3A-Efficient-and...
|
| [InversOS]
| https://www.semanticscholar.org/paper/InversOS%3A-Efficient-...
| zh3 wrote:
| Even as a retro-grouch (with a bunch of 386 and 486 boxes, some
| still in use), this makes sense. Not mentioned, but wondering
| what sort of TPM/DRM bolt-ons will become mandatory as part of
| this?
| mepian wrote:
| There are no TPM/DRM bolt-ons in the specification.
| zh3 wrote:
| Yet.
| akira2501 wrote:
| > All oversights and mistakes made by Intel over the years
|
| Engineering is not about achieving perfection. It's about
| organizing compromises to create a product that provides good
| utility at a fair price. These were not oversights or mistakes
| they were intentional design decisions.
|
| Likewise.. you can see segmented memory as "nonsense" and a
| "waste of development time" but Intel clearly didn't fail at
| anything. They've been one of the largest and most successful
| chip manufacturers for decades, because their products provided
| real utility at affordable consumer prices and software
| developers gladly put up with the technological choices to be a
| part of that giant market.
| fbdab103 wrote:
| >They've been one of the largest and most successful chip
| manufacturers for decades, because their products provided
| real utility at affordable consumer prices...
|
| Do not forget all of the anti-competitive AMD nonsense over
| the years. Sabotaging AMD performance on benchmarking is my
| stand-out, but there were also the payouts to Dell and others
| to purchase exclusively Intel chips.
| mistrial9 wrote:
| anyone in the business side knows that Intel has succeeded
| splendidly, at insider Defense deals, proprietary components
| and market manipulation to crush rivals. Engineering is
| always on display, but does not tell the full financial story
| of Intel "greed is good" Corp.
| buran77 wrote:
| > They've been one of the largest and most successful chip
| manufacturers for decades
|
| Probably the 2 biggest reasons for this are that only 2
| companies are allowed to "touch" x86, and that the second
| company was easily undermined by nefarious business
| practices. This resulted in a lot of things that were not
| "oversights or mistakes" but rather for the longest time lax
| approaches under a distinct lack of pressure.
|
| It's hard to say how the x86 world would have looked like
| today if someone like Nvidia had a license.
| shrimp_emoji wrote:
| Market capture via corner cutting excuses lazy engineering by
| evil bloated monopolist. Got it.
|
| (I'm still shocked how they've begun losing to AMD. Having
| all of the money, dirty benchmarking tricks, and "let's just
| hire all of the people" haven't worked out, incredibly.)
| laserdancepony wrote:
| The IA-32 ISA has been so successful _because_ of the no-
| compromise downward compatibility, whether you _like_ that or
| not.
|
| See all the revolutionary ISAs from the 80s, 90s and 00s that
| did away with all that legacy crap. Where are they now? I think
| the only one still working is POWER.
| fmajid wrote:
| The ARM architecture was introduced in 1985 and the first
| real shipping product, the Acorn Archimedes, in 1987.
| deaddodo wrote:
| ARM also is very backwards compatible, there have only been
| two major breaks in compatibility. The ARM6 (which dropped
| legacy memory addressing modes) and aarch64 (which made
| certain extensions required + dropped support for old ARM7
| and ARM9 modes).
| kps wrote:
| And the thumb stuff. You can buy 32-bit ARM chips that
| have _zero_ binary instructions in common with any 32-bit
| ARM before 1994.
| deaddodo wrote:
| Yeah, sorry; thumb was part of the ARM7/9 features I was
| referring to. It also dropped the hardware Java support.
|
| To be fair, both were always "optional" features; but
| yes, there are thousands of devices that shipped with
| them (one of the biggest being the GBA, with the majority
| of games heavily relying on THUMB).
| dtx1 wrote:
| My biggest Issue would be Retro Gaming. Unless there is suitable
| Emulation for 32Bit (on linux in my case) I'd be annoyed...
| xanathar wrote:
| Unless by that you also mean running old OSs (e.g. Windows
| 95... but you probably can't run that already, in a world with
| UEFI and no A20) then you're fine: they are removing ring-0
| 32bit, but not ring-3 32bit.
| EuropeOverlords wrote:
| Why ?
| dtx1 wrote:
| Cause I like to play old games
| mepian wrote:
| QEMU [0] emulates many systems, including the 32-bit Intel
| architecture. For retro gaming specifically I can recommend
| PCem [1], which also emulates a wide range of sound and
| graphics cards, from IBM MDA to 3dfx Voodoo 2.
|
| [0] https://www.qemu.org/
|
| [1] https://pcem-emulator.co.uk/
| dtx1 wrote:
| For REALLY old games PCEM works but for later games (think
| generation half life 2+) it becomes very tedious to work with
| VMs, especially when you have to do GPU Passthrough
| mepian wrote:
| Looks like 32-bit user mode (but not kernel mode) is not
| getting removed, so these games should still work.
| BooneJS wrote:
| As long as their scalar and vector units still support packed
| 8/16/32-bit data, this seems fine? Too bad there's no OS
| telemetry on the number of legacy apps still in operation.
| nickcw wrote:
| I wonder what practical benefit this will have to the CPUs?
|
| Presumably a few less transistors, but a small % I'd guess.
|
| Will it make anything run faster? If so, what?
| mepian wrote:
| Verification would become significantly easier.
| layer8 wrote:
| If I read this correctly, 32-bit application code (ring 3) would
| remain mostly unaffected.
| EuropeOverlords wrote:
| [flagged]
| rowanG077 wrote:
| Holy shit! Someone reiterated what they thought the article
| said and you go nuclear. Do you think this is even a remotely
| good way to comment?
| Razengan wrote:
| They woke up and chose violence.
| ludocode wrote:
| > Not even title of article says anything even remotely
| suggesting it will go away.
|
| As a matter of fact "64-Bit-Only" is in the title of the
| article. That sure sounds like they are dropping 32-bit
| support, does it not?
|
| As the poster said, they are keeping 32-bit ring 3 support,
| contrary to the title of the article.
| 0zemp2c wrote:
| cool but market forces are shoveling dirt on to the coffin of x86
| no matter what, the window has closed
| sgift wrote:
| I've been hearing that for 20 years. Maybe this time it's true,
| maybe not.
| laserdancepony wrote:
| Yes, Itanium will make the Pentium obsolete!
| tempodox wrote:
| Will they finally have consistent register names?
| Iwan-Zotow wrote:
| Will be there an i87 inside? With 80bits registers?
| allenrb wrote:
| It looks like they're keeping x87 support, which feels like a
| missed opportunity. Does any modern compiler generate these
| instructions?
|
| Stripping out x87 and the associated 80 bit registers, weird
| modes, etc would seem right in line with this effort. If
| someone _really_ needs x87 support, trap those instructions and
| emulate in kernel. Nothing with truly high performance
| requirements will be using them. Intel could even provide the
| code.
| Veliladon wrote:
| Yes. It'll still be there. The only difference will be that you
| won't be able to do stuff that CR0 can control like disabling
| the FPU for whatever reason.
| monocasa wrote:
| You'll still be able to do that too. X87 (and MMX using the
| same register file) is still fully visible to 64 bit code.
| EuropeOverlords wrote:
| [flagged]
| buran77 wrote:
| > a 32-bit OS can only address 3.2 GB of RAM
|
| Is that true though? 32bit Windows 2003 Enterprise or Datacenter
| editions were perfectly capable of accessing 64GB or RAM [0].
| Even so, that difference from the usual 4GB and 3.xGB was any
| kind of memory usage for integrated GPU or virtual address space
| mapping for different hardware.
|
| [0] https://learn.microsoft.com/en-
| us/windows/win32/memory/memor...
|
| P.S. I think the "3.2" figure irked me more than the usual "32bit
| OSes can't use more than 4GB". That's not a real limit and never
| was. Even people with no IT knowledge would have noticed it
| varies quite a bit anyway. I guess I expected a little more from
| a tech reporter.
| hydroreadsstuff wrote:
| It's 4GB per address space / per process. In aggregate you can
| use more.
| [deleted]
| 6510 wrote:
| I vaguely remember some software that put the swap on a ram
| drive.
| pmalynin wrote:
| Yea the 64 gig thing is from PAE I think.
___________________________________________________________________
(page generated 2023-05-20 23:00 UTC)