《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/

[本文已完整，但可能会偶尔补充点什么]