由于基本內聯匯編功能太薄弱了，所以才對它進行了擴展以使其功能強大。不過，易用性往往與功能強弱是成正比的，如您所料，擴展內聯匯編確實有點難，但在求知欲的驅使下，就讓咱們痛并快樂著吧。

gcc本身是個c編譯器，要讓其支持匯編語言，必然牽扯到以下問題：

• 在內聯匯編代碼插入點之前的c代碼，其編譯后也要被分配寄存器等資源，插入的匯編代碼也要使用寄存器，這是否會造成資源沖突？
• 匯編語言如何訪問c代碼中的變量？

您看，內聯匯編真不是簡單地寫兩句匯編代碼就完事了，所以，很多同學寧可單獨寫純匯編文件再鏈接，也不愿意寫內聯匯編，也許您現在還不服，一會可就說不準嘍^_^。

咱們從頭分析，假設目前沒有擴展內聯匯編：

當匯編代碼嵌入到c代碼中，如果匯編代碼想把c代碼中的變量做為操作數加載到寄存器，如何找到可用的寄存器，這可是個大問題，程序員并不知道哪個寄存器已經被分配了，哪些寄存器是空閑的。即使知道了寄存器的分配情況也還不夠，有些底層操作，對寄存器的要求是固定的（比如in/out指令，就得使用al做為數據寄存器），萬一那個固定的寄存器已經被占用了，咱們在使用前還得把它備份。

也許您覺得，這些問題不難啊，我不管之前用了哪些寄存器，我在內聯匯編中用哪些寄存器時就先將其入棧備份，用完了再恢復唄。聽上去不錯，但由用戶來保證數據完整性簡直就是災難，人的精力是有限的，誰知道會不會漏掉哪個寄存器呢，而且在出了問題后也不容易查出來。再說，運行中有大量的壓棧操作，訪問內存本身就比較慢，不如在編譯階段由編譯器優化，直接分配給寄存器或用寄存器緩存，這樣程序運行才更快。所以，這類事情還是交給編譯器自己做這事才放心。

既然編譯器對咱們不放心，那么現在的問題變成了如何將c代碼中的變量變成匯編代碼中的操作數，由于編譯器無法預測用戶的需求，這些只得讓用戶控制，故編譯器采取的做法是，它提供一個模板，讓用戶在模板中提出要求，其余工作由它負責實現。這些用戶提出的要求，就是后面所說的約束。

總結

以上是生活随笔為你收集整理的一步步编写操作系统80 扩展内联汇编1的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。