工作这么长时间，一直在C语言这一层面上钻研和打拼，日积月累，很多关于C的疑惑在书本和资料中都难以找到答案。程序员是追求完美的一个种群，其头脑中哪怕是存在一点点的思维黑洞都会让其坐卧不宁。不久前在itput论坛上偶得《Computer Systems A Programmer's Perspective》（以下称CSAPP）这本经典好书，遂连夜拜读以求解惑。虽说书中没有能正面的回答我的一些疑惑，但是它却为我指明了一条通向“无惑”之路 — 这就是打开汇编之门。

汇编语言是一门非常接近机器语言的语言，其语句与机器指令之间的对应关系更加简单和清晰。打开汇编之门不仅仅能解除高级语言给你带来的疑惑，它更能让你更加的理解现代计算机的运行体系，还有一点更加重要的是它给你带来的是一种自信的感觉，减少了你在高处摇摇欲坠的恐惧，响应了侯捷老师的“勿在浮沙筑高台”的号召。现在学习汇编的目的已与以前大大不同了。正如CS.APP中所说那样“程序员学习汇编的需求随着时间的推移也发生了变化，开始时是要求程序员能直接用汇编编写程序，现在则是要求能够阅读和理解优化编译器产生的代码”。能阅读和理解，这也恰恰是我的需求和目标。

在大学时接触过汇编，主要是Microsoft MASM宏汇编，不过那时的认识高度不够加上态度不端正，错失了一个很好的学习机会。现在绝大部分时间是使用GCC在Unix系列平台上工作，选择汇编语言当然是GNU汇编了，恰好CS.APP中使用的也是GNU的汇编语法。由于学习汇编的主要目的还是“解惑”，所以形式上多是以C代码和汇编代码的比较。

1、汇编让你看到更多
随着你使用的语言的层次的提高，你眼中的计算机将会越来越模糊，你的关注点也越来越远离语言本身而靠近另一端“问题域”，比如通过JAVA，你更多看到的是其虚拟机，而看不到真实的计算机；通过C，你看到的也仅仅是内存一层；到了汇编语言，你就可以深入到寄存器一层自由发挥了。汇编程序员眼里的“独特风景”包括：
a) “程序计数器(%eip)” — 一个特殊寄存器，其中永远存储下一条将要执行的指令的地址；
b) 整数寄存器 — 共8个，分别是%eax、%ebx、%ecx、%edx、%esi、%ebi、%esp和%ebp，它们可以存整数数据，可以存地址，也可以记录程序状态等。早期每个寄存器都有其特殊的用途，现在由于像linux这样的平台多采用“平面寻址[1]”，寄存器的特殊性已经不那么明显了。
c) 条件标志寄存器 — 保存最近执行的算术指令的状态信息，用来实现控制流中的条件变化。
d) 浮点数寄存器 — 顾名思义，用来存放浮点数。
虽说寄存器的特殊性程度已经弱化，但是实际上每个编译器在使用这些寄存器时还是遵循一定的规则的，以后再说。

2、初窥汇编
下面是一个简单的C函数：
void dummy() {
 int a = 1234;
 int b = a;
}
我们使用gcc加-S选项将之转换成汇编代码如下(省略部分内容)：
 movl $1234, -4(%ebp)
 movl -4(%ebp), %eax
 movl %eax, -8(%ebp)
看了一眼又一眼，还是看不懂，只是发现些熟悉的内容，因为上面提过如%ebp、%eax等。这只是个引子，让我们感性的认识一下汇编的“容貌”。我们一点点地来看。咋看一眼汇编代码长得似乎很相似，没错，汇编代码就是一条一条的“指令+操作数”的语句的集合。汇编指令是固定的，每条指令都有其固定的用途，而操作数表示则有多种类型。

1) 操作数表示
大部分汇编指令都有一个或多个操作数，包括指令操作中的源和目的。一条标准的指令格式大致是这样的：“指令 + 源操作数 + 目的操作数”，其中源操作数可以是立即数、从寄存器中读出的数或从内存中读出的数；而目的操作数则可以是寄存器或内存。按这么一分类，操作数就大致有三种：
a) 立即数表示法 — 如“movl $1234, -4(%ebp)”中的“$1234”，就是一个立即数作为操作数，按照GNU汇编语法，立即数表示为“$+整数”。立即数常用来表示代码中的一些常数，如上例中的“$1234”。注意一点的是立即数不能作为目的操作数。
b) 寄存器表示法 — 这种比较简单，它就是表示寄存器之内容。如上面的“movl -4(%ebp), %eax”中的%eax就是使用寄存器表示法作源操作数，而“movl %eax, -8(%ebp)”中的%eax则是使用寄存器表示法作目的操作数。
c) 内存引用表示法 — 计算出的该操作数的值表示的是相应的内存地址。汇编指令根据这个内存地址访问相应的内存位置。如上例“movl -4(%ebp), %eax”中的“-4(%ebp)”,其表示的内存地址为(%ebp寄存器中的内容-4)得到的值。

