例程 contextSwitch()实际上是被调度程序凋用，而调度程序又在那此终止中断的tb系统调用中被调用，因此它不一定在这里终止中断。此外，由于调用调度程序的操作系统调用是用高级语言写的，所以大部分运行任务的寄存器已经被保存到它自己当地的栈中了。这减少了例程saveContext()和restoreContext()需要做的工作。它们只需要关心指令指针，栈指针以及标志位的保存。例程 contextSwitch()的实际行为是很难仅仅通过看前面的代码来理解的。大部分的软件开发者以连续的方式思考问题，认为每一行代码会紧接着上一条代码破执行。然而，这个代码实际为并行地执行了两次。当一个任务（新任务）转变到运行状态，另一个（旧任务）必须同时返回到就绪状态。想一下新任务当它在restoreContext()代码中被恢复的时候就会明白。无论新任务以前做什么，它在saveContext 代码里总是醒着的——因为这就是它的指令存放的地方。新任务如何知道它是否是第一次（也就是，在准备休眠的过程）或者是第二次（醒来的过程）从saveContext()中出来的呢？它确实需要知道这个差别，因此我不得不用一种有点隐蔽的方法来实现saveContext()。例程saveContext()不是保存了准确的目前的指令指针。实际上是保存了一些指令前面的地址。那样，当保存的设备场景恢复的时候，程序从saveContext 中另一个下同的点继续。这也使得saveContext 可能返回不同的值：当任务要休眠的时候为非零，当任务唤起的时候为零。例程contextSwitch()利用这个返回的值来决定是否调用restoreContext()。如果不进行这个检测，那么与这个新任务相关的代码永远不会执行。

我知道这可能是一个复杂的事件序列，因此我在图8-3 中说明了整个的过程。

坦言之，一个操作系统并不是嵌入式或其它计算机系统的必需的组件，它所能做的，也是像时用程序要实现的功能一样。本书中的所有例子都说明了这一点。应用程序执行起来，都是从main 开始，然后进入系统调用、运行、结束。这与系统中只有一个任务是一样的。对于应用程序来说，仅仅是实现使LED 进行闪烁，这就是操作系统的主要功用（屏蔽了很多复杂的操作）。

如果你以前没作过对操作系统的研究，那么，在这里得提醒一下，操作系统是非常复杂的。tb操作系统的厂商肯定是想使你相信，他们是唯一能生产出功能强大又易用的操作系统的科学家。但是，我也要告诉你：这并不是根困难的。实际上嵌入式操作系统要比桌面操作系统更容易编写，所需的模块和功能更为小巧、更易于实现。一旦明确了要实现了功能，并有一定的实现技能，你将会发现，开发一个操作系统并不比开发嵌入式软件艰难多少。

嵌入式操作系统很小，因为它可以缺少很多桌面操作系统的功能。例如，嵌入式操什系统很少有硬盘或图形界面，因此，嵌入式操作系统可以下需要文件系统和图形用户接口。而且，一般来说，是单用户系统，所以多用户操作系统的安全特性也可以省去了。上面所说的各种性能，都可以作为嵌入式操作系统的一部分，但不是必须的。

我们将要讨论的这个应用程序不比其他大部分tb编程书籍中找到的“Hello，World”例子更复杂。它是对于嵌入式软件开发的一个实证，因此这个例子是出现在书的结尾而不是开始。我们不得不逐渐地建立我们的道路通向大部分书籍甚至是高级语言编译器认为是理所当然的计算平台。

一旦你能写“Hello, World”程序，你的嵌入式平台就开始着上去很像任何其他编程环境。但是，嵌入式软件开发过程中最困难的部分——使自己熟悉硬件，为它建立一个软件开发的过程，连接到具体的硬件设备——还在后面呢。最后，你能够把你的力量集中于算法和用户界面，这是由你要开发的产品来确定的。很多情况下，这些程序的高级方面可以在其他的计算机平台上开发，和我们一直在讨论的低级的嵌入式软件开发同时进行，并且只要把高级部分导入嵌入式系统一次，两者就都完成了。

