48 pointsby pwg3 hours ago3 comments
  • garganzol2 hours ago
    100x speed improvement of math operations by 8087 is not an overestimation. The difference for apps relying on math was crazy back then. I experienced this first-hand on my 80286 machine, where it was 3-second vs 300-second calculation results.

    One neat feature of 8087 instruction set is that it can be interspersed with x86 instructions in the code stream, giving you a simultaneous access to two processor chips working in parallel. This combo forms a real asymmetrical multi-processor system with certain opportunities for hardware-assisted code parallelization. If a thoughtful instruction scheduling is used, floating operations executed by 8087 work in parallel with the usual integer x86 code.

  • cogman102 hours ago
    x87 is such a weird architecture. It was designed the same way you'd design a chip for a scientific calculator. Heck, It's almost a perfect fit for an HP RPN calculator.

    But for a compiler to target, it's just so painful. It's so different from almost all other ways CPUs work. There's a reason both CPU and compilers prefer to avoid x87 when possible and use regular SIMD (SSE/AVX) instead.

    Also, the arbitrary "Oh, and the registers are 80 bits wide" is also just one of those weird "Where did that number come from?".

    • jcranmer28 minutes ago
      > But for a compiler to target, it's just so painful. It's so different from almost all other ways CPUs work. There's a reason both CPU and compilers prefer to avoid x87 when possible and use regular SIMD (SSE/AVX) instead.

      The x87 ISA is essentially a one-address stack-based ISA (so unlike a pure stack ISA, you can reference another value on the stack without having to introduce something like a dup instruction). Which honestly isn't particularly painful to work with for a compiler; it's not usual, but there are other ISAs that are also stack-based (the JVM bytecode is the one that most immediately comes to mind).

      The actual weirdness of x87, what makes all the compilers run away from it, is that the only values you can have on the stack are 80-bit extended-precision types. But people don't use those types in their code, they use 32-bit and 64-bit single and double precision, and compilers largely implemented these types by pretending that the x87 just used those value sizes in the first type (the only ones to actually get it correct that I'm aware of are Java's strictfp and Intel's icc, although the latter is merely just correctly implementing FLT_EVAL_METHOD==2). The end result is that compilers caused code to have essentially random and largely uncontrollable precision changes, which pissed a lot of users off, and the SSE units having regular scalar proper single and double precision types made it easier for compilers to switch to that rather than introducing the proper sequences to compile for x87.

    • em3rgent0rdran hour ago
      80-bit wide registers isn't really arbitrary if you consider that the bulk of the floating point number is a 64-bit significand (and the signifiand ALU makes sense as power-of two) and that you don't need as many bits for exponent (it would be wasteful to go to the next power of two up). Memory is stored as 8-bit bytes as the lowest addressable unit, and so the question would be how many extra bytes the number should take, and 80 bits is a nice integer number of 10 bytes.
    • kens27 minutes ago
      I've looked at some early calculators and they are a whole different world of weirdness. They used decimal arithmetic (BCD) because it's a lot easier than converting between binary and decimal. The first calculators were serial, with a 1-bit adder and shift registers and bits constantly in motion. The Sinclair Scientific calculator used TI's strange 4-bit architecture along with terrible algorithms.
    • matja2 hours ago
      > Also, the arbitrary "Oh, and the registers are 80 bits wide" is also just one of those weird "Where did that number come from?".

      One of the features that was advertised (mentioned in the iAPX 86, 88, 186 Microprocessors Part II book (July 1984)) was the ability to do exact arithmetic on integers up to 2^64, which is possible due to the 64-bit mantissa used in the 80-bit format.

      • mortjaan hour ago
        So in a sense the 8087 was the first 64 bit CPU?
        • matjaan hour ago
          I wouldn't say so, because it was a co-processor: e.g., it depended on the 8086 to even generate addresses for memory operations.

          I think the IBM 7030 Stretch CPU (from 1964) would be a likely contender for being one of the first 64-bit CPUs.

        • kens30 minutes ago
          The Cray-1 (1976) was probably the first 64-bit CPU.
          • kragen28 minutes ago
            https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_t... names Stretch from 01961 as the first natively 64-bit CPU, but maybe there are some that are even older?
            • kens22 minutes ago
              I forgot about the IBM 7030 Stretch (1961), which was also 64 bits. The NORC (Naval Ordnance Research Calculator) (1954) had 16 decimal digits, which is sort of 64 bits.
  • kens3 hours ago
    Author here for your 8087 questions...
    • pechay12 minutes ago
      Great work! I love to read your articles.

      I'm curious to know - you say Intel's 8087 emulation code was a bit of a lump at 16KB, do you know if it emulated the 8087 microcode state machine or did it use a different strategy?

      • kens6 minutes ago
        I think the emulation code was a rewrite in 8086 assembly language. An 8087 microcode emulator would be slow and difficult. One of the Opcode Collective people is looking at the emulator now, so there may be more details later. Intel claimed that the emulator completely and exactly duplicated the 8087 functionality, so it would be interesting to see if it is 100% accurate or if they missed any corner cases.
    • bonzinian hour ago
      That's a really vertical microcode. It looks more like a specialized assembly than microcode. I guess it makes sense, since the algorithms are so complex and executing one microinstruction per cycle (is that correct?) already provides almost an order of magnitude performance improvement.
      • kens20 minutes ago
        Yes, it's one microinstruction per cycle, except there is a 1-cycle delay for branches, adds, and shifts. And some micro-instructions loop, so they can take a bunch of cycles.
    • agumonkey7 minutes ago
      no questions, just thanks
    • 2 hours ago
      undefined