1. 17
  1. 4

    There were a bunch of these x86 clones that had a fairly simple in-order pipeline (occasionally dual-issue). They exist almost entirely as a result of Arm not having a standardised boot process, firmware interface, interrupt controller, or UART. If you made a crappy x86 pipeline, you could boot any general-purpose OS. Competing Arm SoCs needed a custom port of a load of bits of Linux / *BSD / whatever. If you didn’t need much by way of OS services from your appliance, you could just use FreeDOS and a FAT filesystem on a Compact Flash card. If you wanted something a bit more programmer-friendly, you could just grab Linux / *BSD and the off-the-shelf releases would Just Work.

    It took a long time for Arm to get to the point of supporting a single kernel binary for most SoCs. MIPS never reached that point. PowerPC tried to standardise things and ended up with two incompatible standards where people picked one and kind-of implemented it. RISC-V seems to be gradually converging on a standard boot process (though with some SoCs targeting something different).

    If anyone wanted to produce something with a similar target today (and hadn’t already invested in x86), I’d imagine that they’d implement a modest RISC-V core, rather than x86.

    1. 2

      I wouldn’t forget about the big advantages of:

      • being able to reuse/port your existing say, DOS application (Many embedded applications in the 90s were done as DOS or even Windows. If you want a good example, the OmniShare makes a good case study.)
      • being able to test on the same architecture (no cross-compiling) from the workstation