Hacker News Reader

Comment by acqq | Hacker News Reader

> The x86 ISA really is a mess!

No, it's not. I've written the compilers for both x86 and x64. One should not look for too much idealistic "symmetry" but look at it as a domain specific encoding language. Behind that encoding is anyway huge machinery that significantly speeds up that what is written in the language, and it's even proven that, when there is enough silicon, it is of advantage that some optimizations are actually done during the execution. Some execution statistics are simply dependent on the information which dynamically depends on execution and can't be pre-coded by a compiler.

Since long ago, even those processors that started as RISC got more and more instructions and started to worry about having them encoded with less bits.

And that all doesn't mean that the compilers shouldn't be as smart as possible to use the hardware the best it can be used.

View on HN

It's not my contention that RISC designs are necessarily faster/more power efficient/etc. It's just that the x86 design is, from an engineering perspective, a mess.

> Since long ago, even those processors that started as RISC got more and more instructions and started to worry about having them encoded with less bits.

x86-64 is not very space efficient, because of all the REX prefixes. Look at the comparative sizes of AArch64 and x86-64 binaries if you don't believe me.

From an engineering perspective it is hugely impressive that a 2020 AMD or Intel chip can run an x86 app compiled in '92 at something like 100 times the speed.

From an engineering perspective, these two assertions that have been prefixed with the qualifier, "from an engineering perspective," are entirely compatible.

28 years later, the speedup on their selected representation is 100x? That seems low for such a long time.

> from an engineering perspective

It's pretty awesome. Remember engineering doesn't happen in a void. It's influenced all sorts of shit including economics, existing investments etc.

I don't know how anyone can look at the list of one-byte opcodes and conclude that x86 isn't a mess.

Even ignoring all the annoying mismatches in semantics, all the awkwardly-fit expansions and prefixes do not lead to a good encoding. And it's far slower to figure out how long an instruction is than it should be.

> I don't know how anyone can look at the list of one-byte opcodes and conclude that x86 isn't a mess.

Or heck, even just the fact that real mode is still a thing.

The CPU contains essentially no hardware that is there only to support real mode, which is simply an documented combination of configurations of various protected mode relevant mechanism plus changed behavior of exactly one microarchitectural operation, which involves replacing bunch of nontrivial microcoded logic with simple 4 bit left shift.

But it's not just a matter of wasting transistors and silicon. The ancient x86 modes are like old legacy code in a software package you have to maintain. They add complexity. Intel hasn't exactly been cranking out an endless series of bug-free chips lately. It might behoove them to make a line of chips which are pure x86-64.

How many of the recent intel vulnerabilities would have been prevented by jettisoning real mode?

Could you elaborate on this a little more? What exactly is "the changed behavior of exactly one microarchitectural operation"? Which operation?

There is hardware that is there only to support v86-mode and v86 mode extensions though. V86 mode really really should go away...

In fact there isn't any hardware to speak of (3 bits worth of architectural registers and bunch of trivial logic related to that?) to support vm86 mode, and that is to some extent the consequence of how true real mode is implemented. The combination of paging enabled (which is not strictly necessary), protected mode enabled, 16b code segment and real mode style segment loads gets you vm86 mode (complete with weird stuff on stack of exception handler vectors), in fact when you look at vm86 entry gate descriptor, this is exactly what it does. The microarchitecture essentially does not care about that.

edit: there is no documented direct way to flip the segment/selector bit, which is the reason why you need documented vm86 mode. The hardware always calculate the linear address according to whatever is in shadow descriptor of segment/selector register, difference between real/vm86 and protected mode is what happens when you store something into there.

It is still a useful feature for people who want (or need) to run legacy apps or OS versions under virtualisation (VirtualBox etc). Forcing that use case to use CPU emulation would have a performance cost.

Although, they could disable real mode support in some CPUs as a market segmentation mechanism. Running a 64-bit OS with EFI boot, most users probably don’t really need real mode support.

How many people need to run DOS apps at 2020 processor speeds? I get that there are legacy systems at banks and power plants running DOS, but practically by definition they don't need 2020 speeds.

