《30天自制操作系统》笔记2 --- 初步了解汇编产生的二进制（Day1）

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 

testDB_hex.nas

    DB 0x3e

testDB_char.nas

    DB "Hello"

testDB_dec.nas

    DB 

test-DW.nas

    DW 

test-DD.nas

    DD

然后逐一手动编译，以test-DD.nas为例

把目录z_tools放到和01_day同一级目录下，打开cmd执行如下

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

当然我写了个脚本

 @ECHO OFF

 setlocal enabledelayedexpansion

 echo ---find nas----

 for /R %cd% %%f in (*.nas) do (

     rem 文件名，无后缀文件名

     SET "FILE_PATH_NO_EXT=%%~nxf"

     SET "OUTFILE_NO_EXT=%%~nf"

     ..\..\z_tools\nask.exe !FILE_PATH_NO_EXT! !OUTFILE_NO_EXT!.img

 )

再用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/

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