Destroying x86_64 instruction decoders with differential fuzzing • Hacker News Board

Re: Destroying x86_64 instruction decoders with differential fuzzing

#21

Post by jstanley » Thu, Oct 31, 2019, 4:44 PM UTC

wolfgke wrote: post #13

teddyh wrote: post #6

Earlier quoted context omitted.

See also this old Microsoft Windows 95-era joke: “ 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition. ”

> “32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.” DOS was a 16 bit operating system. The 8088 (the processor of the IBM-PC) was an 16 bit (if you consider the instruction set) or 8 bit (if you consider the width of the data bus) processor.

CP/M was an 8-bit operating system.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#22

Post by jandrese » Thu, Oct 31, 2019, 4:51 PM UTC

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…

I think your intuition is correct that the translation step is cheap on modern silicon. One interesting thing to note is that Intel doesn't allow you to write code as micro-ops to bypass that step. This is an advantage for them as it allows them to optimize (add, modify, and remove) microops with every generation without having to worry about backwards compatibility. As long as your compiler can spit out some crusty old x86 looking instructions it is free to optimize all it wants under the hood. Having a more efficient ISA introduces a lot of pain with backwards compatibility for only a modest reduction in complexity for a step that is cheap already. Not a win.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#23

Post by solarexplorer » Thu, Oct 31, 2019, 4:55 PM UTC

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.

Well, actually they did try a few times. Itanic and the Intel iAPX 432 come to mind...

Re: Destroying x86_64 instruction decoders with differential fuzzing

#24

Post by cogman10 » Thu, Oct 31, 2019, 5:01 PM UTC

tyoma wrote: post #5

stragies wrote: post #2

From the great article: "x86_64 is the 64-bit extension of a 32-bit extension of a 40-year-old 16-bit ISA designed to be source-compatible with a 50-year-old 8-bit ISA. In short, it’s a mess, with each generation adding and removing functionality, ..." Nice way of wording that! :) It also explains the complexity of the following 10 pages of text.

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 mean, I get why it didn't happen. Stupid history chose wrong (Like making electrons have a negative charge).

Re: Destroying x86_64 instruction decoders with differential fuzzing

#25

Post by unlinked_dll » Thu, Oct 31, 2019, 5:03 PM UTC

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.

https://en.wikipedia.org/wiki/IA-64

Re: Destroying x86_64 instruction decoders with differential fuzzing

#26

Post by baybal2 » Thu, Oct 31, 2019, 5:07 PM UTC

jcranmer wrote: post #12

setpatchaddress wrote: post #11

Earlier quoted context omitted.

Sounds like survivorship bias. x86's longevity is due to the amount of money thrown at the problem. You could surely start with a much cleaner instruction set like the M68k and wind up with a same-or-better result after spending billions on multiple projects to invent new ways of ameliorating the complexity of the ISA, some in parallel, over time. Or you can start by eliminating most of the decode complexity and not…

The decoder doesn't actually take all that much space in the hardware, though. It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware.

Saw die shots of Atom? Decoder makes more than half of the core, and there is no instruction cache.

In a loop, you will be spending more joules on decoding than actual computations.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#27

Post by bogomipz » Thu, Oct 31, 2019, 5:11 PM UTC

Wow, this a wonderfully rich post! I had a question about the following statement:

>"In short, it’s a mess, with each generation adding and removing functionality, reusing or overloading instructions and instruction prefixes, and introducing increasingly complicated switching mechanisms between supported modes and privilege boundaries."

Can someone elaborate on how a instruction at the machine level can be "overloaded"? At this machine level how can an instruction be mapped to more than one entry in the microcode table? Or does this mean overloading in the regular programming sense of something like an ADD instruction capable of working with ints, strings etc.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#28

Post by snoes » Thu, Oct 31, 2019, 5:14 PM UTC

I might be overlooking this as I am on mobile, but what is the license for mishegos?

Re: Destroying x86_64 instruction decoders with differential fuzzing

#29

Post by wolfgke » Thu, Oct 31, 2019, 5:16 PM UTC

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…

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

Re: Destroying x86_64 instruction decoders with differential fuzzing

#30

Post by darkmighty » Thu, Oct 31, 2019, 5:16 PM UTC

jcranmer wrote: post #12

setpatchaddress wrote: post #11

Earlier quoted context omitted.

Sounds like survivorship bias. x86's longevity is due to the amount of money thrown at the problem. You could surely start with a much cleaner instruction set like the M68k and wind up with a same-or-better result after spending billions on multiple projects to invent new ways of ameliorating the complexity of the ISA, some in parallel, over time. Or you can start by eliminating most of the decode complexity and not…

The decoder doesn't actually take all that much space in the hardware, though. It's going to be smaller than the normal OoO logic, which means it's a pretty minor tax at best for actual hardware.

Instruction complexities can be used to save bandwidth/delay (and related energy consumption) at the cost of decoder size. Communication limitations are increasingly dominant in processors afaik; so the analysis is not so simple as to decoder size either.