《30天自制操做系統》筆記2 --- 初步瞭解彙編產生的二進制（Day1） Notepad++自動刷新文本

nask.exe應該就是nas kit(nas開發工具的意思)，因爲這個編譯器是做者本身寫的，因此這種彙編語言應該是做者改造出來的，因此我叫它nas彙編語言。

做者說nask是模仿nasm語法的，關於nasm：Linux 彙編器：對比 GAS 和 NASM

 

前言

本文標題雖爲二進制，但其實通常你們都看十六進制 ，由於每4位二進制（4bits）就對應一位十六進制數(hex)，如

　　

做者也這樣說：爲了方便清晰地表示二進制，咱們用十六進制來看

　　若是計算進制有困難，可使用在線工具或Excel，字符轉16進制的也能夠本身在網上搜索一下。

 

---

 

 

開始編寫nas

首先 咱們對nas彙編語言的 RESB       DB      DW(WORD)      DD(DWORD)很陌生，因此應該瞭解一下

另外簡記一下大小順序：     BWD不玩刀

B　　1字節　　8bits

W　　2字節　　16bits

D　　4字節　　32bits

 

先安裝Nodepad++以及它16進制查看器插件：新版Notepad++加十六進制查看的插件HexEditor

而後咱們在01_day下建幾個nas文件並寫入內容，如

上面是文件名，下面是內容
固然若是你喜歡命令行，能夠文本替換三個換行後用echo 重定向快速寫入文本文件

test-RESB.nas
    RESB 9



testDB_hex.nas
    DB 0x3e



testDB_char.nas
    DB "Hello"



testDB_dec.nas
    DB 3



test-DW.nas
    DW 3



test-DD.nas
    DD 3

 

 

而後逐一手動編譯，以test-DD.nas爲例

把目錄z_tools放到和01_day同一級目錄下，打開cmd執行以下

   ..\z_tools\nask.exe test-DD.nas test-DD.img

固然我寫了個腳本

 1 @ECHO OFF
 2 setlocal enabledelayedexpansion
 3 echo ---find nas----
 4 for /R %cd% %%f in (*.nas) do (
 5     
 6     rem 文件名，無後綴文件名
 7     SET "FILE_PATH_NO_EXT=%%~nxf"
 8     SET "OUTFILE_NO_EXT=%%~nf"
 9 
10     ..\..\z_tools\nask.exe !FILE_PATH_NO_EXT! !OUTFILE_NO_EXT!.img
11 )

View Code

再用nodepad++(View in HEX)查看每一個編譯出來的img的十六進制，這樣咱們就對這幾個nask彙編指令有很清晰的認識了，

以後遇到不清楚的指令，咱們也能夠這麼玩

 而後我發現DD 3和DW 3在我windows系統上是同樣的？？？都是hex(03 00)，

        因爲用的是「小端」的排列方式，因此是hex(0300)而非hex(0003)，關於大端小端，本文底部有說明連接，但仍是推薦你先看完正文。

可是爲何16bits和32bits得出來結果是同樣的？不該該一個03 00一個03 00 00 00嗎

可是DD 512和DW512就不同的了，一個hex(02 00)hex(02)，雖然dec 512的確是hex 200，可是這位數徹底不對啊

？？？算了，繼續看下面的

更多玩法：

開兩個notepad++窗口和一個cmd，一個改，一個編譯，一個看，

能夠啓用實時刷新功能：Notepad++自動刷新文本

（注意：這個實時刷新是須要你點擊窗口時才刷新的，例如你改了test.txt，而test.txt顯示在窗口1，可是此時你在看窗口2，那麼就須要你點擊一下窗口1，這樣纔會刷新。）

 

如下是個人騷操做：

 

25(dec) = 19(hex) 

反向驗證一下

1* 16^1    +    9* 16^0=25

 

---

 

分析nas彙編代碼

一段段來，先複製一小段，分析

 

記下末尾地址（如此處是0xd），而後繼續添加一小段分析

因爲咱們還不知道DW和DD是怎麼回事，因此能夠DW或DD爲分段點

DW 1 ，DB 2這一段我編譯了兩次，第一次是由於看到編譯結果比預想中多了1bits，因此從新編譯了一次，就正常了....結合上面512的例子，因此到底是編譯器的問題仍是Notepad++插件的問題？懵逼中

可能會有人笑我，爲何抱着一本  古老到還在講軟盤卻講不清楚不少細節  的書就不放了呢，還逐個bit去看，

其實我我的以爲應該仔細去看這一部分，由於nask.exe不是全平臺的，可是仔細研究以後，咱們也能夠用其餘的彙編編譯器在各平臺上寫引導區、寫操做系統的

回到DB DW DD，B是8位二進制的，　　2^8=256

DW (WORD)是16bits，因此　　　　　　2^16=65536

DD (DOUBLE-WORD)是32bits，得　　  2^32=4294967296

如今咱們知道了爲何不用DB 512，由於DB是8bits最多擁有256個十進制數，不可能容納512這個數。

而DD，又會不會是由於編譯器的優化讓DD在數不夠大時自動降級爲DW呢？咱們還不清楚，但願後面能找到答案吧。

 

更詳細的圖解

Day1的helloOS.nas前半部分

 

 後半部分（程序主體、信息顯示部分、啓動扇區之外部分輸出）

 

 

從這裏能夠看出只有DB不夠用時纔會用更大容量的DW、DD

可是裏面源碼裏出現了DW 2880和DD 2880

 

因此咱們不由會想，這到底是用法呢？仍是說只是做者爲了標識19行的2880才用了DD（若是是這樣的話，那麼DD在數值只須要16bits時等價於DW？） 

 

怒了，想辦法測試一下：

又對了，那咱們接下來排除一下hex編輯器的問題吧，我把以前出bug 的語句再編譯一次。

 原來是Notepad++插件HexEditor的問題....貌似在文件長度很短的狀況下才有這個bug

 因此DB是寫入1字節，DW是寫入2字節，DD是寫入4字節。 0x01這個地址能容納1個字節，

　　事實證實做者沒騙咱們，而且他考慮的很周到，用不一樣的工具可能會有不同的效果，畢竟bug這東西誰能百分比肯定呢？

　　可是HexEditor確實好用，那我仍是繼續用吧，當心點就行。

 

另外，關於字節序（大端小端）：

詳解大端模式和小端模式 或 http://bdxnote.blog.163.com/blog/static/8444235201091054458112/

[本文已完整，但可能會偶爾補充點什麼]