图 9-1 包含了一个“Hello, World!”应用程序的高级的示意图。这个应用程序包括三个设备驱动程序，ADEOS 操作系统和两个ADEOS 任务。第一个任务以每秒10Hz 的速度切换Arcom 板上的红色指示灯。第二个每隔10 秒钟向主机或是连接到位子串口上的哑终端发送字符串“Hello，WOrld！”。这两个任务之外，图中还有三个设备的驱动程序。这些驱动程序分别控制着Arcom 板子的指示灯、时钟以及串行端口。虽然通常把设备驱动画在操作系统的下面，但是我把它们三个和操作系统放在同一个级别，是为了着重说明它们事实上依赖于ADEOS 比ADEOS 依赖于它们更多。实际上，ADEOS 嵌入式操作系统甚至不知道（或者说下关心）这些设备驱动是否存在于系统之中。这是嵌入式操作系统中设备驱动程序和其他硬件专用软件的共性。

程序 main()的实现如下所示。这段代码简单地创造厂两个任务，tb启动了操作系统的日程表。在这样一个高的级别上，代码的含义是不言而喻的。事实上、我们已经在上一章中讨论了类似的代码。

#include "adeos.h"
void flashRed(void);
void helloWorld(void);
/*
* Create the two tasks.
*/
Task taskA(flashRed, 150, 512);
Task taskB(helloWorld, 200, 512);
/****************************************************
*
* Function : main()
*
* Description : This function is responsible for starting the ADEOS scheduler
only.
*
* Notes :
*
* Returns : This function will never return!
*
****************************************************/
void
main(void)
{
os.start();
// This point will never be reached.
} /* main() */

一旦你使用了自动优化，这里有一些关于用手工的办法进一步减少代码大小的技巧。

避免使用标准库例程
为了减少你的程序的大小，你所能做的最好的一件事情就是避免使用大的标准库例程。很多最大的库例程代价昂贵，只是因为它们设法处理所有可能的情况。你自己有可能用更少的代码实现一个子功能。比如，标准C 的库中的spintf例程是出了名的大。这个庞大代码中有相当一部分是位于它所依赖的浮点数处理例程。但是如果你不需要格式化显示浮点数值(%f 或者%d)，那么你可以写你自己的sprintf 的整数专用版本，并且可以节省几千字节的代码空间。实际上，一些标准C 的库(这让我想起Cygnus 的newlib)里恰好包含了这样一个函数，叫作sprintf。

本地字长
每一个处理器都有一个本地字长，并且ANSI C 和C++标准规定数据类型int必须总是对应到那个字长。处理更小或者更大的数据类型有时需要使用附加的机器语言指令。在你的程序中通过尽可能的一致使用int 类型，你也许能够从你的程序中削减宝贵的几百字节。

goto 语句
就像对待全局变量一样，好的软件工程实践规定反对使用这项技术。但是危急的时候，goto 语句可以用来去除复杂的控制结构或者共享一块经常重复的代码。
除了这些技术以外，在前一部分介绍的几种方法可能也会有帮助，特别是查询表、手工编写汇编、寄存器变最以及全局变量。在这些技术之中，利用手工编写汇编通常可以得到代码最大幅度的减少量。

虽然使软件正确的工作好像应该是一个工程合乎逻辑的最后一个步骤，但是在嵌入式的系统的开发中，情况并不总是这样的。出于对低价系列产品的需要，硬件的设计者需要提供刚好足够的存储器和完成工作的处理能力。当然，在工程的软件开发阶段，使程序正确的工作是很重要的。为此，通常需要一个或者更多的开发电路板，有的有附加的存贮器，有的有更快的处理器，有的两者都有。这些电路板就是用来使软件正确工作的。而工程的最后阶段则变成了对代码进行优化。最后一步的目标是使得工作程序在一个廉价的硬件平台上运行。

