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

101–110 of 113 posts

Re: Destroying x86_64 instruction decoders with differential fuzzing

#101

Post by dnautics »

cogman10 wrote: post #88
dnautics wrote: post #40

Earlier quoted context omitted.

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)

I'd say roughly around 2010 maybe 2015, compilers got to the point where they didn't totally suck at vectorization. Before that point, yeah, they were just too dumb to be able to make Itanium fast.

Polyhedral optimization is going to be exciting too.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#102

Post by tempguy9999 »

monocasa wrote: post #96
beagle3 wrote: post #91

Earlier quoted context omitted.

You are describing segmentation from the 286 protected mode and later. Real mode segmentation, originally introduced in the 8086/8088, is and always was an abomination, even if you don't compare it to the elegance of the contemporary 68000/68008.

Well, and GE-645 (ie. the special purpose MULTICS machine), the iAPX 432 (that Intel chip that gets a bad rap), the Plessey 250, and the CAP computer off the top of my head. ie. anywhere that describes the segment base, limit, and permissions on a separate privileged table.

> that Intel chip that gets a bad rap

I wonder why.

>>

https://en.wikipedia.org/wiki/Intel_iAPX_432#The_project%27s...

From memory a quote from a user of it, something like: "on a good day it walked, on a bad day it crawled"

IIRC every main memory access needed 3 pointer derefs and 3 array lookups (from memory).

Re: Destroying x86_64 instruction decoders with differential fuzzing

#103

Post by wtarreau »

winter_blue wrote: post #71
wtarreau wrote: post #61

Earlier quoted context omitted.

segment registers were a cheap MMU before its age. It was the only way to run code without relocation tables at various addresses. Mind you that at this era the whole operating system fitted in 40kB of RAM! My old turbo-pascal 3.0 editor+compiler was something around 37 kB! Just try to write a hello world of that size nowadays! It's pointless to criticize the past based on 10000 times more powerful hardware nowadays,…

> Just try to write a hello world of that size nowadays! The only reason why hello world binaries are bloated is because compilers for several compiled-to-native languages statically link many standard library functions into the final output executable. You can write a hello world DOS terminal program[1] for x86, using the DOS syscall 9 (invoked with interrupt 21h)[2]: format MZ push cs pop ds mov ah,9 mov dx,hello i…

It's also how I used to code under DOS (except using int 20h to exit and save 3 bytes, plus not copying CS into DS since .com has both equal). But my point precisely is that in order to provide such small binaries, you have to 1) have the skills, and 2) accept to think. Now many devs look up for obvious responses on stackoverflow before even making the effort of solving the problem by themselves, and as a result they inherit from tons of dependencies that cannot be removed and add huge stacks of functions with absolutely zero benefit for their use case.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#104

Post by NPC32419419 »

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.

Intel did not create x86_64. AMD did.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#105

Post by acdha »

cogman10 wrote: post #87
wolfgke wrote: post #29

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

I'd say the opposite is true. There isn't anything about Itanium that makes it worse for mobile. In fact, the opposite is true, it would be better for mobile because it was designed to push more of the optimizations into the compiler vs the hardware. That means less power required to do optimizations against running software. Because Itanium fits with mobile just as well as ARM does for much of the same reasons. Afte…

> There isn't anything about Itanium that makes it worse for mobile. In fact, the opposite is true, it would be better for mobile because it was designed to push more of the optimizations into the compiler vs the hardware. That means less power required to do optimizations against running software.

There's a big problem with that: the VLIW layout is not as memory efficient so programs were larger and the instruction cache needed to be larger to compensate. Mobile architectures have traditionally had smaller caches and less memory bandwidth to save power.

There is an interesting what-if question here: one of the big things which killed Itanium was the poor x86 compatibility meaning that while it was not entirely uncompetitive when running highly-optimized native code, it was massively slower for legacy apps even before you factored in the price. Compiler technology has improved by a huge degree since the 90s and in particular it's interesting to imagine would could happen in an Apple AppStore-style environment where developers ship LLVM bitcode which is recompiled for the target device, substantially avoiding the need to run legacy code.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#106

Post by api »

jandrese wrote: post #22
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…

A while ago I concluded that this was one of the core conceptual issues with EPIC/VLIW designs that try to shift microcoding to the compiler. It's not that it's impossible, but there is an advantage to having the microcode layer completely hidden. It frees the CPU core engineers almost completely from having to remain backward compatible with the software that runs on the chip.

At present I think of CISC instruction sets like X64 as something like a custom compression codec for the instruction stream. They're not an optimal codec but they're not too bad.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#107

Post by upofadown »

DannyB2 wrote: post #39
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.

Yeah, as I said, the 8086 was a pretty good 16 bit processor. It might not of been such a great 20 bit processor (it could only address 1 MB even with the segmentation).

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

That was a 32 bit processor. Yes things are simpler for large programs when you have lots of memory to put your code in and your instructions can take lots of space. The 68000 was as a result a lot easier to design. It was basically just a PDP-11 clone.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#108

Post by kjs3 »

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.

The OP referenced is what is called a 'joke'. Oddly, 'jokes' are not always intended to be pedantically accurate.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#109

Post by kjs3 »

snvzz wrote: post #98
AnimalMuppet wrote: post #74

Earlier quoted context omitted.

OK, the 286 was also garbage compared to the 68000.

So were 386, 486 and Pentium. At that time (Pentium), 68060 (which was also superscalar and released months earlier) would easily beat Pentium's performance at half the clock and much lower power. Later on, x86 would surpass 68000 series, but only because Motorola never released a 68k successor for 68060. They moved on to PowerPC.

Yes, the 68060 was pretty nifty, but no...Motorola moved on to the 88000, which was also very nice. Only then did they dump the 88k and gamble that joining IBM and Apple on the PPC would result in a bigger market to take on Intel. They were wrong.

Re: Destroying x86_64 instruction decoders with differential fuzzing

#110

Post by kjs3 »

AnimalMuppet wrote: post #74
wolfgke wrote: post #67

Earlier quoted context omitted.

> z80 and 8086 were both garbage, next to the 68000. At that time, Z80 and 8088/8086 targeted very different market segments than the 68000. So, this is a quite unfair comparison.

OK, the 286 was also garbage compared to the 68000.

I know it's heretical, but the '286 had a bunch of really interesting innovations, like a primitive capabilities based architecture. The big downfall of the '286 was they tried to do the 8086 backward compatibility and completely screwed it up. Ignoring that and writing an OS just for the '286 features was kinda interesting at the time. Not now...but at the time.
Post reply on HN