隔离编译器

1. 什么是PSOS

pSOS系统结构
pSOS是一个由标准软组件组成的,可剪裁的实时操作系统。其系统结构如图2.1所示

,它分为内核层、系统服务层、用户层。
1. 内核层
pSOS内核负责任务的管理与调度、任务间通信、内存管理、实时时钟管理、中断服

务；可以动态生成或删除任务、内存区、消息队列、信号灯等系统对象；实现了基于优

先级的、选择可抢占的任务调度算法，并提供了可选的时间片轮转调度。pSOS Kernel还

提供了任务建间通信机制及同步、互斥手段，如消息、信号灯、事件、异步信号等。
pSOS操作系统在Kernel层中将与具体硬件有关的操作放在一个模块中,对系统服务层

以上屏蔽了具体的硬件特性,从而使得pSOS很方便地从支持Intel 80x86系列转到支持MC

68XXX系列,并且在系统服务层上对不同应用系统不同用户提供标准的软组件如PNA+、
PHILE+等。
2. 系统服务层
pSOS系统服务层包括PNA+、PRPC+、PHILE+等组件。PNA+实现了完整的基于流的TCP

/IP协议集,并具有良好的实时性能,网络组件内中断屏蔽时间不大于内核模块中断屏蔽时

间。PRPC+提供了远程调用库,支持用户建立一个分布式应用系统。PHILE+提供了文件系

统管理和对块存储设备的管理。PREPC+提供了标准的C、C++库,支持用户使用C、C++语言

编写应用程序。
由于pSOS内核屏蔽了具体的硬件特性,因此,pSOS系统服务层的软组件是标准的、与

硬件无关的。这意味着pSOS各种版本,无论是对80X86系列还是MC68XXX系列,其系统服务

层各组件是标准的、同一的,这减少了软件维护工作,增强了软件可移植性。
每个软组件都包含一系列的系统调用。对用户而言,这些系统调用就象一个个可重入

的C函数,然而它们却是用户进入pSOS内核的唯一手段。
3. 用户层
用户指的是用户编写的应用程序，它们是以任务的形式出现的。任务通过发系统调

用而进入pSOS内核,并为pSOS内核所管理和调度。
pSOS为用户还提供了一个集成式的开发环境（IDE）。pSOS_IDE可驻留于UNIX或DOS

环境下,它包括C和C++优化编译器、CPU和pSOS模拟仿真和DEBUG功能。
pSOS内核机制
§3.1 几个基本概念
3.1.1 任务
在实时操作系统中，任务是参与资源竞争（如CPU、Memory、I/O devices等）
的基本单位。pSOS为每个任务构造了一个虚拟的、隔离的环境，从而在概念上,一个任务

与另一个任务之间可以相互并行、独立地执行。任务与任务之间的切换、任务之间的通

信都是通过发系统调用（在有些情况下是通过ISR）进入pSOS Kernel,由pSOS Kernel完

成的。
pSOS系统中任务包括系统任务和用户任务两类。关于用户任务的划分并没有一个固

定的法则,但很明显,划分太多将导致任务间的切换过于频繁,系统开销太大,划分太少又

会导致实时性和并行性下降,从而影响系统的效率。一般说来,功能模块A与功能模块B是

分开为两个任务还是合为一个任务可以从是否具有时间相关性、优先性、逻辑特性和功

能耦合等几个方面考虑。
3.1.2 优先级
每个任务都有一个优先级。pSOS系统支持0～255级优先级,0级最低,255级最高。0级

专为IDLE任务所有,240～255级为系统所用。在运行时,任务（包括系统任务）的优先级

可以通过t_setpri系统调用改变。
3.1.3 任务状态
pSOS下任务具有三种可能状态并处于这三个状态之一。只有通过任务本身或其他任

务、ISR对pSOS内核所作的系统调用才能改变任务状态。从宏观角度看，一个多任务应用

通过一系列到pSOS的系统调用迫使pSOS内核改变受影响任务而从运行一个任务到运行另

一任务向前发展的。
对于pSOS kernel，任务在创建前或被删除后是不存在的。被创建的任务在能够运行