提高代码的效率
所有现代的 C 和C++编译器都提供了一定程度上的代码优化。然而，大部分由编译器执行的优化技术仅涉及执行速度和代码大小的一个平衡。你的程序能够变得更快或者更小，但是不可能又变快又变小。事实上，在其中一个方面的提高就会对另一方面产生负面的影响。哪一方面的提高对于程序更加的重要是由程序员来决定。知道这一点后，无论什么时候遇到速度与大小的矛盾，编译器的优化阶段就会作出合适的选择。

因为你不可能让编译器为你同时做两种类型的优化，我建议你让它尽其所能的减少程序的大小。执行的速度通常只对于某些有时间限制或者是频繁执行的代码段是重要的。而且你可以通过手工的办法做很多事以提高这些代码段的效率。然而，手工改变代码大小是一件很难的事情，而且编译器处于一个更有利的位置，使得它可以在你所有的软件模块之间进行这种改变。

直到你的程序工作起来，你可能已经知道或者是非常的清楚，哪一个子程序或者模块对于整体代码效率是最关键的。中断服务例程、高优先级的任务、有实时限制的计算、计算密集型或者频繁调用的函数都是候选对象。有一个叫作profiler 的工具，它包括在一些软件开发工具组中，这个工具可以用来把你的视线集中到那些程序花费大部分时间(或者很多时间)的例程上去。
一旦你确定了需要更高代码效率的例程，可以运用下面的一种或者多种技术来减少它们的执行时间。

inline 函数
在 c++中，关键字inline 可以被加入到任何函数的声明。这个关键字请求编译器用函数内部的代码替换所有对于指出的函数的调用。这样做删去了和实际函数调用相关的时间开销，这种做法在inline 函数频繁调用并且只包含几行代码的时候是最有效的。

inline 函数提供了一个很好的例子，它说明了有时执行的速度和代码的太小是如何反向关联的。重复的加入内联代码会增加你的程序的大小，增加的大小和函数调用的次数成正比。而且，很明显，如果函数越大，程序大小增加得越明显。优化后的程序运行的更快了，但是现在需要更多的ROM。

查询表
switch 语句是一个普通的编程技术，使用时需要注意。每一个由tb机器语言实现的测试和跳转仅仅是为了决定下一步要做什么工作，就把宝贵的处理器时间耗尽了。为了提高速度，设法把具体的情况按照它们发生的相对频率排序。换句话说，把最可能发生的情况放在第一，最不可能的情况放在最后。这样会减少平均的执行时间，但是在最差情况下根本没有改善。

如果每一个情况下都有许多的工作要做，那么也许把整个switch 语句用一个指向函数指针的表替换含更加有效。比如，下面的程序段是一个待改善的候选对象：

enum NodeType {NodeA, NodeB, NodeC}
switch(getNodeType())
{
case NodeA:
...
case NodeB:
...
case NodeC:
...
}
为了提高速度，我们要用下面的代码替换这个switch 语句。这段代码的第一部分是准备工作：一个函数指针数组的创建。第二部分是用更有效的一行语句替换switch 语句。

int processNodeA(void);
int processNodeB(void);
int processNodeC(void);
/*
* Establishment of a table of pointers to functions.
*/
int (* nodeFunctions[])() = { processNodeA, processNodeB, processNodeC };
...
/*
* The entire switch statement is replaced by the next line.
*/
status = nodeFunctions[getNodeType()]();

手工编写汇编
一些软件模块最好是用汇编语言来写。这使得程序员有机会把程序尽可能变得有效率。尽管大部分的C/C++编译器产生的机器代码比一个一般水平的程序员编写的机器代码要好的多，但是对于一个给定的函数，一个好的程序员仍然可能做得比一般水平的编译器要好。比如，在我职业生涯的早期，我用C 实现了一个数字滤波器，把它作为TI TMS320C30 数字信号处理器的输出目标。当时我们有的tb编译器也许是不知道，也许是不能利用一个特殊的指令，该指令准确地执行了我需要的那个数学操作。我用功能相同的内联汇编指令手工地替换了一段C 语言的循环，这样我就能够把整个计算时间降低了十分之一以上。