2) 数据传送指令
汇编语言中最最常用的指令 — 数据传送指令，也是我们接触的第一种类别的汇编指令。其指令的格式为：“mov 源操作数, 目的操作数”。
mov系列支持从最小一个字节到最大双字的访问与传送。其中movb用来传送一字节信息，movw用来传送二字节，即一个字的信息，movl用来传送双字信息。这些不详说了。除此以外mov系列还提供两个带位扩展的指令movsbl和movzbl，我们举个例子来说明一下这两个特殊指令的作用何在：

a) movzbl指令
void dummy1() {
 unsigned char c = 'a';
 unsigned int a = c;
}
其对应的GNU汇编为(省略部分内容)：
 movb $97, -1(%ebp)   //'a'的ASCII码为97
 movzbl -1(%ebp), %eax
 movl %eax, -8(%ebp)
说明：在dummy1函数中“unsigned int a = c”语句完成的是一个从unsigned char到unsigned int的赋值操作，由于int的类型长度大于char类型长度，所以实际是将一个字节的内容拷贝到一个可以容纳4个字节的地方，这样的话需要对源数据进行一下扩展，即填充高位的3个字节。

如何填充呢？由于变量a和c都为无符号整型，所以只需要填充0即可。而movzbl就是干这个活的。movzbl指令负责拷贝一个字节，并用0填充其目的操作数中的其余各位，这种扩展方式叫“零扩展”。

b) movsbl指令
void dummy2() {
 signed char c = 'a';
 unsigned int a = c;
}

其对应的GNU汇编为(省略部分内容)：
 movb $97, -1(%ebp)   //'a'的ASCII码为97
 movsbl -1(%ebp), %eax
 movl %eax, -8(%ebp)
说明：在dummy2函数中“unsigned int a = c”语句完成的是一个从signed char到unsigned int的赋值操作，由于int的类型长度大于char类型长度，所以实际是将一个字节的内容拷贝到一个可以容纳4个字节的地方，这样的话需要对源数据进行一下扩展，即填充高位的3个字节。如何填充呢？GNU汇编告诉我们它使用了变量c的最高位来填充其余的3个字节。movsbl指令负责拷贝一个字节，并用源操作数的最高位填充其目的操作数中的其余各位，这种扩展方式叫“符号扩展”。实际上dummy2中变量a还是保留了变量c的符号位的，起码GCC是这么做的。

c) 在CS.APP中pushl和popl也别归入“数据传送指令”类别，但对于刚入门选手这两个指令还是稍显复杂，在以后谈到“procedure”时再细说。

3、小结
已经迈出了踏入汇编之门的第一步，汇编的确让我眼前敞亮了许多，看得多了，知道得多了，疑惑也就少了。

4、参考资料
1) 《Computer Systems A Programmer's Perspective》

[注1]
平面寻址：简单的将存储器看成一个大的、按照字节寻址的数组。不区分类型、符号、地址还是整数。注意汇编程序员看到也是进程空间的虚拟地址。

Tony : Hey Alex, How are you doing?
Alex : 不怎么样。(显得很消沉的样子)
Tony : Oh , Really ? What is the matter?
Alex : 事情是这样的。最近有一个Unix下的C++项目要求我独自完成，以前都是跟着别人做，现在让自己独立完成，还真是不知道该怎么办，就连一个最简单的项目的Makefile都搞不定。昨晚看了一晚上资料也没有什么头绪。唉！！
Tony : 别急，我曾经有一段时间研究过一些关于Makefile的东西，也许能帮得上忙，来，我们一起来设计这个项目的Makefile。
Alex : So it is a deal。(一言为定)
Tony : 我们现在就开始吧，给我拿把椅子过来。

(Tony坐在Alex电脑的旁边)
Tony : 把你的项目情况大概给我讲讲吧。
Alex : No Problem ! 这是一个“半成品”项目，也就是说我将提供一个开发框架供应用开发人员使用，一个类似MFC的东西。
Tony : 继续。
Alex : 我现在头脑中的项目目录结构是这样的：

