Hacker News Reader

Comment by junon | Hacker News Reader

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.

View on HN

> 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.

> 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.

> 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 :/.

>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.

The IRQ remapping / A20 / segmented memory happened years before the AMD benchmarking / Dell payouts / etc.

Not to mention sabotaging AMD performance for all programs compiled with the Intel C Compiler

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.)

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.

> 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.

What might be their motivation for this, then?

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.

Save die space and thus reduce cost and power budgets. Potentially simplify microarch and cache management. Maybe reduce attack surface?

Nah, the die space you save here is absolutely minuscule. Intel saves on the validation of core designs -- forever.

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.

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.

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.

The 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.

I 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.

> 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-...

> 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.

I 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.

Not "errata". 286 had more address space, so above 1MB didn't wrap around (by design). But this differed from 8086.

I thought the idea was that in real mode it should be have like a faster 8086, and exposing memory beyond 1Mb breaks the illusion.

It 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.

"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://web.archive.org/web/20220701015547/https://www.mrhec...

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.

> I wonder how this will affect quirks such as A20

A20 was removed in Haswell (released pretty much exactly ten years ago).

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.

The ARM architecture was introduced in 1985 and the first real shipping product, the Acorn Archimedes, in 1987.

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).

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.

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).

The 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."

Or perhaps they have been successful primarily because of luck. They were lucky to be selected by IBM for the PC. Once they were riding the PC wave, their position as market leader (by volume, not quality) kept them there.

I 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.

While 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.

Something 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.

Do 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.

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?

Looks like SMM is still there.

There are no TPM/DRM bolt-ons in the specification.

Yet.

Reply on news.ycombinator.com