寄存器变量
在声明局部变量的时候可以使用 register 关键字。这就使得编译器把变量放入一个多用选的寄存器，而不是堆栈里。合适地使用这种方珐，它会为编译器提供关于最经常访问变量的提示，会稍微提高函数的执行速度。函数调用得越是频繁，这样的改变就越是可能提高代码的速度。

全局变量
使用全局变量比向函数传递参数更加有效率。这样做去除了函数调用前参数入栈和函数完成后参数出栈的需要。实际上，任何子程序最有效率的实现是根本没有参数。然而，决定使用全局变量对程序也可能有一些负作用。软件工程人士通常不鼓励使用全局变量，努力促进模块化和重入目标，这些也是重要的考虑。

轮询
中断服务例程经常用来提高程序的效率。然而，也有少数例子由于过度和中断关联而造成实际上效率低下。在这些情况中，中断间的平均时间和中断的等待时间具有相同量级。这种情况下，利用轮询与硬件设备通信可能会更好。当然，这也会使软件的模块更少。

定点运算
除非你的目标平台包含一个浮点运算的协处理器，否则你会费很大的劲去操纵你程序中的浮点数据。编译器提供的浮点库包含了一组模仿浮点运算协处理器指令组的子程序。很多这种函数要花费比它们的整数运算函数更长的执行时间，并且也可能是不可重入的。

如果你只是利用浮点数进行少量的运算，那么可能只利用定点运算来实现它更好。虽然只是明白如何做到这一点就够困难的了，但是理论上用定点运算实现任何浮点计算都是可能的。(那就是所谓的浮点软件库。)你最大的有利条件是，你可能不必只是为了实现一个或者两个计算而实现整个IEEE 754 标准。如果真的需要那种类型的完整功能，别离开编译器的浮点库，去寻找其他加速你程序的方法吧。

不论是C、C++对于内存对齐的问题在原理上是一致的，对齐的原因和表现，简单总结一下，以便朋友们共享。

一、内存对齐的原因
大部分的参考资料都是如是说的：
1、平台原因(移植原因)：不是所有的硬件平台都能访问任意地址上的任意数据的；某些硬件平台只能在某些地址处取某些特定类型的数据，否则抛出硬件异常。
2、性能原因：数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。

   也有的朋友说，内存对齐出于对读取的效率和数据的安全的考虑，我觉得也有一定的道理。

二、对齐规则
    每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。比如32位windows平台下，VC默认是按照8bytes对齐的(VC->Project->settings->c/c++->Code Generation中的truct member alignment 值默认是8)，程序员可以通过预编译命令#pragma pack(n)，n=1,2,4,8,16来改变这一系数，其中的n就是你要指定的“对齐系数”。

    在嵌入式环境下，对齐往往与数据类型有关，特别是C编译器对缺省的结构成员自然对届条件为“N字节对 齐”，N即该成员数据类型的长度。如int型成员的自然对界条件为4字节对齐，而double类型的结构成员的自然对界条件为8字节对齐。若该成员的起始 偏移不位于该成员的“默认自然对界条件”上，则在前一个节面后面添加适当个数的空字节。C编译器缺省的结构整体的自然对界条件为：该结构所有成员中要求的 最大自然对界条件。若结构体各成员长度之和不为“结构整体自然对界条件的整数倍，则在最后一个成员后填充空字节。

    那么可以得到如下的小结:

类型 对齐方式（变量存放的起始地址相对于结构的起始地址的偏移量）
Char    偏移量必须为sizeof(char)即1的倍数
Short   偏移量必须为sizeof(short)即2的倍数
int     偏移量必须为sizeof(int)即4的倍数
float   偏移量必须为sizeof(float)即4的倍数
double  偏移量必须为sizeof(double)即8的倍数

   各成员变量在存放的时候根据在结构中出现的顺序依次申请空间，同时按照上面的对齐方式调整位置，空缺的字节编译器会自动填充。同时为了确保结构的大小为结 构的字节边界数（即该结构中占用最大空间的类型所占用的字节数）的倍数，所以在为最后一个成员变量申请空间后，还会根据需要自动填充空缺的字节,也就是 说：结构体的总大小为结构体最宽基本类型成员大小的整数倍，如有需要编译器会在最末一个成员之后加上填充字节。对于char数组，字节宽度仍然认为为1。

   对于下述的一个结构体，其对齐方式为：

