4 ms·

So nowdays this table could have been fixed with a microcode update right?

by Thaxll 2y ago

jeffbee 2y ago
With a microcode update that ruins FDIV performance, sure. Even at that time there were CPUs still using microcoded division, like the AMD K5.
- Netch 2y ago
  This division, using SRT loop with 2 bit output per iteration, perhaps would have already been microcoded - but using the lookup table as an accelerator. An alternative could use a simpler approach (e.g. 1-bit-iteration "non-restoring" division). Longer but still fitting into normal range. But if they had understood possible aftermath of non-tested block they would have implemented two blocks, and switch to older one if misworking was detected.
  - tliltocatl 2y ago
    That was before dark silicon and real estate was still somewhat expensive, so probably having two blocks wasn't really an option.
phire 2y ago
The table couldn't be fixed. But it can be bypassed. The microcode update would need to disable the entire FDIV instruction and re-implement it without using any floating point hardware at all, at least for the problematic devisors. It would be as slow as the software workarounds for the FDIV bug (average penalty for random divisors was apparently 50 cycles). The main advantage of a microcode update is that all FDIVs are automatically intercepted system-wide, while the software workarounds needed to somehow find and replace all FDIVs in the target software. Some did it by recompiling, others scanned for FDIV instructions in machine code and replaced them; Both approaches were problematic and self-modifying code would be hard to catch. A microcode update "might" have allowed Intel to argue their way out of an extensive recall. But 50 cycles on average is a massive performance hit, FDIV takes 19 cycles for single-precision. BTW, this microcode update would have killed performance in quake, which famously depended on floating point instructions (especially the expensive FDIV) running in parallel with integer instructions.
- hakfoo 2y ago
  It's interesting that there's no "trap instruction/sequence" feature built into the CPU architecture. That would presumably be valuable for auditing and debugging, or to create a custom instruction by trapping an otherwise unused bit sequence.
  - j16sdiz 2y ago
    > create a custom instruction by trapping an otherwise unused bit sequence. .. ... until a new CPU support an instruction extension that use the same bit sequence.
    - immibis 2y ago
      That's why architectures - including x86! - have opcodes they promise will always be undefined.
      - colejohnson66 2y ago
        Those undefined opcodes are more for testing your fault handler or for forcing a trap in an “unreachable” part of your code, not to implement custom instructions.
        phire 2y ago
        Yeah... Part of the reason why existing functionality is limited and nobody uses them to implement custom instructions, is that trapping is actually quite expensive. The switch to kernel space and back is super expensive, but even if a CPU did implemente fast userspace trap handlers, it wouldn't be fast.
        immibis 2y ago
        They can be used for anything you want. The CPU treats them as described in the document. They're not fast, though. You probably don't want to run trapped fake instructions in tight loops, but you don't want that no matter how they're implemented.

So nowdays this table could have been fixed with a microcode update right?

by Thaxll 2y ago

So nowdays this table could have been fixed with a microcode update right?

With a microcode update that ruins FDIV performance, sure. Even at that time there were CPUs still using microcoded division, like the AMD K5.

Netch 2y ago
This division, using SRT loop with 2 bit output per iteration, perhaps would have already been microcoded - but using the lookup table as an accelerator. An alternative could use a simpler approach (e.g. 1-bit-iteration "non-restoring" division). Longer but still fitting into normal range. But if they had understood possible aftermath of non-tested block they would have implemented two blocks, and switch to older one if misworking was detected.
- tliltocatl 2y ago
  That was before dark silicon and real estate was still somewhat expensive, so probably having two blocks wasn't really an option.

phire 2y ago

The table couldn't be fixed. But it can be bypassed. The microcode update would need to disable the entire FDIV instruction and re-implement it without using any floating point hardware at all, at least for the problematic devisors. It would be as slow as the software workarounds for the FDIV bug (average penalty for random divisors was apparently 50 cycles). The main advantage of a microcode update is that all FDIVs are automatically intercepted system-wide, while the software workarounds needed to somehow find and replace all FDIVs in the target software. Some did it by recompiling, others scanned for FDIV instructions in machine code and replaced them; Both approaches were problematic and self-modifying code would be hard to catch. A microcode update "might" have allowed Intel to argue their way out of an extensive recall. But 50 cycles on average is a massive performance hit, FDIV takes 19 cycles for single-precision. BTW, this microcode update would have killed performance in quake, which famously depended on floating point instructions (especially the expensive FDIV) running in parallel with integer instructions.

hakfoo 2y ago
It's interesting that there's no "trap instruction/sequence" feature built into the CPU architecture. That would presumably be valuable for auditing and debugging, or to create a custom instruction by trapping an otherwise unused bit sequence.
- j16sdiz 2y ago
  > create a custom instruction by trapping an otherwise unused bit sequence. .. ... until a new CPU support an instruction extension that use the same bit sequence.
  - immibis 2y ago
    That's why architectures - including x86! - have opcodes they promise will always be undefined.
    - colejohnson66 2y ago
      Those undefined opcodes are more for testing your fault handler or for forcing a trap in an “unreachable” part of your code, not to implement custom instructions.
      - phire 2y ago
        Yeah... Part of the reason why existing functionality is limited and nobody uses them to implement custom instructions, is that trapping is actually quite expensive. The switch to kernel space and back is super expensive, but even if a CPU did implemente fast userspace trap handlers, it wouldn't be fast.
      - immibis 2y ago
        They can be used for anything you want. The CPU treats them as described in the document. They're not fast, though. You probably don't want to run trapped fake instructions in tight loops, but you don't want that no matter how they're implemented.