為什麼是根據指令集設計 CPU，而不是根據 CPU 架構設計指令集？
有點出乎意料。
我一直以為應該是先有基本的CPU的框架，再在cpu框架上設計各種指令集。
但是，我看到很多文章都是先有一套指令集，然後再設計cpu來配合這套指令集。
為什麼會呢？
另外，如果是指令集在先，那麼是不是意味著：
1、我們可以在arm上去實現x86、riscv的指令集？
2、理論上誰都可以造一份指令集出來？cpu的開發就是個體力活了？
3、如果指令集有bug怎麼辦？
ARM，x86，這種可以叫做架構，
ARMv7，ARMv8，x86，amd64，AVX這種可以叫指令集，
A52，A72，skylake，zen這種可以叫微架構。
所以第一個問題你是想用一個指令集去實現另一個指令集？當然可以啦， 中間加一層二進位轉換，surface pro x用ARM跑windows不就是嘛。
當然你想問的可能是用ARM處理器的微架構（硬體）去跑x86的指令集？那就不行了，指令集和微架構是相輔相成的，難以剝離的。
第二個問題，造指令集，理論上是誰都可以造。但CPU開發卻不是體力活那麼簡單。
當然你按體力活的方法去搭硬體也不是不可以，只不過從性能上說就不好看了。更重要的是如果你指令集設計得太不合理或者難度太高的話就GG了。
先有指令集再造硬體的說法是合理的，就像軟體開發要先定需求，寫開發文檔再寫代碼一樣。
當然很多在職碼農也會反駁說自己公司是邊寫代碼邊寫文檔，或者寫了代碼沒有文檔，但這樣就很難團隊間合作了咯。而造CPU硬體本身的難度通常是大於普通中小軟體開發的，牽一髮而動全身。
第三個問題，指令集本身複雜度是會很高，但限定了規則的話其實還沒那麼容易出錯的。
但相比之下微架構設計這種硬體層面的東西才更複雜，更容易出錯。現在CPU出bug很多啊，比如Intel就經常要發微碼去更新填補漏洞，再比如TSX指令集的硬體設計也是兩次出bug被禁用到現在。還比如spectre這樣的漏洞，就很難補。
換句話說，指令集本身只是規定了什麼對外可見，什麼操作對外提供，哪些要求限制依賴需要滿足。事實上微架構的重要性可以說比指令性更高，能發揮的餘地也更大。
比如x86這麼多年了，本質上沒做太大修改，但底下硬體明明已經翻天覆地面目全非了。
指令集算是介面，微架構是內部實現。介面出bug是大問題，而內部實現更加複雜，出bug就尋常多了。
至於你說的，先造好CPU硬體再在基礎上設計指令集……但是指令集一改，硬體或多或少也要跟著改，流片不要錢的嘛……
不過大家這時候可能會上FPGA搞設計和驗證，這也算是變相符合了你說的做法吧。
well，事實上，是同時進行的。
通常，人們談到CPU的指令集，是指x86，ARM這些。然而，實際上CPU真正在執行的時候，（大部分）並非是直接執行這些指令。
學過CPU微架構的話，應該知道CPU的指令隊列連接著一個解碼器。這個解碼器就是將上面的指令集翻譯成CPU真正的操作碼，通常稱為（OP）。
因為外部的指令集決定了上層軟體環境，如果自造一套指令集，則等於拋棄了從編譯器到網頁腳本這整個現存的軟體環境，除非是軍事醫療等特別領域，對於通用領域來說這等於自己挖坑，對於CPU的設計來說是致命的。
然而另外一方面，CPU要實現省電、高性能等要求，指令集如果一成不變，則會對CPU當中的數字電路設計形成很大制約。況且，還有複雜的專利保護等問題。所以，當今CPU多數內部有另外一套本地的操作碼，但是對於外部則以通用指令集公開。這樣在保證兼容性的同時，可以對CPU內部的設計進行很多優化升級，並且容易繞開其它公司的專利，形成自己的核心技術。
至於非x86架構的CPU執行x86的指令集，這是完全可以（雖然有一定限制）並且實際上這樣的產品過去存在過。比如索尼的PCG-U3：
這貨採用的CPU其實是128bit的非x86 CPU。但是其CPU內部有個軟體，可以將最多4條x86命令拼接成一條128bit的命令來執行。
當時這樣設計的初衷是為了降頻，從而省電。（理論上，因為一次可以執行4條x86命令，那麼只要1/4的頻率就可以達到同等性能）。但是實際上，命令的轉換需要額外的開銷，且命令當中有跳轉，並非永遠都會執行連續的4條命令，以及，x86命令為變長命令等問題，這個CPU的實際性能很爛。在U3之後，據我所知再沒有人採用這個CPU，廠商也早關門成為了歷史了。
（當然這個機子最大的問題還不是CPU，而是它搭載的1寸機械硬碟。看清楚，是1寸，當時是絕無僅有，現在估計也是。。。。）
至於ARM跑x86，除開虛擬機這種不算，因為ARM是固定長指令集而x86是變長指令集，這個比較難了。
好問題。你可以認為指令集是硬體模塊的介面。先定介面再設計其實是比較常規的思路，無論是不是CPU。甚至設計軟體也會這麼搞。而且指令集不只是介面，還是CPU的完整功能的定義。沒需求文檔沒法開發。
當然實際上是迭代著來的，從最初的一些簡單功能慢慢發展起來。去看看MIPS的wiki頁面，你會看到很多版本。x86也是一樣，隨著計算機硬體成本的降低，擴充到了x64。不過迫於歷史原因甚至還背負著以前16位機的一些包袱。
下面回答問題：
1、我們可以在arm上去實現x86、riscv的指令集？
可以。用軟體實現就是虛擬機。用硬體實現……那就不叫arm了
2、理論上誰都可以造一份指令集出來？cpu的開發就是個體力活了？
是的。問題是需要有人買你的帳。而且你不能抄別人的指令集。你的指令集也需要有人給開發編譯器。
3、如果指令集有bug怎麼辦？
改，雖然廠商很不願意。這點在硬體迭代的歷史過程中應該是有的，硬體更新了之後老的指令集出了問題。我記得x86就有過這種經歷(具體例子忘了)
本人主做編譯兼做一些架構。雖然主要是DSP而不是CPU，但大的方向是一致的，所以泛泛而談一下。
我認為你這話是不對的，或者你的理解可能有問題。正確理解應該是，先有處理器的ISA (Instruction Set Architecture)，然後基於ISA做微架構設計。
從名字可以看出來，ISA主要分成兩個部分指令集(Instruction Set)和架構(Architecture)。
我想誤會可能來源於這兩部分通常寫在一個文檔裏，而很多時候文檔名也並不是ISA，而是Instruction Set Manual或者Instruction Specification等等，再加上這篇文檔通常篇幅最長最為人關注的還是指令集部分。所以，我們經常會叫某架構的ISA文檔為某架構的指令集文檔。
但不管怎麼稱呼，一個架構首先需要定義的是ISA，包含Architecture(處理器結構，模塊劃分，data path，寄存器，內存，pipeline等)和Instruction Set(指令定義，使用的說明，約束等)。而這兩者是相輔相承不大可能獨立存在的。 (RISCV比較特殊，因為它定義基本指令集，而依架構而變的部分多依賴於自己擴展，這裡提一下不展開了)
尤其指令集的定義是依賴架構定義的。
例如，TI的C64+ DSP是分簇式的，每一簇多個FU共用一個general register file。而CEVA DSP則是各個FU(GCU, PCU, DAAU, etc)有自己專有的register file。顯然，TI DSP我們不需要設計指令進行FU之間的register transfer，但需要考慮簇與簇之間的register transfer。而CEVA DSP則需要定義指令進行不同register file之間的transfer。
反過來指令集的定義也會影響架構定義。
還是以TI舉例，TI C64+ DSP一簇有4個FU對應一個32-bits general register file，那麼4個FU可能需要同時寫這個register file，並且.L, .M, .S FU都可以做 32-bits op 32-bits = 64-bits運算，所以4個FU需要8個讀，7-8個寫，如果只有一個register file，顯然連線非常複雜。但因為register是32-bits，實際上每次寫64-bits都會寫入兩個連續的register。
於是register可以變成下面這樣，我們把一個register file分成odd和even兩個register file，把每個FU的dst也分成odd和even，這樣單個register file的寫口就少了很多。read也是類似的，但這樣又反過來使指令的讀受到了限制，比如一cycle內並發的不同指令總共只能有4個對一個寄存器的讀操作，顯然也是因為8個讀口分別在odd, even寄存器上的原因。
PS: TI C64+ DSP的register file沒有上述這麼簡單，我只是抽取其中一部分來說明，事實上不同FU的策略也有不同，還要考慮不同簇間register file的cross path等。
指令集就是人有30多顆牙齒
200多塊骨骼
一個肛門
這些通過進化變味時代的標準
指令集這是不斷地進化
進化也是需要時間的
架構可以理解為不同的國家
社會形態，法律，制度等
兩個是共同進化的
推薦閱讀：
