4 ms·

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 encoura

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 support instructions that address the second-to-last byte of a register (eg. %ah) while keeping the rest of the register 'unchanged', which of course means making a complete mess of the code execution path. The only reason this crap still exists is to keep Windows users' ability to run random EXE and DLL files from the 90s, if not random COM files from the 80s, at the expense of CPU cost, stability, and correctness for everyone else (such as the OCaml developers and users who ran into this bug.)

acdha 9y ago
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.
- jstimpfle 9y ago
  There is still a point that proprietary binaries are probably the biggest force keeping decades of cruft in processors. (Not judging here)
  - etatoby 9y ago
    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.
  - striking 9y ago
    Those "decades of cruft" are usually emulated in microcode and not actual silicon. Intel knows very few people use the BCD instructions, but it costs them almost nothing to keep them in while running them slightly slower than most operations. Why mess up a stable API when you don't have to?
- deleted 9y ago
  [deleted]
rbehrends 9y ago
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.
- etatoby 9y ago
  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.
  - striking 9y ago
    That doesn't at all follow. Microsoft didn't invent the AH register.
  - rbehrends 9y ago
    That does not make sense. First, Windows in 64-bit mode does not even support running 16-bit applications. Second, there's plenty of 16-bit code that's completely unrelated to MS Office/Windows (such as MBRs; that's because the BIOS boot process requires real mode).
  - IncRnd 9y ago
    That isn't true. You can see that by this bug having been found on a system not running Windows.
nneonneo 9y ago
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).
- etatoby 9y ago
  You are right. I stand corrected.
MaulingMonkey 9y ago
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.
pjc50 9y ago
Shipping software executable form? That ship has sailed, long, long ago. Shipping source is both of little use to the vast majority of non-huge customers, and a way of guaranteeing that your software will be pirated. In fact, the demands of getting paid are moving us more and more to SaaS.
- acdha 9y ago
  Also, it's just trading one class of problems for another. Rather than supporting a compiled binary you need to support the entire build environment for every customer; having worked at a vendor who did that in the 90s I'm deeply skeptical that it would be an improvement.
- dom0 9y ago
  Shipping source has many practical issues for software deployment, including security implications, which is why many are moving away from using things similar to "pip" and towards things like "docker" (among other reasons).

acdha 9y ago

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.

jstimpfle 9y ago
There is still a point that proprietary binaries are probably the biggest force keeping decades of cruft in processors. (Not judging here)
- etatoby 9y ago
  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.
- striking 9y ago
  Those "decades of cruft" are usually emulated in microcode and not actual silicon. Intel knows very few people use the BCD instructions, but it costs them almost nothing to keep them in while running them slightly slower than most operations. Why mess up a stable API when you don't have to?
deleted 9y ago
[deleted]

rbehrends 9y ago

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.

etatoby 9y ago
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.
- striking 9y ago
  That doesn't at all follow. Microsoft didn't invent the AH register.
- rbehrends 9y ago
  That does not make sense. First, Windows in 64-bit mode does not even support running 16-bit applications. Second, there's plenty of 16-bit code that's completely unrelated to MS Office/Windows (such as MBRs; that's because the BIOS boot process requires real mode).
- IncRnd 9y ago
  That isn't true. You can see that by this bug having been found on a system not running Windows.

nneonneo 9y ago

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

etatoby 9y ago
You are right. I stand corrected.

MaulingMonkey 9y ago

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.

pjc50 9y ago

Shipping software executable form? That ship has sailed, long, long ago. Shipping source is both of little use to the vast majority of non-huge customers, and a way of guaranteeing that your software will be pirated. In fact, the demands of getting paid are moving us more and more to SaaS.

acdha 9y ago
Also, it's just trading one class of problems for another. Rather than supporting a compiled binary you need to support the entire build environment for every customer; having worked at a vendor who did that in the 90s I'm deeply skeptical that it would be an improvement.
dom0 9y ago
Shipping source has many practical issues for software deployment, including security implications, which is why many are moving away from using things similar to "pip" and towards things like "docker" (among other reasons).