複雜指令集在安卓上註定沒有用武之地嗎？

01-21

也就是問。intel手機在三星和高通手機面前都是渣嗎？

這個問題很好回答。

x86是否為純CISC：首先，糾正一點，x86已經不是當年那個純純的CISC，我記得在P6開始後端就加入了RISC思想的一些東西，現在Haswell也是融合了RISC的微指令。

說個題外話：現在還在討論CISC和RISC是有些low的；討論CISC和RISC誰強誰弱是更low；認為x86比ARM強很多或者ARM比x86強很多是最最最low的事情。

DEC和Intel以及ARM那些事：其次，計算所的胡偉武不說過一句特別有道理的話么：當年技術上超過Intel的都死了。為什麼都死了呢？技術么？DEC當年在技術上可是力壓Intel（當然，其中也跟Intel把x86過於複雜化導致那段時間以CISC為主的Intel在技術上不行）很簡單，他們敗於Intel的生態，而不是技術——ARM則是一個成功的「商人」看準了嵌入式移動領域的發展後在移動端建立了自己的生態，現在手機/遙控器/平板等等這些消費級的嵌入式移動端領域很多也都是ARM，尤其是手機上無論是ARM自家的cortex-A系列，還是Apple的Swift、Cyclone，或者是高通的krait都是ARM的指令集。那麼Apple、高通是因為技術達不到才會用ARM指令集么？

當！然！不！是！

指令集的地位：指令集是CPU當中比較low的東西，很多人把它看的太重，某些民科或者所謂發燒友還有外行認為指令集大於一切，他們會用很多筆墨來渲染對於指令集的重要性，然而實際上這比認為x86比ARM強很多的那些人還要low的多~ 圈內人99%的都知道指令集在整個CPU結構設計中處於一個什麼樣的地位——是基礎但不是決定性因素——優秀的指令設計可以減小微結構實現的功耗和提高性能，這是實現方式的問題，正因為它基礎，所以他才決定了後面的設計的方方面面。正因為如此，它並不是決定性因素，主要的決定性因素還是微結構、工藝以及電路的實現

再重新說回這個問題，其實指令集的技術含量並不高，很多人也都認為指令集難設計，其實不然——CPU真正難的個人覺得在於微結構設計上的「權衡」和「側重」，真正的微結構設計師之間的差距不在於能背多少基礎知識，而是在於如何把書本上的東西實現於現實並且在「權衡」或者「側重」下做出來的比別人更加優秀。當然，我不是做IC後端製造的，不太清楚深亞米工藝技術的實現是有多難。（嗯？貌似有點跑題）

回到正題上：那為什麼Apple和高通不去發展自己的指令集？

生！態！環！境！

重新設計指令集並且實以民用的難題：假如Apple自己設計了一個指令集，性能比x86或者ARM本身強出50%（非擴展指令集下這已經是驚天地泣鬼神的指令集層結構提升了）那Apple也得考慮用不用它。為什麼？因為重新用指令集的話現階段來說Apple需要從頭到尾，從硬體到軟體全部替換掉，os、編譯器、工具鏈等都需要重新做，還有就是需要程序員為其重新做或者兼容，這項工程是浩大的（不替換硬要兼容？那隻能二進位翻譯了，二進位翻譯又要損失性能還有其他的開銷等問題。不過據說二進位翻譯做的極好+對程序員透明的話就可以完成程序遷移，這個貌似是破布大叔說的，具體我不是很清楚~）

總結：上面其實已經說的很明白了，以一種全新的指令集結構融入或者替換掉已經根深蒂固打下良好基礎的指令集結構這是難如登天，即便是擁有自己獨立生態圈並且有一定號召力的Apple也不敢輕易嘗試——還記得大明湖畔那個安騰么？兩巨頭（Intel+HP）聯手搞出來的東西想要在當初指令集體系上再去創建一個新的指令集體系，即便是這樣的巨頭也無可奈何（當然，安騰的失敗還有來源於技術性上的）

所以啊，如今Intel要進軍如今的手機市場其實面對的不是高通、Exynos或者Apple的技術挑戰，它最大的敵人來源於一個龐大的ARM生態，這個是Intel現階段沒辦法從根本上解決的（據說安卓5.0後安裝app時採用安裝編譯，貌似是安裝過程中變為編譯語言，不知道有沒有用？畢竟軟體層是我軟肋）

至於技術上嘛，我覺得Intel還是比較有實力的，但無奈，面對一個早已建立的體系想要兼容或者再創建一個指令集體系我想要麼是號召力極大+不麻煩重新編譯做os之類；要麼就是技術上突破了兼容的障礙

大概就說這麼多了，其實今天說的東西我覺得更多是商業性上的話題，而不是更多在於技術性上的。所以，我也沒像往常拽那麼多英文術語。回答中可能有點疏漏或者錯誤的地方，歡迎指出來~

ps：個人感覺現階段Intel進軍如今ARM手機市場就好比讓中國人接受歪果仁那套關於Sexual culture的思想一樣——一樣的困難●﹏●

我前段時間買了個3735的android板，流暢度甩同價位的arm板好幾條街好么。

CISC出現的機緣是因為最早的軟體開發人員基本都從事過電路設計，當年的軟硬不分家，軟體人員想實現個複雜運算直接想到的就是用硬體造出來，然後加條指令。這樣做最終導致了硬體的崩潰。這樣發生的第一個改變是在硬體中加入了微碼引擎，然後把執行單元拆成一系列更為通用的微操作單元，指令在微碼引擎中拆成一系列微操作。當年的奔騰系列用過P5和P6兩套架構，其中P5就沒有加微碼引擎，最後讓一個大學教授發現了浮點單元一個bug，導致intel緊急召回，然後推出了加入微碼引擎的P6。這個可以認為是硬體設計人員給指令集設計發出了一個警告：不能再隨著你們性子亂搞了，我現在就固化這麼多單元，指令怎麼設計要兼容我的硬體資源，你們發揮的空間就是在微碼引擎裡面。微碼引擎的問題在於要比之前的指令解碼更為複雜，所以在P6架構中解碼佔用了兩級流水。但是任性的軟體人員仗著微引擎和摩爾定律，依舊不斷地將指令集設計的五花八門，最終導致流水越來越長，工作頻率越來越高，而隨之帶來的效應就是流水效率的降低。