5 ms·
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
by junon 3y ago
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.
- 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.
- Lt_Riza_Hawkeye 3y agoNot to mention sabotaging AMD performance for all programs compiled with the Intel C Compiler
- nikanj 3y agoThe IRQ remapping / A20 / segmented memory happened years before the AMD benchmarking / Dell payouts / etc.
- buran77 3y ago> 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.
- SecretDreams 3y ago> It's hard to say how the x86 world would have looked like today if someone like Nvidia had a license. There's some alternate universe out there where x86 died because Nvidia was charging $1200 for a mid tier CPU so arm was able to creep up even faster :/.
- remexre 3y ago> 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 3y agoWhat might be their motivation for this, then?
- JohnBooty 3y agoIt 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 3y agoA 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 3y agoIt'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.
- luma 3y agoSave die space and thus reduce cost and power budgets. Potentially simplify microarch and cache management. Maybe reduce attack surface?
- zh3 3y agoEven 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?
- laserdancepony 3y agoThe 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 3y agoThe ARM architecture was introduced in 1985 and the first real shipping product, the Acorn Archimedes, in 1987.
- deaddodo 3y agoARM 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 3y agoAnd 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 3y agoYeah, 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).
- addaon 3y agoThe grandparent is referring to the fact the ARMv6-M and ARMv7-M architectures are Thumb only (and are different subsets of Thumb 1 and Thumb 2, to keep it spicy); so a Cortex M has zero instruction set overlap with a pre-Thumb ARM core, even though both are "32 bit ARM."
- Sesse__ 3y ago> I wonder how this will affect quirks such as A20 A20 was removed in Haswell (released pretty much exactly ten years ago).
- bitwize 3y agoSegmented 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.
- bcrl 3y agoThe way Intel did it was absolutely horrible. Had the left shift of segment selectors on the 8086 been 8 bits rather than 4, the extra 15MB of address space would have given DOS apps substantially more headroom. Having programmed C and assembly on both the x86 and the 68000 in the 1980s, x86 was an absolute nightmare to program. Even in C you had to always be intimately aware of your memory model at all times on x86 (remember near, far and huge pointers??!!?) annotating pointers to work around limitations of the architecture, whereas on 68k everything was just a 32 bit pointer. Oh the loss of productivity that one decision driven by the desire to save money avoiding putting an extra 4 address pins on the CPU ended up costing the industry. The horror.
- 13of40 3y agoI always thought the point with memory segments was that you could load a program verbatim without adjusting any pointers and do tricks like Terminate and Stay Resident and executing one program from another. E.g. Command.com and edlin.com don't need to know where they're loaded when they're both in memory, they just start at CS:0100.
- pwg 3y ago> 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.
- hakfoo 3y agoI thought it was a 286 errata-- where the address didn't wrap around correctly in real mode. The "fix" was IBM repurposing the keyboard controller to fix up the behaviour on A20.
- mlyle 3y agoNot "errata". 286 had more address space, so above 1MB didn't wrap around (by design). But this differed from 8086.
- hakfoo 3y agoI thought the idea was that in real mode it should be have like a faster 8086, and exposing memory beyond 1Mb breaks the illusion.
- mlyle 3y agoIt does break the illusion. At the same time, it allowed another ~64k of memory, which was important. DOS eventually sat up there in the non-wrapped memory. So, feature or bug? Heh.
- Findecanor 3y ago> 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-Efficient-and-Secure-Information-Wang-Wu/e6315c85d0e83727be327ea04ed3203a5c168530 https://www.semanticscholar.org/paper/SafeHidden%3A-An-Effic... [CETIS] https://www.semanticscholar.org/paper/CETIS%3A-Retrofitting-Intel-CET-for-Generic-and-Xie-Wu/d1643d2542c360330ff8ca9905008f7f24725f0e https://www.semanticscholar.org/paper/CETIS%3A-Retrofitting-... [Seimi] https://www.semanticscholar.org/paper/SEIMI%3A-Efficient-and-Secure-SMAP-Enabled-Memory-Wang-Wu/812607001031f55e2245f1d67377c873e331fa1e https://www.semanticscholar.org/paper/SEIMI%3A-Efficient-and... [InversOS] https://www.semanticscholar.org/paper/InversOS%3A-Efficient-Control-Flow-Protection-for-Shen-Criswell/a29a9856c3fbadcb61be838575a602ffd6e1fdac https://www.semanticscholar.org/paper/InversOS%3A-Efficient-...
- nickpsecurity 3y ago"their segmented memory nonsense was also a waste of development time and I'm glad to see them finally acknowledge it." Burroughs B5000 had segments. Roger Schell said it was added to Intel by a Burroughs guy when they requested hardware-enforced security to protect memory. They wanted to use it in upcoming OS's like GEMSOS. Rings came from SCOMP which also had an IOMMU in the 1980's. Descripters evolved into capability-based computer systems. Intel tried with Intel i432 APX and i960MX (good one). They lost billions. CHERI with RISC-V is the best of that lineage right now. https://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf https://www.cse.psu.edu/~trj1/cse443-s12/docs/ch6.pdf https://web.archive.org/web/20220701015547/https://www.mrheckman.com/yahoo_site_admin/assets/docs/DesigningTheGemsosSecurityKernel-OCR-120409-DRAFT.158131458.pdf https://web.archive.org/web/20220701015547/https://www.mrhec... https://homes.cs.washington.edu/~levy/capabook/ https://homes.cs.washington.edu/~levy/capabook/ (Note: Aesec might still sell GEMSOS today.) More recently, schemes like Native Client and Code Pointer Integrity used segments. The reviewer who broke the software versions of Code Pointer Integrity couldn't bypass the segment-enforced version. There was probably a lot of unexplored territory in combining modern, memory protection with segments. I'd like the alternatives to have as much assurance as designs on segments gave us. They're getting hacked more often, though.
- mise_en_place 3y agoDo you really need to use segmented memory? You can just go flat mode and put code segment and data segment in the same entry of the GDT. And run everything in ring0.
- userbinator 3y agoSomething like this is the only thing that would save the x86 architecture before ARM inevitably took over. On the contrary, it will make it worse. People choose x86 and the PC for the backwards compatibility, and Intel throwing that away is not going to make them any better than ARM.
- deterministic 3y agoI highly recommended not assuming that the engineers working for Intel are idiots. If something seems like an “obvious” mistakes by you, then it is highly likely that you have zero clue on the constraints that forced the decisions.
- Netch 3y agoWhile the _engineers_ of Intel are definitely not idiots - otherwise they couldn't have been getting enough success - the quasi-engineer layer over it, which makes the real technical decisions, showed a truly summit of folly, multiple times. - Foolhardy snatch 1: iAPX 432. - Degradation in first half of 1990s, concluded with FDIV bug, and marvellous savior "ASCI Red" which paid all OoO development (PPro and following). - Foolhardy snatch 2: RAMBUS + Itanium. Nearly collapse with P4 and miracle #2 with Israel team, Core, and stealing AMD64. I can't imagine that a person adopted EPIC-based Itanium had had a real engineering competence. (Not sure for iAPX 432, this is a complicated issue.) On a lower layes, as ISA details, every Intel move looks like using prediction less than for 1 move forward! Maybe 1/2 move sounds more veracious. Loads of examples. And, this also seems a guy that just remembered he was an "engineer" 30-40 years ago is now a decision maker.