注：本文转自http://hyry.dip.jp/blogt.py?file=0135.blog

在CCS的build options中的linker选项卡中，Autoinit Model有两个选项：Run-Time Autoinitialization和Load-Time Initialization。本文简单介绍一下这两个选项的区别和用法。

因为这两个选项和.cinit和.bss Section有关，所以先简单的介绍一下这两个section相关的知识。从C语言的角度来看的话，.bss section是用来存放C语言中的全局变量的。而.cinit则用来存放全局变量的初始值。例如如果有下面的全局变量buf的话，

那么buf放在.bss中，而初始值0x01, 0x02, 0x03, 0x04放在.cinit中。.cinit中储存的实际上是一个copy table，它对于每个需要初始化的全局变量，都有一个复制项与之对应，以55x系为例，上面的这段程序产生的复制项为：

00 04 00 12 34 00 00 01 00 02 00 03 00 04 
----- ----------- ------------------------ 
  1        2                    3      

1. 复制的word数
2. 复制的目标地址，也就是buf的地址(这里假设为0x1234)
3. 要复制的数据，也就是初始化数据0x01, 0x02, 0x03, 0x04

那么对于这个.cinit中的copy table具体由谁来完成复制操作呢，这样就有了Load-Time和Run-Time的这两个选择。

先来看看Run-Time Autoinitialization。这段英文的的意思是“运行时初始化”，实际上就是在main函数之前被运行的c_int00中的一段代码完成这个复制工作。我们知道c_int00是用来初始化C语言程序运行所需要的环境的，这个初始化的一部分就是初始化全局变量的初始值。因此在c_int00中初始化全局变量是理所当然的。

然而这样做存在一个问题：.cinit中的copy table只在c_int00中用一次，如果把它放在dsp的on chip RAM中的话，实在是太浪费了。因此通常的做法是将.cinit放到flash内存中。假设系统没有flash内存，而是采用的serial boot之类的启动方式，由别的芯片通过McBSP将DSP的程序传输到DSP中的话，我们就不得不把.cinit放到RAM中了。如果初始化数据很多的话，显然是非常浪费内存的。为了解决这个问题，可以采用Load-Time Initialization。

所谓Load-Time Initialization，就是在将程序load进DSP内存的同时，初始化.bss中的全局变量。我们以55x系列的serial boot为例来解释一下Load-Time Initialization。out文件的格式比较复杂，所以通常都是先通过hex5x工具将out文件转化为一个boot table格式的文件，然后通过DSP ROM中的boot程序接收并分析这个boot table完成各个section的初始化工作，最后跳转到c_int00运行。boot table的格式和.cinit中的copy table类似，都有复制个数，目标地址以及需要复制的数据。例如下图是hex5x产生的boot table的格式。

DSP ROM中的serial boot程序一边接收这个boot table的数据一边将数据复制到相应的地址中去。因此如果能将.cinit中的copy table转换到boot table中去的话，就不需要在c_int00中对.cinit进行操作了，也就不需要额外的内存用来储存.cinit了。只要选择了Load-Time Initialization选项，这个工作就都由计算机自动完成了。我们来看看它具体是如何做的。

当以Load-Time Initialization方式对项目进行link的时候，linker会在输出的out文件中的.cinit的section header中添加一个STYP_COPY标签。这个标签会改变hex5x工具对这个section的操作。也就是说当hex5x发现某个section header中有STYP_COPY标签的话，它就把这个section中的数据当作copy table一项一项添加到boot table中去了。因此最终产生的boot table不是将整个.cinit复制到DSP的内存中，而是将.cinit中的每个复制项复制到.bss相应的位置。这样就在boot load的同时完成了全局变量的初始化工作。