不可否認，這次的標題有點長。之所以把標題寫得這麼詳細，主要是為了搜索引擎能夠准確地把確實需要了解GCC生成16位實模式代碼方法的朋友帶到我的博客。先說一下背景，編寫能在x86實模式下運行的16位代碼，這個話題確實有點復古，所以能找到的資料也相應較少。要運行x86實模式的程序，目前我知道的只有兩種方式，一種是使用DOS系統，另一種是把它寫成引導扇區的代碼，在系統啟動時直接運行。很顯然，許多講自己實現操作系統的書籍都會講到x86實模式，也只有自己實現操作系統引導的朋友需要用到x86實模式，所以我這篇文章的閱讀用戶數肯定很少，雖然我自認為它填補了網上關於該話題相關資料缺乏的空白。因此，凡是逛到我這篇文章的朋友，請點一下推薦，謝謝。
為什麼說我這篇博客填補了相關話題的空白呢？那是因為不管是那些寫書的，還是網上寫文章的，一旦需要編寫16位的實模式代碼，都喜歡拿NASM說事兒，一點也不顧GNU AS的感受。當然，這是有歷史原因的，因為Linux自從其誕生起就是32位，就是多用戶多任務操作系統，所以GCC和Gnu AS一移植到Linux上就是用來編寫32位保護模式的代碼的。而且，ELF可執行文件格式也只有ELF32和ELF64，沒聽說過有ELF16的。即使是Linux自己，剛誕生的時候（1991年），也只有使用as86匯編器來編寫自己的16位啟動代碼，直到1995年以後，GNU AS才逐步加入編寫16位代碼的能力。
下面開始我的GCC和GNU Binutils的16位代碼之旅。我決定使用DOS作為我的測試環境，所以最後生成的可執行文件都把它制作成DOS系統中可運行的Plain Binary格式。第一步安裝一個qemu虛擬機來運行FreeDOS，安裝虛擬機在Ubuntu中只需要一個sudo apt-get install qemu命令就可以完成，所以我就不截圖了。但是FreeDOS的軟盤映像文件需要到Qemu的官網上面去下載，下載地址如下圖：
使用qemu-system-i386 -fda freedos.img可以運行Qemu虛擬機和FreeDOS系統，如下圖：
因為匯編語言更接近底層，而C語言更高級，所以先從匯編語言開始，逐步過渡到C語言。先寫一個簡單的、能在DOS中顯示一個“Hello，world！”的匯編語言程序，考慮到我之後會使用該程序調用C語言的main函數，並且該程序負責讓程序運行結束後順利返回DOS系統，所以我把這個程序命名為test_code16_startup.s。其代碼如下：
下面對以上代碼進行簡單解釋：
1. GNU AS匯編器使用的匯編語言采用的是AT&T語法，該語法和Intel語法不同。我更喜歡AT&T的語法，原因有兩個，一是AT&T語法是Linux世界中通用的標准，二是AT&T語法在某些概念方面確實理解起來更簡單（比如內存尋址模式）。有匯編語言基礎的人，AT&T語法學起來也很快，主要有以下幾條：①匯編指令後面跟有操作數長度的後綴，比如mov指令，如果操作數是8位，則用movb，如果操作數是16位，則用movw，如果操作數是32位，則用movl，如果操作數是64位，則用movq，其余指令依此類推；②操作數的順序是源操作數在前，目標操作數在後，比如movw %cs, %ax表示把cs寄存器中的數據移動到ax寄存器中，這個順序和Intel匯編語法正好相反；③所有的寄存器使用%前綴，如%ax, %di, %esp等；④對於立即數，需要使用$前綴，比如 $4, $0x0c，而且如果一個數字是以0開頭，則是8進制，以其它數字開頭，是10進制，以0x開頭則是16進制，標號當立即數使用時，需要$前綴，比如上面的pushw $message，而標號當函數名使用時，不需要$前綴，比如上面的callw display_str；⑤內存尋址方式，眾所周知，x86尋址方式眾多，什麼直接尋址、間接尋址、基址尋址、基址變址尋址等等讓人眼花缭亂，而AT&T語法對內存尋址方式做了一個很好的統一，其格式為section:displacement(base, index, scale)，其中section是段地址，displacement是位移，base是基址寄存器，index是索引，scale是縮放因子，其計算方式為線性地址=section + displacement + base + index*scale，最重要的是，可以省略以上格式中的一個或多個部分，比如movw 4, %ax就是把內存地址4中的值移動到ax寄存器中，movw 4(%esp), %ax就是把esp+4指向的地址中的值移動到ax寄存器中，依此類推。我上面的介紹是不是全網絡最簡明的AT&T匯編語法教程？
2. 在以上代碼中我全部使用的都是16位的指令，如movw、pushw、callw等，並且直接在代碼中定義了字符串“Hello, world！”。
3. 在以上代碼中使用了函數display_str，在調用display_str之前，我使用pushw $15和pushw $message將參數從右向左依次壓棧，然後使用callw指令調用函數，這和C語言的函數調用約定是一樣的。調用callw指令會自動將%ip寄存器壓棧，而在函數開始時，我又用pushw %bp將%bp寄存器壓棧，所以%esp又向下移動了4個字節，所以在函數中使用0x4(%esp)和0x6(%esp)可以訪問到這兩個參數。在32位代碼中，由於調用函數時壓棧的是%eip和%ebp，所以需要使用0x8(%esp)和0xc(%esp)來依次訪問壓棧的參數。關於匯編語言函數調用的細節，我這裡有一本好書Linux匯編編程指南.pdf。這是一本免費的英文版電子書，其原名為《Programming from the ground up》。
4. 以上代碼使用BIOS中斷int 0x10來輸出字符串，使用DOS中斷int 0x21來返回DOS系統。
5. 最重要的是，需要使用.code16指令讓匯編器將程序匯編成16位的代碼。
代碼完成後，使用下面一串命令就可以把它進行匯編、鏈接，然後轉換成DOS下的純二進制格式（Plain Binary），最後復制到FreeDOS.img中，使用Qemu虛擬機執行FreeDOS，然後運行該16位實模式程序。這一串命令及其運行效果如下圖：
這些命令中比較重要的選項我都特意標出來了。由於我用的是64位的環境，所以調用as命令的時候需要指定--32選項，調用ld命令的時候需要指定-m elf_i386選項。指定以上選項後，生成的是32位的ELF目標文件，否則默認會生成64位的ELF目標文件，如果目標文件是64位，以後和C語言生成的目標文件連接時會出問題。使用32位環境的朋友們不用特意指定這兩個選項。由於DOS系統總是把Plain Binary文件載入到0x100地址處執行，所以調用ld命令時，需要指定-Ttext 0x100選項。ld命令執行完成後，生成的是ELF格式的可執行文件test.elf，最後需要調用objcopy生成純二進制文件，-j .text選項的意思是只需要代碼段，因為我把“Hello, world!”也是定義在代碼段中的，-O binary選項指定輸出格式為純二進制文件，輸出文件為test.com。最後，將freedos.img鏡像文件mount到Ubuntu中，將test.com拷貝到其中，然後umount，然後運行虛擬機，在DOS中運行test，就可以看到效果了。
除了as和ld，GNU Binutils中的其它程序也是寫程序和分析程序時的好幫手。可以使用readelf -S查看test.elf文件中的所有段，也可以使用objdump -s命令將test.elf中的數據以16進制形式輸入，如下圖：
當然，也可以使用objdump -d或者objdump -D將程序進行反匯編，查看是否真正生成了16位代碼，如下圖：（反匯編時一定要指定-m i8086選項）
也可以對純二進制格式的文件進行反匯編，必須指定-b binary選項，如下圖，對test.com進行反匯編：
反匯編時，一定要指定-m i8086選項，否則objdump不知道反匯編的是16位代碼。（前面提到過Linux從誕生起就是32位，所以ELF只有32位和64位兩種，沒有16位的ELF格式。）如下圖，如果使用-m i386選項進行反匯編，反匯編結果將不知所雲：
下面進入C語言的世界。為了搞清楚C語言生成的16位代碼的匯編指令有哪些特別之處，先寫一個簡單的C語言程序進行調研，如下圖：
該程序有以下特點：
1. 程序的開頭使用了__asm__(".code16\n")嵌入匯編指令，以指示as生成16位代碼；
2. display_str函數的簽名和之前匯編語言中的相同，可以使用它來觀察C語言生成的代碼如何傳遞參數。
使用下面的命令對程序進行編譯和反匯編，如下圖：
從上圖可以看出，C語言生成的代碼雖然是16位，但是它有如下特點：①從生成的display_str函數中可以看出，函數一開始是push %ebp，而不是push %bp；②在display_str函數中獲取參數的位置分別為0x8(%ebp)和0xc(%ebp)，而不是我在匯編語言中寫的0x4(%ebp)和0x6(%ebp)；③從生成的main函數可以看出，調用diaplay_str之前，沒有使用push命令把參數壓棧，而是直接通過sub $0x18, %esp調整%esp的位置，然後使用mov指令將參數放到指定位置，和使用push指令的效果相同；④雖然我在display_str函數的定義中故意將長度參數定義為short，但是從生成的代碼中可以看到依然是每隔4個字節放一個參數。
另外需要說明的是，調用gcc時除了指定-c選項指示它只編譯不連接外，還要指定-m32選項，這樣才會生成32位的匯編代碼，而只有在32位的匯編代碼中使用.code16指令，才能編譯成16位的機器碼。如果沒有指定-m32選項，則生成的是64位匯編代碼，然後匯編時會出錯。使用-m32選項後，生成的目標文件是ELF32格式。ELF32格式的目標文件只能和ELF32格式的目標文件連接，這也是為什麼前面的as和ld需要指定--32和-m elf_i386選項的原因。
通過以上分析，似乎可以得出以下結論：只需要將匯編代碼中的pushw %bp更改為pushl %ebp，然後將獲取參數的位置調整為0x8(%ebp)和0xc(%ebp)，就可以從C語言裡面成功調用到匯編語言中的函數了。而事實上，還有一點點小差距。從上面的反匯編代碼中可以看到，函數調用時使用的是16位的call指令，該指令壓棧的是%ip，而不是%eip，而C語言生成的函數框架中獲取的參數位置是按照將%eip壓棧計算出來的，它們之間差了兩個字節。
為了證明我以上判斷的准確性，我將上面的C語言程序和匯編程序修改後，編譯連接成一個完整的程序，看看它究竟能否正確運行。如下圖：
C語言程序修改很簡單，就是去掉了display_str函數的實現，只保留聲明。匯編代碼如下圖：
匯編語言的更改包含以下幾個地方：將display_str函數導出，將pushw %bp改為pushl %ebp，同時修改獲取參數的位置。編譯、連接、運行程序的指令如下：
可以看到“Hello world from C language”沒有正確顯示出來。上面的命令都是前面用過的，不需要多解釋，唯一不同的是使用C語言寫的程序多了一個.rodata段，所以在objcopy的時候需要把這個段也包含進來。
由於Ｃ語言生成的函數框架都是從0x8(%ebp)開始取參數，它認為0x0(%ebp)是old ebp，0x4(%ebp)是%eip，而事實上使用16位的call指令調用函數後，0x4(%ebp)中是%ip而不是%eip，所以要從0x6(%ebp)開始取參數。我們不可能修改C語言生成的函數框架，只能看看能否將16位的call改成32位的call。
辦法當然是有的，那就是不使用.code16，而使用.code16gcc。.code16gcc和.code16不同的地方就在於它生成的匯編代碼在使用到call、ret、jump等指令時，都生成32位的機器碼，相當於calll，retl，jumpl。這也是.code16gcc叫.code16gcc的原因，因為它就是配合GCC生成的函數框架使用的。
下面再來修改代碼，C語言代碼修改很簡單，只需要將.code16改成.code16gcc即可，如下圖：
通過反匯編，可以看到它使用了32位的calll和retl，如下圖：
匯編程序的修改主要是將.code16改為.code16gcc，然後手動將callw改成calll，將retw改成retl，如下圖：
最後，編譯連接，拷貝到freedos.img，運行虛擬機，查看運行效果，如下圖：
大功告成，運行效果如上圖。
總結：編寫運行於x86實模式下的16位代碼是一個很復古的話題，編寫能在DOS下運行的Plain Binary可執行文件是一個更復古的話題。以往，凡是需要使用x86的16位實模式的時候，作者都喜歡用NASM來編程。比如《30天自制操作系統》、《Orange's 一個操作系統的實現》、《x86匯編語言——從實模式到保護模式》等書籍都以NASM匯編器和Intel匯編語法作為示例。而且他們都是在進入32位保護模式後，才讓匯編語言和C語言共同工作。
我用Linux操作系統，所以我就是想不管是寫32位代碼，還是16位代碼，都能使用GCC和GNU AS。我還想即使是在16位模式下，也能盡量少用匯編語言，多用C語言。經過努力，有了上面的文章。使用GCC和GNU Binutils編寫運行於x86實模式的16位代碼的過程如下：
1. 如果只用匯編語言編寫16位程序，請使用.code16指令，並保證只使用16位的指令和寄存器；如果要和C語言一起工作，請使用.code16gcc指令，並且在函數框架中使用pushl，calll，retl，leavel，jmpl，使用0x8(%ebp)開始訪問函數的參數；很顯然，使用C語言和匯編語言混編的程序可以在實模式下運行，但是不能在286之前的真實CPU上運行，因為286之前的CPU還沒有pushl、calll、retl、leavel、jmpl等指令。
2. 使用as時，請指定--32選項，使用gcc時，請指定-m32選項，使用ld時，請指定-m elf_i386選項。如果是反匯編16位代碼，在使用objdump時，請使用-m i8086選項。
3. 在DOS中運行的.com文件會被加載到0x100處執行，所以使用ld連接時需指定-Ttext 0x100選項；引導扇區的代碼會被加載到0x7c00處執行，所以使用ld連接時需指定-Ttext 0x7c00選項。
4. 使用gcc、as、ld生成的程序默認都是ELF格式，而在DOS下運行的.com程序是Plain Binary的，在引導扇區運行的代碼也是Plain Binary的，所以需要使用objcopy將ELF文件中的代碼段和數據段拷貝到一個Plain Binary文件中，使用-O binary選項； Plain Binary文件也可以反匯編，在使用objdump時需指定-b binary選項。