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

I found a bug in Intel Skylake processors

gallium.inria.fr

Post reply on HN
Print view View original

21–30 of 104 posts

Re: I found a bug in Intel Skylake processors

#21

Post by jstimpfle »

acdha wrote: post #18
etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

Did you miss the part about where the bug was found using the current versions of GCC to build the current versions of OCaml? It's lazy to the point of dishonesty to act as if Microsoft is the only one with decades of accumulated code.

There is still a point that proprietary binaries are probably the biggest force keeping decades of cruft in processors. (Not judging here)

Re: I found a bug in Intel Skylake processors

#22

Post by [deleted] »

acdha wrote: post #18
etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

Did you miss the part about where the bug was found using the current versions of GCC to build the current versions of OCaml? It's lazy to the point of dishonesty to act as if Microsoft is the only one with decades of accumulated code.

[deleted]

Re: I found a bug in Intel Skylake processors

#23

Post by rbehrends »

etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

That's not what happened. You can reproduce what gcc does easily by trying to compile the following code:

  int f(int x) { return x | 256; }
Gcc generates the following code:

  movl    %edi, %eax
  orb     $1, %ah
  ret
In contrast, clang uses an orl instead of orb. The advantage of using orb is that it generates shorter code with an immediate operand. This is on an x86_64 architecture and does not involve 32-bit code.

Re: I found a bug in Intel Skylake processors

#24

Post by etatoby »

jstimpfle wrote: post #21
acdha wrote: post #18

Earlier quoted context omitted.

Did you miss the part about where the bug was found using the current versions of GCC to build the current versions of OCaml? It's lazy to the point of dishonesty to act as if Microsoft is the only one with decades of accumulated code.

There is still a point that proprietary binaries are probably the biggest force keeping decades of cruft in processors. (Not judging here)

Precisely. I would go as far as saying proprietary binaries for Microsoft systems are the single force making Intel processors keep decades of cruft, considering the immense cost that Intel must bear to keep those old instructions (barely) running on modern processors.

Re: I found a bug in Intel Skylake processors

#25

Post by nneonneo »

etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

Unfortunately, you simply aren't correct - the blame here can't be placed with Microsoft. The bug occurs in 64-bit code, which is using the AMD64 instruction set. This instruction set is incompatible with the older 32-bit i386 instruction set, but shares many of its features.

During the move to AMD64, AMD decided to remove many features of the old architecture (for example, removing many one-byte instructions that were taking up valuable opcode space). However, they decided not to touch the AH/BH/CH/DH register access modes - yet it was entirely in their power to do so because they were developing a new architecture with no existing code. So, if you're going to blame someone for this, blame AMD for wanting to keep too many legacy features in what was designed to be a brand new architecture.

For examples of a 64-bit architecture that aren't simply extensions of the 32-bit versions, look at AArch64 (compared with the classic ARM instruction set), or Itanium (Intel's ultimately-unsuccessful attempt to build a brand-new 64-bit architecture cleanly broken from the legacy 32-bit set).

Re: I found a bug in Intel Skylake processors

#26

Post by etatoby »

rbehrends wrote: post #23
etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

That's not what happened. You can reproduce what gcc does easily by trying to compile the following code: int f(int x) { return x | 256; } Gcc generates the following code: movl %edi, %eax orb $1, %ah ret In contrast, clang uses an orl instead of orb . The advantage of using orb is that it generates shorter code with an immediate operand. This is on an x86_64 architecture and does not involve 32-bit code.

My point is that binary executables for Microsoft OSes, and the entire market built around them, are the only reason something like %ah (which is an incredibly stupid and expensive thing to address and the actual source of the bug) is part of the x86_64 architecture in the first place.

Re: I found a bug in Intel Skylake processors

#28

Post by rbehrends »

tom_mellior wrote: post #11
raverbashing wrote: post #3

GCC generates code that's smaller but it isn't optimal, because of the potential for partial register stalls (and just overall register renaming issues) It's of course not wrong, but using AH when you're dealing with RAX is a weird anachronism Clang does the obvious, correct thing.

Do you know for a fact that Clang's code is faster here, i.e., have you measured it on actual hardware? Armchair performance estimation about "the potential" for something is often wrong...

In a micro benchmark, using the clang version appears to be a bit faster. However, note that code size can also become a relevant concern in larger code bases: Apple, for example, is said to generally build its OS code with -Os rather than -O2 or -O3 (and had -Oz as an even more aggressive custom code size optimization added to gcc back when they still were using it instead of clang).

Re: I found a bug in Intel Skylake processors

#29

Post by shawnz »

zrth wrote: post #12
raverbashing wrote: post #8

Earlier quoted context omitted.

It is obvious, though I meant "obvious and correct" not "obviously correct"

Who can clarify? Google says: Qbvious - easily perceived or understood; clear, self-evident, or apparent.

Sounds like by "obvious" the parent means that Clang uses the most trivial approach.

Re: I found a bug in Intel Skylake processors

#30

Post by MaulingMonkey »

etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

I routinely peddle in binaries for open source, and even my own projects. Building from source is a pain in the ass, usually nondeterministic, and a constant maintenance burden with evolving compilers and build toolchains - not exactly the beacon of stability. EDIT: And dear me, I forgot to mention slow.

If you think stability and correctness are bad now, try compiling random codebases from the 90s with a motley melange of random people using random compiler versions - some prerelease, some stable, some unpatched and broken - many of which have been just as if not more aggressive than CPU vendors with regards to things like "undefined behavior" in C and C++ codebases.

Yes, microcode bugs suck. No, getting rid of x86 won't eliminate them. No, getting rid of QAed, tested, and sometimes disassembly-verified binaries (for such things as verifying fixed duration crypto operations) in favor of compiling with any and every C compiler under the sun isn't going to improve stability and correctness. No, I really don't want to go through the bother of installing configuring and fixing your build chain either.

Post reply on HN