APL (Alex's Programming Library)
 -Make.properties
 -Makefile(1)
 -include  //存放头文件
  -Module1_1.h
  -Module1_2.h
  -Module2_1.h
  -Module2_2.h
 -src   //存放源文件
  -Makefile(2)
  -module1
   -Module1_1.cpp
   -Module1_2.cpp
   -Makefile(3)
  -module2
   -Module2_1.cpp
   -Module2_2.cpp
   -Makefile(3)
  -…
  
 -lib  //存放该Project依赖的库文件,型如libxxx.a
 -dist  //存放该Project编译连接后的库文件libapl.a
 -examples  //存放使用该“半成品”搭建的例子应用的源程序
  Makefile(4)
  -appdemo1
   -Makefile(5)
   -src  //存放应用源代码
   -include
   -bin  //存放应用可执行程序
  -appdemo2
   -Makefile(5)
   -src  //存放应用源代码
   -include
   -bin  //存放应用可执行程序
  -…

Tony : I got it!
Alex : 下面我们该如何做呢？
Tony : 我们来分析一下各个Makefile的作用。你来分析一下各个级别目录下的Makefile的作用是什么呢？
Alex : (思考了一会儿)我想应该是这样的吧。
 Makefile(3)负责将其module下的.cpp源文件编译为同名.o文件，同时其phony target "clean"负责删除该目录下的所有.o文件;
 Makefile(2)负责调用src目录下所有module的Makefile文件。
 Makefile(1)负责先调用src中的Makefile生成静态库文件，然后调用examples中的Makefile构建基于该框架的应用。
 至于Make.properties，定义通用的目录信息变量、编译器参数变量和通用的依赖关系。

Tony : 说得很好。我们一点一点来，先从src中每个module下的Makefile着手，就如你所说在每个module下的Makefile负责将该module下的.cpp文件编译为同名的.o文件。
Alex : 好的，我来写吧，这个我还是能搞定的。看下面：
module1下的Makefile如下：

#
# Makefile for module1
#
all : Module1_1.o Module1_2.o

Module1_1.o : Module1_1.cpp
 g++ -c $^ -I ../../include
Module1_2.o : Module1_2.cpp
 g++ -c $^ -I ../../include

clean :
 rm -f *.o

module2下的Makefile如下：

#
# Makefile for module2
#
all : Module2_1.o Module2_2.o

Module2_1.o : Module2_1.cpp
 g++ -c $^ -I ../../include
Module2_2.o : Module2_2.cpp
 g++ -c $^ -I ../../include

clean :
 rm -f *.o

make一下，顺利产生相应的.o文件。

/*=============================================================
Note: 关于$^、$<和$@的用法说明:
$@ — “$@”表示目标的集合，就像一个数组，“$@”依次取出目标，并执于命令。
$^ — 所有的依赖目标的集合。以空格分隔。如果在依赖目标中有多个重复的，那个这个变量会去除重复的依赖目标，只保留一份。
$< — 依赖目标中的第一个目标名字

举例: Module1_1.o Module1_2.o : Module1_1.cpp Module1_2.cpp
则$@ — Module1_1.o Module1_2.o
$^ — Module1_1.cpp Module1_2.cpp
$< — Module1_1.cpp

==============================================================*/

Tony : Well done! 不过发现什么问题了么？
Alex : 什么问题？
Tony : 存在重复的东西。在重构中我们知道如果两个子类中都定义相同的接口函数，我们会将其pull up到基类中。同样我们可以重构我们的Makefile,把一些重复的东西拿到外层去。
Alex : （似乎略微明白了一些）我想有三处重复：a)查找头文件的路径是重复的; b)g++这个字符串可以用一个变量定义代替 c)编译器的编译参数可以也定义到一个变量中。我知道Make工具支持include一个文件，我们就建立一个公用的文件来存放一些通用的东西吧。
Tony : 没错，Just do it.
Alex : 就按我原先的想法，把这些公共的部分放到Make.properties中吧。

#
# Properties for demo's Makefile
#
MAKEFILE  = Makefile

BASEDIR = $(HOME)/proj/demo

####################
# Directory layout #
####################
SRCDIR = $(BASEDIR)/src
INCLUDEDIR = $(BASEDIR)/include
LIBDIR = $(BASEDIRE)/lib
DISTDIR = $(BASEDIR)/dist

####################
# Compiler options #
#    F_ — FLAG    #
####################
CC = g++