It’s not just DOS apps. Booting any OS using legacy BIOS boot (as opposed to EFI) needs real mode support, even if it never uses real mode again after the boot process completes. (Theoretically, you might be able to build a hypervisor which uses CPU emulation for real mode and hardware-based virtualisation in protected mode, but no such thing exists yet.)

So if someone has a legacy app running in a Windows XP/Vista/2003/etc VM, that VM needs real mode to boot.

The point is, it didn't matter as people wrote assembly by hand, and it doesn't matter now when everybody is using compilers. The opcode details are trivially solved by the tables, the know-how of those who programmed assembly was enough for most of the times they programmed, compilers can handle a lot, and the real problems that really have to be solved are simply not dependent on these issues at all.

And diagonally, the instruction set is surely not the reason why every internet page is tracked by thousands of companies and has to download more megabytes than the total RAM the whole x86 computers had.

And like I've said, all instruction sets since a while have to take care to be "compressed" in a way, which is simply a total opposite of what the critics pointed since RISC was introduced. Pure RISC was/is useful only under some very specific assumptions.

The appearance of "mess" is a result of "if was successful." But the problems it solved were/are real.

"It doesn't matter" (much) that it's a mess is one thing.

"It's not a mess" is quite another.

But 'compression' and 'mess' are very very different things. You can have organized compression. Look at the length encoding on RISC-V, or something. No prefix bytes in sight. On x86 the balance and methodology for getting different instruction sizes is completely garbage for historical reasons.

> The appearance of "mess" is a result of "if was successful." But the problems it solved were/are real.

It's because it's been collecting legacy since it was 8-bit all the way to 64-bit with vector units, not as an inevitable result of being successful.

The x86 architecture is a mess and it matters.

The reason it matters is because a disproportionate amount of energy is spent in the instruction decode system.

And that affects your battery life.

Yes. Precisely. As ex-Intel, I confirm all of your points.

The “mess”, though, is just a natural artifact of longevity. Many years of decisions that made sense in the moment accumulated to appear to be a “what WERE they thinking?” situation when, in fact, they were addressing the market forces and technology constraints of the day.

In the end, nobody buys your product because the elegant design means that two generations of your product later it will have good performance. Sales are driven by what you can do in the here-and-now. If you do that well enough, you can live long enough to accumulate the kind of cruft that is the X86 ISA.

> The “mess”, though, is just a natural artifact of longevity. Many years of decisions that made sense in the moment accumulated to appear to be a “what WERE they thinking?” situation when, in fact, they were addressing the market forces and technology constraints of the day.

> In the end, nobody buys your product because the elegant design means that two generations of your product later it will have good performance. Sales are driven by what you can do in the here-and-now. If you do that well enough, you can live long enough to accumulate the kind of cruft that is the X86 ISA.

I think Itanium, or the pursuit of making Itanium the replacement for x86, demonstrated these quite well.

How messy is AARCH64 compared to X64? I imagine it's less, but ARM's been around for a while too hasn't it?

Much less, but it’s starting to get some uglier stuff in it. Since it doesn’t need to be backwards compatible the task of keeping it reasonable is much easier.

Cache takes the bulk of the idle power consumption, thanks to not-perfect transistors.

Battery life in benchmarks (and in a lot of real-world use cases) is more about how long the CPU spends in its halted sleep state, and how much power that takes, than its "full throttle" power usage.

Mobile x86 CPUs since Core Duo(?) have the ability to turn off parts of their caches in lower-power modes, for this reason.

Its a very small % of die space. Hardly any power compared to the rest of the CPU.

[Edit:] I got deja vu, searched my comment history, and found we were still harping on about this exact same crap 9 years ago: https://news.ycombinator.com/item?id=2061500

Even on 32nm, instruction decoding was a tiny % of die space!

> Even on 32nm, instruction decoding was a tiny % of die space!

Exactly that. Looking what the actual problems with the processors that tried to be better than x86-line were, the good or bad instruction "decoding" was certainly not what made them worse than x86-line, at the end.

Do you have a citation for the claim that this is a materially impactful portion of energy consumption (battery life)?

The claim is obviously wrong. x86 paid the cost for it's complex instruction decode ages ago so the real cost in today's die area is low. Recent changes to the ISA are only incremental cost increases.

Reply on news.ycombinator.com