Proposed merge with Simultaneous multithreading

edit

Simultaneous multithreading is a special case of Instruction pipelining where the fetch phase looks ahead and injects multiple instructions with non overlapping resource utilization into the decode-execute pipeline when possible. Ethanpet113 (talk) 08:20, 3 January 2019 (UTC)Reply

no, i think SMT is just Flynn's MISD. maybe. or a minor variant of it. basically what happens is that memory is too quick and even register files are struggling, today, so multiple fetch/decoders share an execute unit and multiplex instructions into them, fanning them back out to their associated "thread". it's kinda like Time-Division Multiplexing. the result is that if you have say 4-way SMT then the register file associated with each thread only needs to cope with 1/4 the speed, which is a big deal. so whilst the processor execution pipelines are running at 4.8 ghz, say, the 4 (separate) register files only need to run at 1.2 ghz, which is a massive saving. Lkcl (talk) 17:40, 4 August 2025 (UTC)Reply

No, it is not simply a special case of instruction pipelining. It isn't just the fetch and decode that are doubled up, many other parts of the pipeline may also have their components doubled up too. Some parts are not doubled, and therefore shared, and some remain single threaded, but not all except the fetch stage.

You can have pipelining with or without SMT and you could have SMT with or without pipelining. You cannot have SMT without the processor being superscalar however.FoxyBuscuits (talk) 10:40, 3 June 2019 (UTC)Reply

yeah i designed a processor which had Finite State Machines instead of pipelines. to "solve" the "problem" of parallelism you simply put down N FSMs, the saving being that the N FSMs were a hell of a lot simpler (less gates) that 1of N-stage pipeline. so rather than Time-Division Multiplexing the pipeline stages between M threads, (N/M) FSMs would be actively working on M threads. what you actually need is not so much superscalar as proper Hazard Management. Lkcl (talk) 17:46, 4 August 2025 (UTC)Reply

Although there are some similarities, those two are quite different techniques. Oppose. --Arny (talk) 13:27, 18 June 2019 (UTC)Reply

Oppose. Should have it's own article. It's a different technology than basic pipelining. Oranjelo100 (talk) 07:10, 19 June 2019 (UTC)Reply

Out of Order Processor Idle Logic

edit

The line "In contrast, out of order computers usually have large amounts of idle logic at any given instant" is on paper often true. However, it is vague and not useful, as the reader will probably assume that this is synonymous with idle execution logic, which is not entirely true. The whole point of OOO processors is that they will keep the ALUS/Multipliers/Dividers/FPUs fed with data by reordering the instructions. The fact that most OOO processors are also superscalar(and so have a tendency to have idle logic when memory bandwidth lmited) is irrelevant to the instruction reordering itself. 2601:246:5900:E790:0:0:0:F1D (talk) 01:41, 22 June 2023 (UTC)Reply

CDC6600 had a 2-stage FP pipeline

edit

mitch alsup told me a few years ago on re-reading thornton's book that he noted the CDC6600 FP pipeline was 2 stage. reason: the cabinet length was so massively long, the connection between racks had to turn round and come back in the opposite direction, and the transistors couldn't switch fast enough. Lkcl (talk) 17:49, 4 August 2025 (UTC)Reply

no actual explanation as to why pilelining exists!

edit

reason is down to transistor switching time, and a VLSI circuit must have chains of transistors, you get a ripple-effect and a buffer line-driver effect, *and* one-to-many driver issues all affecting rise and fall time. if you want to hit a certain time threshold, you must have shorter chains. and that means storing partial results, and ta-daaa you have pipeline stages. Lkcl (talk) 17:59, 4 August 2025 (UTC)Reply