哈哈，就一起討論啊，辨證是讓知識和修為進步的重要方式。

話說回來，其實SuperScalar的觀念是相對Scalar，本質就是為了讓同一Cycle有多個指令都被處理，也就是魔王兄講的ILP，Instruction Level Parallelism，以提昇效率。

而Pipeline本身就是一個偉大發明，它也是和SuperScalar一樣是為了提升ILP，提升的效能增益也最明顯。所以維基百科也有說，SuperScalar很容易被誤解就是等同Pipeline，但其實兩者應該視為不同，因為沒有做Pipeline的CPU還是可以做SuperScalar。反過來說，SuperScalar也不是為了解決Pipeline Stall而產生的。

我舉個SuperScalar的例子，像說我的程式碼編譯後有兩行組合語言指令:

add $c, $a, $b (c = a + b)
lw $d, 64($e) (d = Memory[e+64])

第一行是做加法運算，用到的是主要ALU；第二行是記憶體存取指令，通常好一點的CPU會讓記憶體位址計算的部份也有一顆自己的小ALU，避免去搶主要ALU的資源。

因此以SuperScalar的CPU來說，它在讀指令的階段就會判斷，發現這兩行指令其實是可以同時執行的，不用等第一行add做完，再做第二行lw，這兩行用到的硬體資源是獨立無關的，所以它就會把這兩行指令同時執行。


至於Pipeline的話，做法就會和上述SuperScalar有點不同，但目標是和SuperScalar一模一樣的，就是提升ILP。它的設計哲學就像工廠的流水線，一支iPhone在製造的過程，不必等一支iPhone從頭做到好再做第二支，這樣一堆作業員都在挖鼻孔發呆。而是可以第一個作業員組好主機板後交給下個作業員去組電池，第一個作業員就可以馬上著手下一支iPhone的主機板組裝作業，所以流水線上的每個作業員無時無刻都能爆肝滿檔工作，每個Cycle也能產出一支iPhone。其實Pipeline這個詞也是借引工作流水線而來，把每行組語指令都拆分成很多階段，就能像工廠流水線這樣作業，以前述例子來說，它的設計哲學就可以將每行指令都拆成：

1. Instruction Fetch
2. Instruction Decode
3. Execution
4. Memory
5. Write Back

這就是一個最基本的5階Pipeline，一條流水線上就有這5個作業員。

所以第一行add執行到Instruction Decode時，第二行的lw也可以進入到Instruction Fetch的階段，不用等第一行add做完Write Back，才開始做第二行lw。

因此Pipeline Stall通常只能靠一些方法來解決，就不是SuperScalar能搞定的，實務上常作的解法是Prediction，因為Stall有一些情況，其中兩種叫Data Hazard和Control Hazard，也就是上下幾行指令之間有嚴重相依性，必須等第一行做完，第二行再根據第一行計算結果判斷才能做，所以Pipeline的機制等同廢掉，大家都要等第一行做完。這時Prediction就是冒險先偷偷開始做第二行指令，如果第一行算出來的結果還真的曚到猜對了，那麼第二行以後那些偷跑的執行成果就是賺到了，當然如果猜錯第一行執行結果，後面那些指令都白做，全都重來。