Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Destroying x86_64 instruction decoders with differential fuzzing

blog.trailofbits.com

Post reply on HN
Print view View original

31–40 of 113 posts

Re: Destroying x86_64 instruction decoders with differential fuzzing

#31

Post by jcranmer »

api wrote: post #15

Tangent but: what's the additional overhead on a modern chip of parsing this crazy instruction set vs. a simpler to parse one like PPC64 or ARM64? Is it significant compared to all the other stuff that almost all modern CPUs do like out of order execution, register renaming, SIMD, virtualization, etc. etc. etc.? I've seen many people argue that it's significant but I never see anything in depth from anyone who really…

It's hard to get accurate numbers for this information, but the entire instruction decode stage on modern x86 decode is roughly the size of the OoO scheduler (see, e.g., https://wccftech.com/amd-ryzen-architecture-detailed/ that contains a vague core breakdown for AMD Ryzen).

Modern architectures all already execute on micro-ops instead of the actual ISA instructions, so instruction decode is going to have to have the micro-op lookup anyways, as well as the micro-op cache and other functionality in the decode stage. What you might gain in die area is going to be on the order of another execution unit at best--and the value of the extra execution unit may not be all that high if you can't fetch enough instructions per cycle to use that execution unit.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#32

Post by pcwalton »

api wrote: post #15

Tangent but: what's the additional overhead on a modern chip of parsing this crazy instruction set vs. a simpler to parse one like PPC64 or ARM64? Is it significant compared to all the other stuff that almost all modern CPUs do like out of order execution, register renaming, SIMD, virtualization, etc. etc. etc.? I've seen many people argue that it's significant but I never see anything in depth from anyone who really…

The variable length nature of the ISA is a big pain for out-of-order implementations. My understanding is that, to parse ahead in your instruction stream, you basically have to take every possible byte location starting at your PC and, in parallel, decode the instruction starting there. You'll eventually end up throwing away most of the results. Naturally, this costs a fair bit of power.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#33

Post by unlinked_dll »

wolfgke wrote: post #29
cogman10 wrote: post #24

Earlier quoted context omitted.

I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Wouldn't it be great if software instead of hardware, had complete control of instruction ordering? Wouldn't it be great to not be limited by the current SIMD restrictions? Wouldn't it be nice if you could choose to spend more compile time to get even faster programs (vs relying on the hardware to do it JIT)? I…

> I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Itanium was an architecture that was designed for "big iron", i.e. fast, powerful computers. It is thus, in my opinion, much harder to "scale down" to, say, mobile devices than x86.

x86 hasn't really proven that it scales down well for mobile devices either.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#37

Post by monocasa »

withzombies wrote: post #20
shakna wrote: post #19

Earlier quoted context omitted.

> ARM64 (aka AArch64) is the best version of x86 yet. Huh? Isn't that ARM and not even remotely compatible with x86?

ARM64 is what Intel would design if they learned from the lessons of x86 and got a chance to restart.

I'm sure that's not true. I've heard a great rant from an Intel CPU engineer about how CISC is a great fit for large OoO cores. Like how memory RMW instructions can be thought of as allocating physical register file resources with no architectural register file requirements, no extra instruction stream bits required, and no confusions inside the core about register data dependencies of the instruction.

It'd be fun to throw together a modern CISC-V or something that does a better job than x86 from an instruction encoding efficiency perspective, and see how it stacks up against modern RISCs.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#38

Post by rayiner »

cogman10 wrote: post #24
tyoma wrote: post #5

Earlier quoted context omitted.

Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.

I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Wouldn't it be great if software instead of hardware, had complete control of instruction ordering? Wouldn't it be great to not be limited by the current SIMD restrictions? Wouldn't it be nice if you could choose to spend more compile time to get even faster programs (vs relying on the hardware to do it JIT)? I…

Itanium was one of those scenarios where theory blew up in practice. In theory it’s great for software to have complete control of instruction ordering. In practice, software simply doesn’t have enough information at compile time to do that. As proven by the fact that even Itanium moved to an OOO architecture in Paulson.

It comes down to memory latency. Even an L3 cache hit these days is 30-40 cycles. It’s hard to predict when loads and stores will miss the cache, so there is little a compiler can do to account for that in scheduling. OOO can cover the latency of an L3 cache hit pretty well. And once you add it for that, why not just pretend you’ve got a sequential machine?

Re: Destroying x86_64 instruction decoders with differential fuzzing

#39

Post by DannyB2 »

upofadown wrote: post #14

>... a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In fairness to the Intel of that era, they actually did a really good job with this. They gained basically zero warts from the 8080 assembler source compatibility. They mostly set out to make the best variable length 16 bit instruction set they could. They had significant competition at the time and they pretty much had to ma…

The 8086 introduced the abomination of segment registers.

That created many software limitations for much of the 80's.

Compilers with 64 K limits on array sizes, or code segment sizes, and similar.

By comparison the 680x0 on classic Mac was a pleasure to program. A nice large simple flat address space.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#40

Post by dnautics »

cogman10 wrote: post #24
tyoma wrote: post #5

Earlier quoted context omitted.

Every time Intel has tried to more away from x86 (i960? Itanium? Maybe others...) they end up coming back. The years of backwards compatibility are a big selling point.

I really wish Itanium had taken off. IMO it is a superior architecture that was simply ahead of it's time. Wouldn't it be great if software instead of hardware, had complete control of instruction ordering? Wouldn't it be great to not be limited by the current SIMD restrictions? Wouldn't it be nice if you could choose to spend more compile time to get even faster programs (vs relying on the hardware to do it JIT)? I…

The stupid quip about sufficiently advanced compilers has actually been true until relatively recently, and shipping shared libraries has also been a thing for a while until recently (we basically ship shared libraries as statically linked these days, aka containers)
Post reply on HN