前必须被启动。一旦启动后，一个任务通常处于下面三个状态之一：
①Executing (Ready)就绪
②Running运行
③Blocked阻塞
就绪任务是未被阻塞可运行的，只等待高优先级任务释放CPU的任务。由于一个任务

只能由正运行的任务通过调用来被启动，而且任何时刻只能有一个正在运行的任务，所

以新任务总是从就绪态开始。
运行态任务是正在使用CPU的就绪任务， 系统只能有一个running任务。一般runni

ng任务是所有就绪任务中优先级最高的，但也有例外。
任务是由自身特定活动而变为阻塞的，通常是系统调用引起调用任务进入等待状态

的。所以任务不可能从ready态到blocked态，因为只有运行任务才能执行系统调用。
3.1.4 任务控制块
任务控制块TCB是pSOS内核建立并维护的一个系统数据结构,它包含了pSOS Kernel调

度与管理任务所需的一切信息,如任务名、优先级、剩余时间片数、当前寄存器状态等。

在有的RTOS中,任务的状态与任务TCB所处的队列是等同的。pSOS操作系统将二者分

为两个概念,例如任务处于阻塞状态,但它的TCB却处于消息等待队列、信号灯等待队列、

内存等待队列、超时队列之一。
pSOS启动时,将根据Configuration Table中的参数kc_ntask建立一个包含kc_ntask

个TCB块的TCB池,它表示最大并行任务数。在创建一个任务时,分配一个TCB给该任务,在

撤销一个任务时,该TCB将被收回。
3.1.5 对象、对象名及ID号
pSOS Kernel是一个面向对象的操作系统内核,pSOS系统中对象包括任务、memory
regions、memory partitions、消息队列和信号灯。
对象名由用户定义（4位ASCII字符）,并且在该对象创建时作为系统调用obj_CREAT
E
的一个人口参数传给pSOS Kernel。pSOS Kernel反过来赋予该对象一个唯一的32位ID号

。除obj_CREATE和obj_IDENT外,所有涉及对象的系统调用都要用到对象ID号。
创建对象的任务通过obj_CREATE就已经知道了该对象的ID号,其余任务可通过obj_
IDENT或通过全局变量（如果已经为该任务的ID号建立了一个全局变量的话）获取该对象

的ID号。对象ID号隐含了该对象控制块（如TCB、QCB）的位置信息,这一位置信息被pSO
S
Kernel用于对该对象的管理和操作,如挂起/解挂一个任务、删除一个消息队列等。
3.1.6 任务模式字Mode word.
每个任务带有一个mode word，用来改变调度决策或执行环境。主要有以下四个参

数
Preemption Enabled/Disabled.
Roundrobin Enabled/Disabled
Interupts Enabled/Disabled.
ASR Enabled/Disabled: 每个任务有一个通过as-catoh建立起来的异步信号服务例

程ASR。异步信号类似于软件中断。当ASR位为1时as-catch所指向的任务将会被改变执行

路径，先执行ASR，再返回原执行点。
§3.2 任务调度
3.2.1 影响动态调度效果的两个因素
pSOS采用优先级+时间片的调度方式。有两个因素将影响动态调度的效果:一是优先

级可变（通过t_setpri系统调用改变任务的优先级）；二是任务模式字中的preemption

bit位和roundrobin bit位。preemption bit位决定不同优先级的任务是否可抢占,并和

roundrobin bit位一起决定任务的时间片轮转是否有效。
3.2.2 引起任务调度的原因及结果
pSOS系统中引起调度的原因有两条:
1. 在轮转方式下时间片到
2. pSOS系统调用引发任务调度。该系统调用可能是ISR发出的,也可能是某个任务发出的
。
pSOS任务调度的结果有两种:
1. 引起运行任务切换,这指的是
2. 不引起运行任务切换,这指的是
不论任务调度是否引发运行任务切换,都有可能引起一个或多个任务状态变迁。
3.2.3 运行任务的切换
一、何时切换
下面三种情况将引发运行任务切换：
1. 在时间片轮转方式下（此时任务模式字的roundrobin bit与preemption bit均为
enable），运行任务Task A的时间片用完,且Ready队列中有相同优先级的其它任务，则

