Professional Documents
Culture Documents
1 语言参考手册
David Gay, Philip Levis, David Culler, Eric Brewer
2003.5
1 简介
nesC 是对 C 的扩展 [2] ,它基于体现 TinyOS 的结构化概念和执行模型而设
计 [1] 。 TinyOS 是为传感器网络节点而设计的一个事件驱动的操作系统,传
感器网络节点拥有非常有限的资源 ( 举例来说., 8K 字节的程序储存器,512 个
字节的随机存取储存器) 。TinyOS 用 nesC 重新编写。本手册描述 nesC 的 1.1
版本, 在第 3 段中概述了它与 1.0 版的不同。
nesC 基本概念如下:
z 结构和内容的分离: 程序有组件构成, 它们装
配在一起 (" 配线 ") 构成完整程序. 组件定义
两类域, 一类用于它们的描述 ( 包含它们的接口
请求名称) ,另一类用于它们的补充。组件内部
存在作业形式的协作。 控制线程可以通过它的接
口进入一个组件。这些线程产生于一件作业或硬
件中断。
z 根据接口的设置说明组件功能。 接口可以由
组件提供或使用。被提供的接口表现它为使用者
提供的功能,被使用的接口表现使用者完成它的
作业所需要的功能。
z 接口有双向性: 它们叙述一组接口供给者 (指
令)提供的函数和一组被接口的使用者(事件)实现
的函数。这允许一个单一的接口能够表现组件之
间复杂的交互作用 (举例来说.,当某一事件在一
个回调之前发生时,对一些事件的兴趣登记)。 这
是危险的,因为 TinyOS 中所有的长指令 (举例
来说. 发送包)是非中断的; 他们的完成由一个事
件( 发送完成)标志。 通过叙述接口,一个组件
不能调用发送指令除非它提供 sendDone 事件的
实现。通常指令向下调用,比如, 从应用组件到
那些比较靠近硬件的调用,而事件则向上调用。特
定的原始事件与硬件中断是关联的 (这种关联是
由系统决定的,因此在本参考手册中不作进一步
描述)。
z 组件通过接口彼此静态地相连。 这增加运行
时效率,支持 rubust 设计, 而且允许更好的程序
静态分析。
z nesC 基于由编译器生成完整程序代码的需求
设计。这考虑到较好的代码重用和分析。这方面
的一例子是 nesC 的编译-时间数据竞争监视器。
z nesC 的协作模型基于一旦开始直至完成作
业 , 并且中断源可以彼此打断作业. nesC 编译
器标记由中断源引起的潜在的数据竞争。
本文是 nesC 的一本参考手册并非个别指导。TinyOS tutorial1 给出了对
nesC 的更亲切的介绍.
本文的其余部分构成如下: 第 2 节给出了本参考手册中使用的记号。. 第 3
节概述 nesC 1.1 的新特征。 第 4,5 节,6, 和 7 介绍 nesC 接口和组件. 第 8
节给出 nesC 的协作模型和数据竞争监视. 第 9 节解释 C 文件, nesC 接口和组
件是怎样被装配成一个应用. 第 10 节包含 nesC 的保留的各种特征. 最后,附
录 A 完全定义 nesC 的文法 (来自 Kernighan and Ritchie (K&R) [2, pp234–239]
附录 A 的对 C 文法述说的扩展),而附录 B 是本参考手册中所使用术语的专业
词汇词典。
2 符号
打字机字体作为 nesC 代码和文件名,带任意下标的单个斜体字符用于表示
nesC 实体,举例来说., " 组件 K" 或 " 数值 v"。nesC 文法是 ANSI C 文法的扩
展. 我们选择来自 Kernighan and Ritchie (K&R) 的附录 A 的 ANSI C 文法[2,
pp234 –239]作为我们介绍的基础。在这里我们将不重复 ANSI C 文法。. 斜体
字是非终端机和非文字的终端机,打字机字体和符号是文字的终端机。 下标 opt
表示可选择的终端机或非终端机。在一些情形中,我们改变一些 ANSI C 文法
规则. 我们用下面的方式表示:also 为现存的非终端机指出新增的内容,replaced
by 表示替换一现有的非终点的.nesC 的结构解释给出对应的文法片段。在这些片
段中,我们有时使用 . . . 表现省略( 与当前不相关的解释). 附录 A 给出完整的
nesC 文法.一些例子使用来自 C99 标准 inttypes.h 文件的 uint8 t 和 uint16 t
类型.
3 变化
nesC 1.0 版本同 1.1 版本的变化如下:
1. 原子的陈述. 这些单一化协同数据结构的实现,能够被新的编译- 时间数据竞
争监视器识别。
2. 编译- 时间数据竞争监视为可能的协同的二个中断操作者 , 或一个中断操作
者和一件作业同时存取变量提出警告
3. 指令和事件必须明确地标出存储类型说明才能安全地被中断操作者执行。
4. 对指令或"扇出"事件的调用返回结果自动地被新的类型- 特性的组合器执行
联合。
5. uniqueCount 是一个新的 " 常数功能 ", 具有独特的作用.
6. NESC 预处理程序符号指出语言版本. 对于 nesC 1.1 版本它是 110 。
4 接口
nesC 的接口有双向性: 它们描述一个多功能的两组件(供给者和使用者)之
间的交互渠道.。 接口叙述一组叫做指令的, 被接口的供给者实现的,被命名的
功能和一组叫做事件的, 被接口的使用者实现.的,被命名的功能。
本节解释接口如何被指定, 第 5 节解释组件如何描述它们提供和使用的接
口, 第 6 节解释在 C 代码中指令和事件如何被调用和实现,而第 7 节解释组
件接口如何被一起联编.
接口被接口类型指定,如下:
nesC-file:
includes-listopt interface
...
interface:
interface identifier { declaration-list }
storage-class-specifier: also one of
command event async
这声明接口类型标识符. 这一标识符有全局的作用范围并且属于分开的命名
空间,组件和接口类型命名空间。 如此所有接口类型都有清楚的名字以区别于其
它接口和所有组件, 同时能不和一般的 C 的声明发生任何冲突。
声明列表中,每个接口类型都有一个分开的声明范围。声明列表必须由有指
令或事件存储类型的功能描述组成( 否则, 会发生编译-时间错误). 可选的
async 关键字指出指令或事件能在一个中断处理者中被运行。
通过包含列表,一个接口能可选择地包括 C 文件 (见第 9 节)。
一个简单的接口如下:
interface SendMsg {
command result_t send(uint16_t address, uint8_t length, TOS_MsgPtr
msg);
event result_t sendDone(TOS_MsgPtr msg, result_t success);
}
这儿有一个完整的规格例子:
configuration GenericComm {
provides {
interface StdControl as Control;
// 该接口以当前消息序号作参数
interface SendMsg[uint8_t id];
interface ReceiveMsg[uint8_t id];
}
uses {
//发送完成之后为组件作标记
//重试失败的发送
event result_t sendDone();
}
} ...
在这个例子中,一般:
z 提供简单的接口实例类型 StdControl 的控
制.
z 提供接口类型 SendMsg 和 ReceiveMsg 的
参数实例; 参数实例分别地叫做 SendMsg 和
ReceiveMsg.
z 使用事件 sendDone.
我们说,在组件 K 的规格中提供的一个指令 (事件) F 是 K 的提供指令(事
件) F; 同样地,一个被用于组件 K 的规格的指令 (事件) 是 K 的使用指令 (事
件) F。
组件 K 的提供接口实例 X 的指令 F 是 K 的提供指令 X.F;组件 K 的使用接
口实例 X 的指令 F 是 K 的使用指令 X.F 。K 的提供接口实例 X 中的事件 F 是 K
的使用事件 X.F; K 的使用接口实例 X 中的事件 F 是 K 的提供事件 X.F ( 注意事
件的使用和提供根据接口双向属性的颠倒)。
当使用/提供区别关系不大时,我们常常只简单的提到" K 的指令或事件 a"。
K 的指令或事件 a 可能是参数化的或简单的, 取决于其通信的规格元素的参数化
或简单状态.
6 模块
模块用 C 代码实现组件说明:
module-implementation:
implementation { translation-unit }
指令和事件的执行是立即的,也就是,调用和发送信号行为和函数调用是同样
地。实际的指令或事件是由调用还是信号表达运行取决于程序结构联系说明。 这
些联系说明可能指定 0,1 或更多的实现将被运行。当超过 1 个实现被运行, 我们
说模块的指令或事件为"扇出"。
一个模块能为一使用指令或事件 a 指定默认的调用或信号实现。提供指令或
事件的默认实现会引起编译-时间错误。如果 a 未与任何指令或事件实现联系,
默认的实现将被执行。默认的指令或事件由带有默认关键字的指令或事件实现前
缀定义:
declaration-specifiers: also
default declaration-specifiers
第 7.4 节叙述实际上什么指令或事件实现被运行以及调用和信号表达返回什么
结果.
6.3 作业
作业是一个独立的控制点,由一个返回空存储类型的无二义性地函数定义:task
void myTask() { ... }。作业也能预先声明,举例来说., task void myTask();
作业通过前缀 post 调用通知,举例来说., post myTask()。通知返回迅速;如果独立
执行通知成功则返回 1,否则返回 0。通知表达式的类型是 unsigned char。
storage-class-specifier: also one of
task
call-kind: also one of
post
组件列表列出用来建立这一个结构的组件,连接列表指明各组件之间,以及
与结构说明之间是怎样装配在一起的。在这一节的其余部分中,我们调用来自结
构的外部的规格元素 , 和来自结构的内在的成份之一的规格元素。
7.1 包含组件
组件列表列出用来建立这一个结构的组件。在结构里面这些组件可随意的重命
名,使用共同外形规格元素,或简单的改变组件结构从而避免名称冲突。(以避
免必须改变配线)为组件选择的名字属于成份的实现域。
component-list:
components
component-list components
components:
components component-line ;
component-line:
renamed-identifier
component-line , renamed-identifier
renamed-identifier:
identifier
identifier as identifier
如果二个组件使用 as 给出相同的名字,则会发生编译时间错误(举例来说.,
componentsX, Y as X)。
只有一个个别的例子:如果组件 K 被用于二不同的结构 ( 或甚至两次用于
相同的结构里面), 在程序中仍然只有 K(及它的变量) 的唯一实例。
7.2 配线
配线用于连接规格元素 (接口,指令,事件)。本节和下一节(第 7.3 节) 定义
配线的语法和编译-时间规则。第 7.4 节详细说明程序配线声明是如何指出在每
个调用和信号表达中哪个函数被调用。
connection-list:
connection
connection-list connection
connection:
endpoint = endpoint
endpoint -> endpoint
endpoint <- endpoint
endpoint:
identifier-path
identifier-path [ argument-expression-list ]
identifier-path:
identifier
identifier-path . identifier
配线陈述连接二个端点。每个端点的标识符路径指明一个规格要素。自变量
表达式列表可选的指出接口参数值。如果端点的规格要素是参数化的,而端点又
没有参数值,那么我们说该端点是参数化的。如果一个端点有参数值,而下面的
任一事件成立时,就会产生一个编译时间错误:
z 叁数值不全是常量表达式.
z 端点的规格元素不是参数化的.
z 参数个数比规格要素中限定的叁数个数多
( 或少)
z 叁数值不在规格元素限定的叁数类型范围中。
如果端点的标识符路径不是以下三种形式之一,就会产生一个编译时间错误:
z X, 此处 X 命名一种外部的规格元素.
z K.X,此处 K 是组件列表中的一个组件,而 X
是 K 的规格元素。
K ,此处 K 是组件列表中的一些组件名。这种形式用在固定的连接中,将在第 7.3
节中讨论。 注意,当叁数值指定时这种形式不能够使用。
nesC 有三种配线陈述:
z endpoint1=endpoint2:( 赋值配线) 任何连接包
括一外部规格元素。这些有效地使两规格元素相
等。设 S1 是 endpoint1 的规格要素,S2 是 endpoint2
的规格要素。下面两个条件之一必须满足,否则就
会产生编译时间错误:
– S1 是内部的, S2 是外部的 (反之亦然) ,并且 S1 和 S2 都是被提供或都是
被使用
– S1 和 S2 都是外部的,而且一个被提供,而另一个被使用.
endpoint1->endpoint2:( 联编配线) 一个连接包括二种内在的规格元素。.联编配线
总是连结一由 endpoint1 指定的使用规格元素到一 endpoint2 指定的提供规格元
素。如果这两个条件不能满足, 就会发生编译-时间错误.。
z endpoint1<- endpoint2 与 endpoint2 ->
endpoint1 是等价的。
在配线的所有三种类型中,两被指定的规格元素必须是一致的,就是说., 它们
必须都是指令,或都是事件, 或都是接口实例. 同时, 如果它们是指令(或事件),则
它们必须有相同的函数名。如果他们是接口实例,它们必须有相同的接口类型。
他们一定是有相同的接口类型的. 如果这些条件不能满足, 就会发生编译-时间
错误.。
如果一个端点是参数化的,则另一个必须也是而且必须有相同的叁数类型;否
则就会发生编译-时间错误.。
相同的规格元素可以被多次连接,举例来说.,:
configuration C {
provides interface X;
} implementation {
components C1, C2;
X = C1.X;
X = C2.X;
}
在这个例子中,当接口 X 中的命令被调用时,多次的配线将会导致接口 X
的事件的多重信号 ("扇入"),以及多个函数的执行("扇-出")。注意,当二个结构
独立地联结相同接口的时候,多重配线也能发生,举例来说.:
configuration C { } configuration D { }
implementation { implementation {
components C1, C2; components C3, C2;
C1.Y -> C2.Y; C3.Y -> C2.Y;
} }
所有的外部规格元素必须配线,否则发生编译-时间错误. 可是,内部的规格元
素可以不连接 (它们可能在另外一个结构中配线,或者如果模块有适当的默认事
件或指令实现,他们可以不配线).
7.3 隐含连接
隐含连接可以写成 K1 <- K2.X 或 K1.X <- K2 (=和->是等价的). 该用法通过
规格元素 K1 (不妨 K2)来引用规格元素 Y,因此 K1.Y <- K2.X (不妨 K1.X <-
K2.Y )形成一个合法联结。如果能正确的引用 Y,则连接建立,否则发生编译-
时间错误。举例来说:
module M1 { module M2 {
provides interface StdControl; uses interface StdControl
as SC;
} ... } ...
configuration C { }
implementation {
interface X { module M {
command int f(); provides interface X as P;
event void g(int x); uses interface X as U;
} provides command void
h();
} implementation { ... }
configuration C {
provides interface X;
provides command void h2();
}
implementation {
components M;
X = M.P;
M.U -> M.P;
h2 = M.h;
}
图 1: 简单的配线例子
components M1, M2;
M2.SC -> M1;
}
图 2: 图 1 的中间函数
附录 A 语法
读本语法时,请翻阅 Kernighan and Ritchie (K&R) [2, pp234–239]的附录 A。
下列关键字对 nesC 是新的: as, call, command, components, configuration,
event, implementation, interface, module, post, provides, signal, task, uses, includes.
这些关键字在 C 文件中是不被保留的。 对应的 C 符号,通过加上
_nesc_keyword 前缀(举例来说.,_ nesc _keyword _as).,在 nesC 文件中是可用的。
nesC 所有的标识符均以_nesc 开头保留作为内部使用。TinyOS 保留所有的
标识符以 TOS_和 TOSH_开头。
nesC 文件遵循 nesC 文件要求; .h 文件通过 includes 包含,遵循来自 K&R 的
指令编译单位
新的规则:
nesC-file:
includes-listopt interface
includes-listopt module
includes-listopt configuration
includes-list:
includes
includes-list includes
includes:
includes identifier-list ;
interface:
interface identifier { declaration-list }
module:
module identifier specification module-implementation
module-implementation:
implementation { translation-unit }
configuration:
configuration identifier specification configuration-implementation
configuration-implementation:
implementation { component-listopt connection-list }
component-list:
components
component-list components
components:
components component-line ;
component-line:
renamed-identifier
component-line , renamed-identifier
renamed-identifier:
identifier
identifier as identifier
connection-list:
connection
connection-list connection
connection:
endpoint = endpoint
endpoint -> endpoint
endpoint <- endpoint
endpoint:
identifier-path
identifier-path [ argument-expression-list ]
identifier-path:
identifier
identifier-path . identifier
specification:
{ uses-provides-list }
uses-provides-list:
uses-provides
uses-provides-list uses-provides
uses-provides:
uses specification-element-list
provides specification-element-list
specification-element-list:
specification-element
{ specification-elements }
specification-elements:
specification-element
specification-elements specification-element
specification-element:
declaration
Interface renamed-identifier parametersopt
parameters:
[ parameter-type-list ]
改变的规则:
storage-class-specifier: also one of
command event async task norace
declaration-specifiers: also
default declaration-specifiers
direct-declarator: also
identifier . identifier
direct-declarator parameters ( parameter-type-list )
init-declarator-list: also
init-declarator attributes
init-declarator-list , init-declarator attributes
function-definition: also
declaration-specifiersopt declarator attributes declaration-listopt
compound-statement
attributes:
attribute
attributes attribute
attribute:
_attribute_ ( ( attribute-list ) )
attribute-list:
single-attribute
attribute-list , single-attribute
single-attribute:
identifier
identifier ( argument-expression-list )
statement: also
atomic-statement
atomic-statement:
atomic statement
postfix-expression: replaced by
primary-expression
postfix-expression [ argument-expression-list ]
call-kindopt primary ( argument-expression-listopt )
postfix-expression . identifier
postfix-expression -> identifier
postfix-expression ++
postfix-expression --
call-kind: one of
call signal post
附录 B 词汇
•联合函数: 连接前一扇出中指令(或事件信号)调用的多个返回结果的 C 函数。
•指令, 事件: 一个函数,作为组件说明的一部分,它要么直接地作为规格元素,
要么在组件的一个接口实例中。当直接作为规格元素时,指令和事件有自己的角
色 (提供者 , 使用者),而且可以有接口叁数。而对接口时实例, 我们区分没有
接口参数的简单指令(事件)和有接口参数的复杂指令(事件)。指令或事件的接口
参数可以从它的常用函数叁数中了解。
•编译- 时间错误: 一个 nesC 编译器在编译时必须报告的错误。
•组件: nesC 程序的基本单位。成份有名字并且有二个类型:模块和结构。组件有
说明和实现。
•结构: 一种组件,其实现由别的组件内容通过一特殊配线提供。
•端点: 在结构的配线陈述中的特别的规格元素的说明, 和可选地一些接口叁数
值。参数化端点是没有符合参数化规格元素的叁数值的端点。
•事件: 见指令.
•作用域: 变量的生存时间。nesC 有标准的 C 作用域: 模糊的,函数,和区段。
•外部的: 在一个结构 C 中, 描述 C 称述中的一种规格元素。见内部的。
•扇入: 描述有多个调用接口的提供指令或事件。
•扇出: 描述连接多个指令或事件实现的使用指令或事件。连接函数连接调用这
些使用指令或事件的返回结果。
•接口: 当上下文清楚时,我们使用接口引用接口类型或接口实例。
•接口实例: 组件说明中,某一接口类型的实例。接口实例有实例名,角色(提
供者或使用者),接口类型和可选的接口参数。没有接口参数的接口实例是简单
的接口实例,带有参数的是参数化接口实例。
•接口参数: 接口参数有接口参数名且一定是整数类型。参数化接口实例的每个
参数清单都有(概念的)一个独立的简单的接口实例(并且,同样的,在参数化
指令或事件的情况下,都有独立的简单的指令或事件)。参数化接口实例允许运
行时根据参数值在一套指令(或一套事件)中选择运行。
•接口类型: 接口类型陈述两组件,提供者和使用者间的交互作用。这种陈述使
用一套指令或事件的形式。每个接口类型都有一个明确的名字。接口是双向的:
接口供给者实现它的指令,接口使用者实现它的事件。
•中间函数: 表现组件指令和行为的虚函数,由整个程序的配线结构指定。见 7.4
节。
•内部的: 在一个结构 C 中, 描述 C 的组件列表中声明的一个组件的规格元素。
见外部的。
•模块: 由 C 代码提供实现的组件。
•命名空间: nesC 有标准的 C 变量(也为函数和宏使用),类型标识符(结构,
联合,枚举标识名)和标签命名空间。另外,nesC 有组件和接口类型命名空间
用于组件和接口类型名。
参数化指令,参数化事件,参数化接口实例,端点:见指令,事件,接口实例,
端点。
提供,提供者:规格元素的一个角色。接口实例的提供者必须在接口中实现指令;
提供指令和事件必须被实现。
K 的提供指令:一个指令,它要么是 K 提供的规格元素,要么是 K 的提供接口
的指令。
K 的提供事件:一个事件,它要么是 K 的规格元素,要么是 K 使用接口的事件。
•范围: nesC 拥有标准的 C 全局,函数参数和段落范围。另外,组件中还有说明
和实现范围和每一接口类型范围。范围被分为命名空间。
简单指令,简单事件,简单接口实例:见指令,事件,接口实例。
•规格:说明组件和其他组件交互作用的规格元素列表。
•规格元素:规格中提供或使用的接口实例,指令或事件。
•作业:一个 TinyOS 作业。
使用,使用者:规格元素的一种角色。接口实例的使用者必须实现接口中的事件。
K 的使用指令:一个指令,它要么是 K 的使用规格元素,要么是 K 的使用接口
的指令。
K 的使用事件:一个事件,它要么是 K 的使用规格元素,要么是 K 的提供接口
的事件。
•配线:由结构指定的组件规格元素间的连接。
参考书目
[1] J. Hill, R. Szewczyk, A. Woo, S. Hollar, D. E. Culler, and K. S. J. Pister.《传感器
网络系统结构指南》. In Architectural Support for Programming Languages and
Operating Systems, pages 93–104, 2000. TinyOS is available at
http://webs.cs.berkeley.edu.
[2] B. W. Kernighan and D. M. Ritchie. 《C 语言程序设计》, Second Edition.
Prentice
Hall, 1988.