寫了硬件的發展史之后，屬于歷史，那么我們也要展望一下未來的可能性。所以就有了今天這一篇。我們知道硬件的設計需求是根據具體使用場景的遇到的痛點，然后可能會提出新的需求。

我們也會發現各個架構有一定的趨同性，無論是x86還是arm也在相互學習，x86學習arm的低功耗，arm也想提高性能。所以精簡指令和復雜指令不再那么純粹。各種總線也在相互借鑒，比如都有內存分頁，除了寄存器定義不同，宏觀上的分頁結構基本是一致的。所以好的東西都在用，這樣對軟件也有一個好處，硬件形態的設計規范，會使得軟件的移植性更好。

除了一些特定使用場景的硬件設計，我們普遍希望的是提高處理速度。我們以服務器使用場景為例子，來一些可能已經存在的猜測，然后我們再展望一下未來處理器（光子計算機和量子計算機等）的形態對于編程的影響

先說可能存在的猜想。我們說過服務器為了提高吞吐量，是分布式的，提高穩定性支持內存，cpu的熱插拔等。那么為了提高性能。

在一個服務器主板上可能是怎樣的呢？是單個操作系統還是多個操作系統呢？對于同構的處理器可以是單個系統。對于異構的只能是多個系統。假設猜測是多操作系統之間的配合協調。實際也有可能是一個分布式的操作系統。單系統。但是不影響我們說明問題。

我們假設我們訪問百度，百度不可能只有一個機房，一個機房不可能只有一個服務器。這些從百度的網址找到具體的服務器（通常肯定是多個，然后負載均衡）。我們就假設找到了一個服務器，然后這個服務器的形態是怎樣的會好呢。我們猜測的硬件形態如下圖：

注意這里的cpu1，2，3表示的不是core，而是一顆多核心的cpu。由于我們假設是多系統的，那么我們就假設這幾個cpu都跑linux，系統在各自cpu的local memory里面。然后global memory是每個cpu都可以訪問的。這樣這幾個cpu之間就可以通過共享內存來通信，至于gloabl memory里面是什么結構來組織的實現共享內存通信，這個是實現問題。假設global里面有一個內存數據庫。這樣相當于多個cpu使用了一個內存數據庫。或者是一個內存文件系統，那么多個cpu之間共享了一個文件系統。或者更簡單的一些消息通信機制，比如就是個類似ringbuffer的東西，這樣cpu之間可以根據定義的ringbuffer的結構通信。

服務器重要的是什么一個是速度，還有一個是數據的備份，保存，數據庫之類的。數據庫有內存數據庫redis，還有磁盤數據庫mysql之類的。所以最終的數據都要進入磁盤。所以這個就有一個矛盾并發和互斥訪問的矛盾。為了速度我們在不斷的提高并發的可能，提高單個核心的速度，但是對于同一個數據庫，同一個總線，同一塊內存，同一個磁盤的訪問總會互斥，有些是硬件上要支持的互斥，有些是軟件保證的互斥。所以就要考慮盡量減少互斥的范圍。

目前的情況是我們的cpu的兩個核心，訪問內存的時候，是互斥訪問的，因為是同一個總線。那么有沒有這樣一種可能，如下圖：

如上圖我們兩顆cpu訪問同一內存條假設20G，那么紅色的部分就要保證互斥訪問，訪問者，要先獲得總線所有權，然后訪問釋放。對于整個20G的地址空間都要互斥。這樣互斥的共享空間限制太大了20個G。由硬件保證在微觀上兩個cpu訪問內存條是互斥訪問的。

那么我做一個猜想有沒有這樣一種memory，比如可以提供2，4，8個通道，這樣多個cpu使用不同的通道，只要訪問地址不同，就在硬件上，不會爭奪總線。或者難以實現的話，我們弱化一些，每4K為一個地址范圍。比如這20G的地址空間是0-20G，那么假設一個cpu訪問的地址是0《addr《4K，如果另外一個cpu也訪問這個內存條，那么如果地址范圍也在0-4K那么就要總線互斥，但是如果訪問的是4k-8k，那么就可以不需要總線互斥，在微觀上，硬件上確實做到一定程度的并發訪問。猜測的可能的硬件形態如下圖：

如上圖，cpu1通過紅色的總線訪問這個內存條，cpu2通過綠色的總線訪問這個內存條，內存條出廠的時候有一個判斷電路，看紅色和綠色的地址是否4K空間沖突。如果不沖突，那么可以微觀上完全并發，如果沖突，那么就只能互斥訪問。

異構內存文件系統 ：可能沒有這個概念，是我臆造的，不知道是否存在。

我們的總線上有多顆cpu，每顆都有自己的系統，但是我們的memory里面可以有一個內存文件系統，我把它叫做異構共享文件系統，兩顆cpu都可以訪問，并且兩個cpu里面可以跑不同的系統，也不要求是同一種硬件架構。如下圖：

前面的一些屬于一些合理猜測或者臆造，不知道是否存在，也許還真的已經存在。

接下來我們說光子計算機和量子計算機。有一段時間炒作的很火，我們不說炒作嫌疑，畢竟無論什么行業剛開始都會有夸大炒作。但是只要發展方向是對的遲早實現，就是時間問題。

光子計算機低功耗，速度快，量子計算機更是速度快。那么假設這些最終都實現了，那么編程的形態會不會變化？我們現在學習的編程語言，編程思想，整個軟件生態還能不能用？

我認為對于軟件生態是一個機會，可能c語言，java語言等等各種編程語言還能用，也許會有新的語言出來。新的系統出來。這個對于整個軟件生態都是機會。新的計算形態完全沒有必要整個將老的推翻。而是適配向上兼容。

也許新的計算機表示信息不再是2進制，都不好說，但是我們的高級語言是通過編譯器編譯的。對于語言不需要知道計算機信息表示是幾進制。這個通過編譯工具鏈掩蓋了。

所以新的針對光子處理器，量子形態的處理器會出現對應的編譯工具鏈。向上兼容現有的軟件生態（語言，系統，工具），也許不完全兼容，但是大部分兼容。我們在量子計算機和光子計算機上運行我們原來在傳統計算機上的程序，我們不需要知道底層是光子計算機還是量子計算機。就像我們寫的程序。我們用不同的工具鏈編譯運行。我們不需要知道是x86的還是arm的一樣。這就是向上兼容。通過編譯工具來翻譯。加上光子計算機和量子計算機的速度的極大提升，會出現新的針對這么高速度的的操作系統，新的軟件生態的擴充，而不是消滅老的。對于軟件來說反而是機會。也許會出現新的針對該種計算機的新的編程語言，但是完全不會消滅老的語言。新的應用場景會出現，同樣對于應用編程者也是機會。