Task A退出运行。
2. 在运行任务Task A的Mode word的preemption bit位为enable的前提下,若Task A发出

的某条相同调用引发一个优先级高于Task A的任务Task B从Block状态进入Reary状态,则

将Task B投入运行。
3. ISR使用I_RETURN系统调用,则ISR退出运行,pSOS Kernel选择Ready队列中优先级最高

的任务投入运行（这一任务并不一定是被ISR打断的前运行任务）。
二、如何切换
上述三类运行任务的切换,其具体的pSOS Kernel运作过程并非完全一样,但彼此之间

差别不大。为了简单起见,我们以
为例对切换过程作一简单叙述。这一过程可细分为4个步骤：
1. 任务A运行信息保存（_t_save proc far）
这一过程主要完成修改系统工作标志，保存切换点地址及运行信息、任务A栈调
整
栈
指针保存、栈切换、参数及返址入栈等一系列工作。
2.任务A入就绪队列（void t_in_chain）
这一过程将任务A的TCB块按优先级顺序插入就绪队列。
3.选择一个高优先级任务B（void t_choice( )）
按一定算法从就绪队列中选出最高优先级任务B的TCB块,并使运行指针指向它。

4.将任务B投入运行（_t_run proc far）
从系统栈切换到任务B栈，用任务B的TCB块中保存的信息恢复上次运行被打断的
地
,恢
复任务运行环境，于是任务B开始继续运行。
图3.1反映了典型任务切换过程中CPU控制权的转移、各堆栈活动生命期、任务活动

生命期等信息。图中
t1,t4为切换点 t2,t3为开/关中断
Tsch=t4-t1 // Tsch为任务切换时间
Tforbid=t3-t2 // Tforbid为中断禁止时间
它们是实时操作系统最重要的两个性能指标。

2. 在C++ 程序中调用被 C 编译器编译后的函数，为什么要加 extern “C”声明

因为c++编译时会进行名变化，而C不会，导致无法找到函数等。
要禁止名变换，使用C++的extern 'C'指示。

详见
http://dev.csdn.net/article/13/13133.shtm