# Compiler search options
F_INCLUDE = -I$(INCLUDEDIR)
F_LIB = -L $(LIBDIR)

CFLAGS =
CPPFLAGS = $(CFLAGS) $(F_INCLUDE)

然后修改一下，各个module中的Makefile文件，以module1为例，修改后如下：
#
# Makefile for module1
#
include ../../Make.properties

all : Module1_1.o Module1_2.o

Module1_1.o : Module1_1.cpp
 $(CC) -c $^ $(CPPFLAGS)
Module1_2.o : Module1_2.cpp
 $(CC) -c $^ $(CPPFLAGS)

clean :
 rm -f *.o

Tony : 其实这两个Makefile中还有一个隐含的重复的地方
Alex : 你是指依赖规则么？
Tony : 嗯，这个依赖规则在src中的各个module中都会用得到的。
Alex : 没错，我也是这么想的，我现在就把这个规则抽取出来，然后你来评审一下。我想利用make工具的传统的“后缀规则”来定义通用依赖规则，我在Make.properties加入下面的变量定义：

####################
# Common depends   #
####################
DEPS = .cpp.o

然后还是以module1为例，修改module1的Makefile后如下：
#
# Makefile for module1
#
include ../../Make.properties

all : Module1_1.o Module1_2.o

$(DEPS):
 $(CC) -c $^ $(CPPFLAGS)

clean :
 rm -f *.o

Tony : 基本满足需求。我们可以进行上一个层次的Makefile的设计了。我们来设计Makefile(2)。Alex，你来回顾一下Makefile(2)的作用。
/*=============================================================
Note: 关于后缀规则的说明
后缀规则中所定义的后缀应该是make 所认识的，如果一个后缀是make 所认识的，那么这个规则就是单后缀规则，而如果两个
连在一起的后缀都被make 所认识，那就是双后缀规则。例如：".c"和".o"都是make 所知道。因而，如果你定义了一个规则是
".c.o"那么其就是双后缀规则，意义就是".c"是源文件的后缀，".o"是目标文件的后缀, ".c.o"意为利用.c文件构造同名.o文件。
==============================================================*/

Alex : No Problem! 正如前面说过的Makefile(2)负责调用src目录下所有module子目录下的Makefile文件，并负责将各个module下的.o文件打包为libdemo.a文件放到dist目录中。所以存在简单的依赖关系就是libdemo.a依赖各个module子目录下的.o文件，而前面的Makefile(3)已经帮我们解决了.o文件的生成问题了,即我们只需要逐个在各module子目录下make即可。我的Makefile(2)文件设计如下：
#
# Makefile for src directory
#

include ../Make.properties

TARGET = libdemo.a

####################
#  Subdirs define  #
####################
MODULE1_PATH = module1
MODULE2_PATH = module2
SUBDIRS = $(MODULE1_PATH) $(MODULE2_PATH) 

####################
#  Objects define  #
####################
MODULE1_OBJS = $(MODULE1_PATH)/Module1_1.o $(MODULE1_PATH)/Module1_2.o
MODULE2_OBJS = $(MODULE2_PATH)/Module2_1.o $(MODULE2_PATH)/Module2_2.o
DEMO_OBJS = $(MODULE1_OBJS) $(MODULE2_OBJS)

all : subdirs $(TARGET)
 cp $(TARGET) $(DISTDIR)

subdirs:
 @for i in $(SUBDIRS); do \
  echo    "===>$$i"; \
  (cd $$i &&$(MAKE) -f $(MAKEFILE)) || exit 1; \
  echo    "<===$$i"; \
 done

$(TARGET) : $(DEMO_OBJS)
 ar -r $@ $^

clean:
 @for i in $(SUBDIRS); do \
  echo    "===>$$i"; \
  (cd $$i &&$(MAKE) clean -f $(MAKEFILE)) || exit 1; \
  echo    "<===$$i"; \
 done
 rm -f $(DISTDIR)/$(TARGET)

Tony : Alex你的进步真的是很大，分析问题的能力提高的很快，方法也不错。这个设计的缺点在于一旦新增了一个module子目录，这个Makefile文件就需要改动，不过改起来倒不是很难。有机会可以再想想，使这个Makefile更加通用。

Alex : 我记住了。我们继续么？
Tony : 歇一回吧^_^。

/*=============================================================
Alex and Tony are having a short break.
==============================================================*/

