# Why is a superscalar processor SIMD?

1. In Flynn's taxonomy, a single-core superscalar processor is classified as an SIMD processor (Single Instructions, Multiple Data),

Flynn's taxonomy is based on number of instruction streams and number of data streams.

A superscalar processor can run more than one instructions at a time, so why isn't it MIMD?

If there is a valid reason for a superscalar processor to be SI, then why isn't there a similar reason which makes it single-data (i.e. SISD)?

2. Instruction pipeline also runs more than one instruction at one time. Is it SISD or SIMD?
3. Does "SI $\equiv$ only one CPU core"? Or only one implies the other?

Does "MI $\equiv$ more than one CPU cores"? Or only one implies the other?

Thanks.

• Note that Flynn's taxonomy was created in 1966. It would be naive to think that it would reflect reality in 2018 (or 2015). – gnasher729 Jan 27 '18 at 21:36
• @gnasher729: I hate Flynn. – Kindred Dec 6 '18 at 19:55
• Now wiki says this: In Flynn's taxonomy, a single-core superscalar processor is classified as an SISD processor (Single Instruction stream, Single Data stream) – paulplusx Dec 10 '19 at 18:45

First, Wikipedia is wrong in classifying superscalar processors as SIMD (except as many modern superscalars also support short vector instructions). A superscalar has one instruction stream, i.e., there is conceptually only one current instruction address from which instructions are fetched. However, it also has only one data stream, i.e., it generally does not apply the same instruction to multiple data as a vector processor would. (from "Some Computer Organizations and Their Effectiveness" (Michael J. Flynn, 1972): "The single-instruction stream-multiple-data stream (SIMD), which includes most array processes, including Solomon [2] (Illiac IV).")

Pipelining does not increase the number of instruction streams being processed in parallel; the single stream simply flows through a longer channel as it were.

A single processing core can have multiple instruction streams by using multithreading. (Multithreading cores often present this as virtual cores, i.e., to software each thread appears to have a full core, as a convenience for operating systems, allowing any multiprocessor-capable OS to trivially support multithreading. However, this is not a necessary feature; the MIPS MultiThreading Application Specific Extension, e.g., differentiates between a Virtual Processing Element and a Thread Context.)

More interesting cases would included decoupled access/execute architectures, GPUs which provide some instruction stream divergence, and a traditional ISA that internally (microarchitecturally) uses speculative multithreading.

Decoupled access/execute architectures have two partially independent instruction streams, one performing memory accesses and address calculations, the other performing computation, e.g., see James E. Smith, "Decoupled Access/Execute Computer Architectures" (PDF, so they are not neatly classified as having a single instruction stream but they do not have the extent of independent instruction flow associated with Flynn's Multiple Instruction classifications.

Similarly, some GPUs support some control diverge (different instruction streams applied to different data), which is conceptually similar to applying eager execution (where multiple conditional paths are executed in parallel and only the results of the correct path are committed) to multiple data (where at least one of the data elements unconditionally does follow that execution path). This type of architecture is sometimes called Single Program Multiple Thread or Single Instruction stream Multiple Thread. (Note that GPUs also commonly support more traditional MIMD multithreading.)

Hardware speculative multithreading presents the interface of a single instruction stream, but such uses a microarchitecture that supports multiple partially independent instruction streams. For example, loops might have iterations distributed across multiple threads and function calls might spawn a separate thread while processing continues at the return point (possibly using a predicted return value). Like GPUs and decoupled access/execute, this provides limited independence among instruction streams, but even MIMD programs often have limited independence, synchronizing instruction streams at join points. However, unlike those architectures, hardware speculative multithreading provides a SISD interface to software, so from the programmer's perspective it is SISD while from the hardware perspective it is more like MIMD.

• Thanks. Does "hardware speculative multithreading" in your last paragraph mean the same as "Multithreading" in your third paragraph? – Tim Oct 26 '15 at 21:42
• @Tim No, h.s.m. is transparent to software (excluding timing). The multithreading mentioned in the third paragraph is visible to software: software defines which hardware provided thread does what work (hardware can — and often does — schedule the threads at finer granularity than system software). Software can perform speculative multithreading, but without special hardware features (I think versioned memory was one such feature) it is more difficult to do so productively. – Paul A. Clayton Oct 27 '15 at 2:16