Item M34：如何在同一程序中混合使用C++和C
许多年来，你一直担心编制程序时一部分使用C++一部分使用C，就如同在全部用C编程的年代同时使用多个编译器来生成程序一样。没办法多编译器编程的，除非不同的编译器在与实现相关的特性（如int和double的字节大小，传参方式）上相同。但这个问题在语言的标准化中被忽略了，所以唯一的办法就是两个编译器的生产商承诺它们间兼容。C++和C混合编程时同样是这个问题，所以在实体混合编程前，确保你的C++编译器和C编译器兼容。
确认兼容后，还有四个要考虑的问题：名变换，静态初始化，内存动态分配，数据结构兼容。
* 名变换
名变换，就是C++编译器给程序的每个函数换一个独一无二的名字。在C中，这个过程是不需要的，因为没有函数重载，但几乎所有C++程序都有函数重名（例如，流运行库就申明了几个版本的operator<<和operator>>）。重载不兼容于绝大部分链接程序，因为链接程序通常无法分辨同名的函数。名变换是对链接程序的妥协；链接程序通常坚持函数名必须独一无二。
如果只在C++范围内，名变换不会影响你。如果你你有一个函数叫drawline而编译器将它变换为xyzzy，你总使用名字drawLine，不会注意到背后的obj文件引用的是xyzzy的。
如果drawLine位于C运行库中，那就是一个不同的故事了。你的C++源文件包含的头文件中申明为:
void drawLine(int x1, int y1, int x2, int y2);
代码体中通常也是调用drawLine。每个这样的调用都被编译器转换为调用名变换后的函数，所以写下的是
drawLine(a, b, c, d); // call to unmangled function name
obj文件中调用的是:
xyzzy(a, b, c, d); // call to mangled function mame
但如果drawLine是一个C函数，obj文件（或者是动态链接库之类的文件）中包含的编译后的drawLine函数仍然叫drawLine；没有名变换动作。当你试图将obj文件链接为程序时，将得到一个错误，因为链接程序在寻找一个叫xyzzy的函数，而没有这样的函数存在。
要解决这个问题，你需要一种方法来告诉C++编译器不要在这个函数上进行名变换。你不期望对用其它语言写的函数进行名变换，如C、汇编、Fortran、LISP、Forth或其它。（是的，这“其它”中应该包括COBOL，但那时你将得到什么？（Yes, what-have-you would include COBOL, but then what would you have? ））总之，如果你调用一个名字为drawLine的C函数，它实际上就叫drawLine，你的obj文件应该包含这样的一个引用，而不是引用进行了名变换的版本。
要禁止名变换，使用C++的extern 'C'指示：
// declare a function called drawLine; don't mangle
// its name
extern "C"
void drawLine(int x1, int y1, int x2, int y2);
不要以为有一个extern 'C'，那么就应该同样有一个extern 'Pascal'和extern 'FORTRAN'。没有，至少在C++标准中没有。不要将extern 'C'看作是申明这个函数是用C语言写的，应该看作是申明在个函数应该被当作好象C写的一样而进行调用。（使用术语就是，extern 'C'意思是这个函数有C链接，但这个意思表达实在不怎么清晰。不管如何，它总意味着一件事：名变换被禁止了。）
例如，如果不幸到必须要用汇编写一个函数，你也可以申明它为extern 'C'：
// this function is in assembler - don't mangle its name
extern "C" void twiddleBits(unsigned char bits);
你甚至可以在C++函数上申明extern 'C'。这在你用C++写一个库给使用其它语言的客户使用时有用。通过禁止这些C++函数的名变换，你的客户可以使用你选择的自然而直观的名字，而不用使用你的编译生成的变换后的名字：
// the following C++ function is designed for use outside
// C++ and should not have its name mangled
extern "C" void simulate(int iterations);
经常，你有一堆函数不想进行名变换，为每一个函数添加extern 'C'是痛苦的。幸好，这没必要。extern 'C'可以对一组函数生效，只要将它们放入一对大括号中：
extern "C" { // disable name mangling for
// all the following functions
void drawLine(int x1, int y1, int x2, int y2);
void twiddleBits(unsigned char bits);
void simulate(int iterations);
...
}
这样使用extern 'C'简化了维护那些必须同时供C++和C使用的头文件的工作。当用C++编译时，你应该加extern 'C'，但用C编译时，不应该这样。通过只在C++编译器下定义的宏__cplusplus，你可以将头文件组织得这样：
#ifdef __cplusplus
extern "C" {
#endif
void drawLine(int x1, int y1, int x2, int y2);
void twiddleBits(unsigned char bits);
void simulate(int iterations);
...
#ifdef __cplusplus
}
#endif
顺便提一下，没有标准的名变换规则。不同的编译器可以随意使用不同的变换方式，而事实上不同的编译器也是这么做的。这是一件好事。如果所有的编译器使用同样的变换规则，你会误认为它们生成的代码是兼容的。现在，如果混合链接来自于不同编译器的obj文件，极可能得到应该链接错误，因为变换后的名字不匹配。这个错误暗示了，你可能还有其它兼容性问题，早些找到它比以后找到要好。
* 静态初始化
在掌握了名变换后，你需要面对一个C++中事实：在main执行前和执行后都有大量代码被执行。尤其是，静态的类对象和定义在全局的、命名空间中的或文件体中的类对象的构造函数通常在main被执行前就被调用。这个过程称为静态初始化（参见Item E47）。这和我们对C++和C程序的通常认识相反，我们一直把main当作程序的入口。同样，通过静态初始化产生的对象也要在静态析构过程中调用其析构函数；这个过程通常发生在main结束运行之后。
为了解决main()应该首先被调用，而对象又需要在main()执行前被构造的两难问题，许多编译器在main()的最开始处插入了一个特别的函数，由它来负责静态初始化。同样地，编译器在main()结束处插入了一个函数来析构静态对象。产生的代码通常看起来象这样：
int main(int argc, char *argv[])
{
performStaticInitialization(); // generated by the
// implementation
the statements you put in main go here;
performStaticDestruction(); // generated by the
// implementation
}
不要注重于这些名字。函数performStaticInitialization()和performStaticDestruction()通常是更含糊的名字，甚至是内联函数（这时在你的obj文件中将找不到这些函数）。要点是：如果一个C++编译器采用这种方法来初始化和析构静态对象，除非main()是用C++写的，这些对象将从没被初始化和析构。因为这种初始化和析构静态对象的方法是如此通用，只要程序的任意部分是C++写的，你就应该用C++写main()函数。
有时看起来用C写main()更有意义－－比如程序的大部分是C的，C++部分只是一个支持库。然而，这个C++库很可能含有静态对象（即使现在没有，以后可能会有－－参见Item M32），所以用C++写main()仍然是个好主意。这并不意味着你需要重写你的C代码。只要将C写的main()改名为realMain()，然后用C++版本的main()调用realMain()：
extern "C" // implement this
int realMain(int argc, char *argv[]); // function in C
int main(int argc, char *argv[]) // write this in C++
{
return realMain(argc, argv);
}
这么做时，最好加上注释来解释原因。
如果不能用C++写main()，你就有麻烦了，因为没有其它办法确保静态对象的构造和析构函数被调用了。不是说没救了，只是处理起来比较麻烦一些。编译器生产商们知道这个问题，几乎全都提供了一个额外的体系来启动静态初始化和静态析构的过程。要知道你的编译器是怎么实现的，挖掘它的随机文档或联系生产商。
* 动态内存分配
现在提到动态内存分配。通行规则很简单：C++部分使用new和delete（参见Item M8），C部分使用malloc（或其变形）和free。只要new分配的内存使用delete释放，malloc分配的内存用free释放，那么就没问题。用free释放new分配的内存或用delete释放malloc分配的内存，其行为没有定义。那么，唯一要记住的就是：将你的new和delete与mallco和free进行严格的隔离。
说比做容易。看一下这个粗糙（但很方便）的strp函数，它并不在C和C++标准（运行库）中，却很常见：
char * strp(const char *ps); // return a of the
// string pointed to by ps
要想没有内存泄漏，strp的调用着必须释放在strp()中分配的内存。但这内存这么释放？用delete？用free？如果你调用的strp来自于C函数库中，那么是后者。如果它是用C++写的，那么恐怕是前者。在调用strp后所需要做的操作，在不同的操作系统下不同，在不同的编译器下也不同。要减少这种可移植性问题，尽可能避免调用那些既不在标准运行库中（参见Item E49和Item M35）也没有固定形式（在大多数计算机平台下）的函数。
* 数据结构的兼容性
最后一个问题是在C++和C之间传递数据。不可能让C的函数了解C++的特性的，它们的交互必须限定在C可表示的概念上。因此，很清楚，没有可移植的方法来传递对象或传递指向成员函数的指针给C写的函数。但是，C了解普通指针，所以想让你的C++和C编译器生产兼容的输出，两种语言间的函数可以安全地交换指向对象的指针和指向非成员的函数或静态成员函数的指针。自然地，结构和内建类型（如int、char等）的变量也可自由通过。
因为C++中的struct的规则兼容了C中的规则，假设“在两类编译器下定义的同一结构将按同样的方式进行处理”是安全的。这样的结构可以在C++和C见安全地来回传递。如果你在C++版本中增加了非虚函数，其内存结构没有改变，所以，只有非虚函数的结构（或类）的对象兼容于它们在C中的孪生版本（其定义只是去掉了这些成员函数的申明）。增加虚函数将结束游戏，因为其对象将使用一个不同的内存结构（参见Item M24）。从其它结构（或类）进行继承的结构，通常也改变其内存结构，所以有基类的结构也不能与C函数交互。
就数据结构而言，结论是：在C++和C之间这样相互传递数据结构是安全的－－在C++和C下提供同样的定义来进行编译。在C++版本中增加非虚成员函数或许不影响兼容性，但几乎其它的改变都将影响兼容。
* 总结
如果想在同一程序下混合C++与C编程，记住下面的指导原则：
* 确保C++和C编译器产生兼容的obj文件。
* 将在两种语言下都使用的函数申明为extern 'C'。
* 只要可能，用C++写main()。
* 总用delete释放new分配的内存；总用free释放malloc分配的内存。
* 将在两种语言间传递的东西限制在用C编译的数据结构的范围内；这些结构的C++版本可以包含非虚成员函数。