struct Node1{

    double m1;
    char m2；
    int m3;
};

  对于第一个变量m1，sizeof(double)=8个字节；接下来为第二个成员m2分配空间，这时下一个可以分配的地址对于结构的起始地址的偏移量为8，是sizeof(char)的倍数，所以把m2存放在偏移量为8的地方满足对齐方式，该成员变量占用 sizeof(char)=1个字节；接下来为第三个成员m3分配空间，这时下一个可以分配的地址对于结构的起始地址的偏移量为9，不是sizeof (int)=4的倍数，为了满足对齐方式对偏移量的约束问题，自动填充3个字节（这三个字节没有放什么东西），这时下一个可以分配的地址对于结构的起始地址的偏移量为12，刚好是sizeof(int), 由于8+4+4 = 16恰好是结构体中最大空间类型double(8)的倍数，所以sizeof(Node1) =16.

typedef struct{

    char a;

    int b;

    char c;

}Node2;

    成员a占一个字节，所以a放在了第1位的位置；由于第二个变量b占4个字节，为保证起始位置是4(sizeof(b))的倍数，所以需要在a后面填充3个 字节，也就是b放在了从第5位到第8位的位置，然后就是c放在了9的位置，此时4+4+1=9。接下来考虑字节边界数，9并不是最大空间类型int(4) 的倍数，应该取大于9且是4的的最小整数12，所以sizeof(Node2) = 12.
typedef struct{

    char a;

    char b;

    int c;

}Node3;

   明显地：sizeof(Node3) = 8

   对于结构体A中包含结构体B的情况，将结构体A中的结构体成员B中的最宽的数据类型作为该结构体成员B的数据宽度，同时结构体成员B必须满足上述对齐的规定。

   要注意在VC中有一个对齐系数的概念，若设置了对齐系数，那么上述描述的对齐方式，则不适合。

   例如：