Tony : 你的咖啡味道真不错。
Alex : 这可是朋友从巴西带回来的极品咖啡豆，经过我精心研磨而成的。
Tony : 想不到你在这方面还有研究。
Alex : 呵呵。
Tony : Let's go on 。有了Makefile(2)，后面的工作就轻松多了。
Alex : 现在我的信心也很足，我来设计Makefile(1)，它负责先调用src中的Makefile生成静态库文件，然后调用examples中的Makefile构建基于该框架的应用。我还是按照Makefile(2)的思路走，看我的Makefile(1):

#
# Makefile for whole project
#

include Make.properties

SRC_PATH = src
EXAMPLES_PATH = examples

SUBDIRS = $(SRC_PATH) $(EXAMPLES_PATH) 

all : subdirs
 
subdirs:
 @for i in $(SUBDIRS); do \
  echo    "===>$$i"; \
  (cd $$i && $(MAKE) -f $(MAKEFILE)) || exit 1; \
  echo    "<===$$i"; \
 done

clean:
 @for i in $(SUBDIRS); do \
  echo    "===>$$i"; \
  (cd $$i && $(MAKE) clean -f $(MAKEFILE)) || exit 1; \
  echo    "<===$$i"; \
 done

运行一下，由于examples目录下的Makefile还是空的，所以没有成功。

Tony : 有了前面的经验，相信完成examples目录下的两个Makefile对你来说不成问题。
Alex : I could not agree with you any more(Alex脸上满是笑容)，我来完成它。
每个appdemoX下的Makefile(5)我设计成这样：
#
# Makefile for appdemoX
#
include ../../Make.properties

TARGET = appdemoX
SRC = ./src/appdemoX.cpp

all :
 $(CC) -o $(TARGET) $(SRC) $(CPPFLAGS) -L $(DISTDIR) -ldemo
 mv $(TARGET).exe ./bin

clean :
 rm -f ./src/*.o ./bin/$(TARGET).exe

而examples目录下的Makefile(4)的样子如下：
#
# Makefile for examples directory
#

include ../Make.properties

EXAMPLE1_PATH = appdemo1
EXAMPLE2_PATH = appdemo2

SUBDIRS = $(EXAMPLE1_PATH) $(EXAMPLE2_PATH) 

all : subdirs
 
subdirs:
 @for i in $(SUBDIRS); do \
  echo    "===>$$i"; \
  (cd $$i &&$(MAKE) -f $(MAKEFILE)) || exit 1; \
  echo    "<===$$i"; \
 done

clean:
 @for i in $(SUBDIRS); do \
  echo    "===>$$i"; \
  (cd $$i &&$(MAKE) clean -f $(MAKEFILE)) || exit 1; \
  echo    "<===$$i"; \
 done

Tony : 可以，不知不觉间，我们的工作已经接近尾声，剩下的工作就是细节了，包括编译器参数的细化等。
Alex : 在Makefile(1)中加上install,tar等目标，使用户得到有更多的功能。十分感谢你的指导。
Tony : 那晚上去原味斋吧，想烤鸭了^_^。

/*=============================================================
Note : Makefile常识
a) "=" vs ":="
例子：
C_OPTIONS = $(C_EXTRA_OPTION) -O2
C_EXTRA_OPTION = -g
cfoo: foo.c exam.c
    gcc $(C_OPTIONS) -o $@ $^
=>gcc -g -O2 -o cfoo foo.c exam.c

C_OPTIONS := $(C_EXTRA_OPTION) -O2
C_EXTRA_OPTION = -g
cfoo: foo.c exam.c
    gcc $(C_OPTIONS) -o $@ $^
=>gcc -O2 -o cfoo foo.c exam.c

大家发现不同了，Why? 使用“=”赋值的变量在使用时才被展开，并且每使用一次就会展开一次，其值每次展开的时候有可能是不同的,就如第一个C_OPTION由于在使用时展开，所以C_EXTAR_OPTION定义的位置不影响C_OPTION的值。而使用“:=”进行赋值的变量，则在赋值的时候就被展开，并且仅仅展开一次，从此以后其值将不会发生任何变化，就第二个C_OPTION由于定义时展开所以由于定义时看不到C_EXTAR_OPTION所以值为-02，而不是-g -02。

b) wildcard 函数
在 GNU Make 里有一个叫 'wildcard' 的函数，它有一个参数，功能是展开成一列所有符合由其参数描述的文件名，文件间以空格间隔。你可以像下面所示使用这个命令：SOURCES = $(wildcard *.cpp)   SOURCES = xx.cpp yy.cpp … zz.cpp
==============================================================*/