15 ms·
Intel Explores Transition to 64-Bit-Only X86S Architecture
- Netch 3y ago1. Reading the current spec I'm most wondering with mandatory paging enable. This requires prefilled paging catalogs in RAM. Does it mean CPU can't start until ME (or another external agent) generates these catalogs? It also looks really weird compared to other ISAs as System/Z or SPARC which really benefit of not using page translation in kernel mode. I'd expect alleviation of switching paging on and off... 2. Looks it's a good moment to relax memory ordering from TSO, with easy control using Flags. (Using it will gradually soar in years, yep.)
- vinyl7 3y agoI wonder if Intel will still have to pay licensing fees to AMD for x64 with this move?
- manuelabeledo 3y agoThey have a cross-licensing agreement.
- EuropeOverlords 3y ago[flagged]
- monocasa 3y agoAlmost 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.
- Iwan-Zotow 3y agoWill be there an i87 inside? With 80bits registers?
- Veliladon 3y agoYes. 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 3y agoYou'll still be able to do that too. X87 (and MMX using the same register file) is still fully visible to 64 bit code.
- allenrb 3y agoIt 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.
- jcranmer 3y agoI suspect the main thing keeping x87 support is that 32-bit ABIs for x86 still use it, just for returning floats and doubles from functions, which makes trap-and-emulate not an effective solution.
- addaon 3y agoThere's still no replacement for high precision long doubles on x86; 128 bit float support seems unlikely, and double-double has not caught on. Sometimes 64 bits just ain't enough.
- linusg789 3y agoAlso see https://news.ycombinator.com/item?id=36006446 https://news.ycombinator.com/item?id=36006446
- BulgarianIdiot 3y agoAbsolutely. 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 3y agoIMHO a similar point could be made about the C++ language spec, sadly.
- BulgarianIdiot 3y agoSame 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.
- stjohnswarts 3y agoRust is still in the noise vs the amount of market share that C++ has. That said I love it as a language but it's hardly "taking over", I have tried to push it at my company a bit for command line utilities.
- delta_p_delta_x 3y agoThere 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 https://github.com/carbon-language/carbon-lang [2]: https://github.com/hsutter/cppfront https://github.com/hsutter/cppfront
- bigdict 3y agoHa, literally thought about this 5 days ago. https://news.ycombinator.com/item?id=35942727 https://news.ycombinator.com/item?id=35942727
- EuropeOverlords 3y ago[flagged]
- deaddodo 3y agoWhat 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.
- EuropeOverlords 3y ago[flagged]
- deaddodo 3y agoYes, MY statement is the totally unhinged and insane one. Got it.
- EuropeOverlords 3y ago[dead]
- junon 3y agoFabulous. 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.
- akira2501 3y ago> 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.
- shrimp_emoji 3y agoMarket 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.)
- mistrial9 3y agoanyone 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.
- fbdab103 3y ago>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.
- layer8 3y agoIf I read this correctly, 32-bit application code (ring 3) would remain mostly unaffected.
- EuropeOverlords 3y ago[flagged]
- rowanG077 3y agoHoly 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 3y agoThey woke up and chose violence.
- EuropeOverlords 3y ago[flagged]
- ludocode 3y ago> 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 3y agocool but market forces are shoveling dirt on to the coffin of x86 no matter what, the window has closed
- sgift 3y agoI've been hearing that for 20 years. Maybe this time it's true, maybe not.
- laserdancepony 3y agoYes, Itanium will make the Pentium obsolete!
- tempodox 3y agoWill they finally have consistent register names?
- pyrolistical 3y agoIsn’t this still makeup on a pig? They will still have a tiny risc machine underneath
- mepian 3y agoThey don't have a "tiny risc machine" underneath, that's a myth. EDIT: https://qr.ae/pyvelA https://qr.ae/pyvelA
- pengaru 3y ago> They don't have a "tiny risc machine" underneath, that's a myth. https://stackoverflow.com/questions/5806589/why-does-intel-hide-internal-risc-core-in-their-processors https://stackoverflow.com/questions/5806589/why-does-intel-h...
- nickcw 3y agoI 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?
- Animats 3y agoAMD 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.
- kps 3y ago> The Pentium Pro (1995), the first good superscalar microprocessor … I thought the i960CA was good.
- kjs3 3y agoPPro 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.
- Narishma 3y agoI 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.
- timw4mail 3y agoIt's performance advantage was only on 32bit code, 16bit code was not further optimized. The high cost (and high manufacturing cost) certainly didn't help either.
- stjohnswarts 3y agoThat "older baggage" takes up less than 5% of the chip. While I'm all for simplifying the platform, lets not act like it's a major step. It's not going to make much difference either size or speed wise, but it's just plain time to put 32 bit to rest.
- dtx1 3y agoMy biggest Issue would be Retro Gaming. Unless there is suitable Emulation for 32Bit (on linux in my case) I'd be annoyed...
- EuropeOverlords 3y agoWhy ?
- dtx1 3y agoCause I like to play old games
- EuropeOverlords 3y ago[flagged]
- dtx1 3y agoAre you high? Anyway I'm talking about 32bit based windows games from 2000 forward
- EuropeOverlords 3y ago[flagged]
- mepian 3y agoQEMU [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/ https://www.qemu.org/ [1] https://pcem-emulator.co.uk/ https://pcem-emulator.co.uk/
- dtx1 3y agoFor 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
- EuropeOverlords 3y ago[flagged]
- londons_explore 3y agoI 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.
- wmf 3y agoThe proposal is from Intel. How sure are we that we know better than Intel?
- moffkalast 3y agoWe ask AMD what they think about it?
- rowanG077 3y agoWhy would Intel propose it if there are is no benefit?
- chx 3y ago1. 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.
- mappu 3y agoThe main x86_64 patents have all expired, but this would get to be patented again.
- anticensor 3y agoYou cannot patent a removal without an accompanying addition.
- BooneJS 3y agoAs 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.
- buran77 3y ago> 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/memory-limits-for-windows-releases 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 3y agoIt’s 4GB per address space / per process. In aggregate you can use more.
- 6510 3y agoI vaguely remember some software that put the swap on a ram drive.
- deleted 3y ago[deleted]
- pmalynin 3y agoYea the 64 gig thing is from PAE I think.
- EuropeOverlords 3y agoyet, processors had that, even before 32BIT 4GB issue was even issue in press XD
- EuropeOverlords 3y ago[flagged]
- dusted 3y agomaking a mental note that the 32 bit compatible era is coming to an end and I should start thinking about stocking up on hardware
- fb03 3y agowhat about emulators?
- rnd0 3y agoIf the hardware has DRM (or is locked down in other ways), then emulation won't help you out -having the actual hardware will be much more desirable.
- dusted 3y agoThey have their place. They're not perfect though. Also, I'm not perfect, I have an attachment to the physical realm, and I desire not simply to run software, but to run it on hardware, whatever that means. Oftentimes, I desire simply to run hardware for its own sake, because it brings me pleasure.
- ksec 3y agoI wish they just opens up x86s so everyone could implement it. ( I assume we are well past the 20 years patent so most of it doesn't matter )
- hyperman1 3y agoI wonder how much they can gain from it. Suppose they push all 16 bit and 32 bit kernel mode code to microcode,basically building an interpreter inside the CPU. This would sacrifice performance but not compatibility. Probably today's design is already close.
- notorandit 3y ago> a 32-bit OS can only address 3.2 GB of RAM I am wondering how these numbers stick together. I especially wonder why those extra 0.8 GB are unaccessible, when did that happen and who's the thief
- Netch 3y agoThe design of current x86s is that multiple regions under 4GB boundary are occupied by I/O regions, some of them tied to processor (as APIC, HPET, etc.) and some to extension cards which reject working in 64-bit mode. 3.2GB is an example figure - it could be 3.5GB, 3.6GB... - but reflects that RAM can't be mapped at all of lower 4GB. Memory controllers typically remap part of it to a range upper than 4GB boundary, so 32-bit PAE-capable or 64-bit OS can still use it. OTOH using 64-bit OS is recommended with RAM >=1.5GB because if OS can't map all RAM _twice_ and all device memory to virtual address space, tricks with memory banking (frequent page remapping) are getting needed to deal with data move.
- pvillano 3y agoInvoking Cunningham's, I'd guess it's memory mapped I/O occupying 0xE0000000 - 0xFFFFFFFF. That's the top ⅛ of the address space, which is every binary address starting with 111. In researching this I learned that some 32bit hardware could utilize 128GB of ram using Physical Address Extensions. Each process is still limited to 4GB though.