1字节对齐(#pragma pack(1))
输出结果：sizeof(struct test_t) = 8 [两个编译器输出一致]
分析过程：
成员数据对齐
#pragma pack(1)
struct test_t {
    int a;
    char b;
    short c;
    char d;
};
#pragma pack()
成员总大小=8；

2字节对齐(#pragma pack(2))
输出结果：sizeof(struct test_t) = 10 [两个编译器输出一致]
分析过程：
成员数据对齐
#pragma pack(2)
struct test_t {
    int a;
    char b;
    short c;
    char d;
};
#pragma pack()
成员总大小=9；

4字节对齐(#pragma pack(4))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(4)
struct test_t { //按几对齐， 偏移量为后边第一个取模为零的。
int a;
char b;
short c;
char d;
};
#pragma pack()
成员总大小=9；

8字节对齐(#pragma pack(8))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
成员数据对齐
#pragma pack(8)
struct test_t {
int a;
char b;
short c;
char d;
};
#pragma pack()
成员总大小=9；

16字节对齐(#pragma pack(16))
输出结果：sizeof(struct test_t) = 12 [两个编译器输出一致]
分析过程：
1) 成员数据对齐
#pragma pack(16)
struct test_t {
int a;
char b;
short c;
char d;
};
#pragma pack()
成员总大小=9；

至于8字节对齐和16字节对齐，我觉得这两个例子取得不好，没有太大的参考意义。

(x666f)

理想上：如何客户企图使用某个接口缺没有获得他所预期的行为，这个代码不该通过编译；如果代码通过了编译，他的行为就该是客户所想要的。

1. 导入外覆类型（wrapper types）

2. 让types容易被正确使用，不容易被误用。尽量领你的types行为与内置types一致。

3. 设计class犹如设计type

新type的对象应该如何被创建和销毁？（自己设计operatornew，operatornew[],operator delete和operator delete[])

对象的初始化和对象的复制该有什么样的差别?对应于不同的函数调用

新type的对象如果被passed by value ，意味着什么

什么是新type的“合法值”？（？？）

你的新type需要配合某个继承图系吗？

你的心type需要什么样的转换

什么样的操作符合函数对此新type而言是合理的

什么样的标准函数应该驳回

谁该取用新type的成员

什么是新type的未声明接口

你的新type有多么一般化

你真的需要一个新type吗

一、宁以pass-by-reference-to-const 替换 pass-by-value

1.tbw效率高，没有任何构造函数或析构函数被调用，因为没有任何新对象被创建。

2. by refrenece方式传递参数还可以避免对象slicing 问题

二、必须返回对象时，别妄想返回其reference

所有用上static对象的设计，会造成多线程安全性的怀疑。

三、将成员变量声明为private：

1. 可以实现出“不准访问”、“只读访问”、“读写访问”、“惟写访问”

2. 封装：它使我们能够改变事物而只影响有限客户。

将成员变量隐藏在函数接口的背后，可以为“所有可能的实现”提供弹性。如：tb变量被读或被写时通知其他对象、可以验证class的约束条件以及函数的前提和事后转帖；以及在多线程环境执行同步控制。。。。等。

四、宁以non-member、non-friend替换member函数

namespace WebBrowserStuff{ 
        class WebBrowser{...}; 
        void clearBrowser(WebBrowser& wb); 
} 

五、若所有参数皆需要类型转换，请为此采用non-member函数

class Rational { 
... 
} 
 
const Rational operator*(const Rational& lhs,const Rational& rhs) 
{ 
 return Rational( lhs.numerator()* rhs.numerator()
,lhs.denominator()*rhs.denominator() ); 
} 
 
Rational oneFourth（1，4）； 
Rational result； 
result = oneFourth * 2; 
result = 2*oneFourth; 

 六、考虑写出一个不抛异常的swap函数

不幸的是，如果按照这个标准来说，嵌入式系统可能是程序员工作中碰到的最难的计算机平台了。甚至在某些嵌入式系统中，根本无法实现“Hello，World!”程序。即使在那些可以实现这个程序的嵌入式系统里面，文本字符串的输出也更像是目标的一部分而不是开始的一部分。

你看，“Hello，World!”示例隐含的假设，就是有一个可以打印字符串的输出设备。通常使用的是用户显示器上的一个窗口来完成这个功能。但是大多数的嵌入式系统并没有一个显示器或者类似的输出设备。即使是对那些有显示器的系统，通常也需要用一小段嵌入式程序，通过调用显示驱动程序来实现这个功能。这对一个嵌入式编程者来说绝对是一个相当具有挑战性的开端。

看起来我们还是最好以一个小的，容易实现并且高度可移植的联人式程序来开始，这样的tb程序也不太会有编程错误。归根到底，我这本书继续选用“Hello，World!”。这个例子的原因是，实现这个程序实在太简单了。这起码在读者的程序第一次就运行不起来的时候，会去掉一个可能的原因，即：错误不是因为代码里的缺陷：相反，问题出在开发工具或者创建可执行程序的过程里面。

嵌人式程序员在很大程度上必须要依靠自己的力量来工作。在开始一个新项目的时候，除了他所熟悉的编程语言的语法，他必须首先假定什么东西都没有运转起来，甚至连标准库都没有，就是类似printf()和scanf()的那些程序员常常依赖的辅助函数。实际上，库例程常常作为编程语言的基本语法出现。可是这部分标准很难支持所有可能的计算平台，并且常常被嵌入式系统编译器的制造商们所忽略。

所以在这一章里你实际上将找不到一个真正的”Hello，World!”程序，相反，我们假定在第一个例子中只可以使用最基本的C 语言语法。随着本书的进一步深人，我们会逐步向我们的指令系统里添加C++的语法、标准库例程和一个等效的字符输出设备。然后，在第九章“综合所学的知识”里面。我们才最终实现一个“Hello，World!”程序。到那时候你将顺利地走上成为一个嵌入式系统编程专家的道路。