uC++参考手册：带注释的C++扩展解析

需积分: 10 198 浏览量更新于2024-08-01 收藏 1.52MB PDF 举报

"The Annotated C++ Reference Manual" 是一本关于C++编程语言的详细参考资料，由Peter A. Buhr和Richard A. Stroobosscher编写。这本书提供了对C++标准的深入理解和扩展，特别关注了名为"µC+"的一个特定实现。书中包含了对C++语言设计要求、执行特性、高级执行构造的解析，以及如何扩展C++和使用"µC+"编译器的详细信息。在"µC+"扩展部分，作者探讨了设计目标，如满足嵌入式系统的需求，以及基本的执行属性，包括内存管理和程序结构。这一部分还介绍了高级执行构造，如控制流语句和数据结构，这些都是C++程序员日常工作中不可或缺的部分。 "µC+"翻译器章节深入介绍了如何扩展C++语言，包括如何构建和理解"µC+"程序的编译时和运行时结构。书中详细阐述了"µC+"的运行时结构，比如Cluster（可能指的是某种特定的内存组织或管理单元）和Virtual Processor（虚拟处理器），这在理解嵌入式系统中的C++实现时非常重要。此外，书中还涵盖了"µC+"内核的细节，这是整个系统的核心部分，负责管理程序的执行和资源分配。用户指南部分教授了如何使用"µC+"编译器，包括编译程序的具体步骤和预处理器变量的使用。书中的"Labelled Break/Continue"和"Coroutine"章节则进一步扩展了C++的控制流概念，Coroutine是一种可以暂停和恢复执行的子程序，这对于并发编程和复杂任务调度非常有用。 "Coroutine"章节详细解释了协程的创建、销毁以及它们如何在程序中协作执行。这部分内容对于理解和实现高效的多任务程序至关重要，尤其是在资源受限的嵌入式环境中。《The Annotated C++ Reference Manual》不仅是一本C++语言的权威参考，还是学习和应用"µC+"这个特定C++实现的宝贵资源，对于想要深入理解C++特性和其在嵌入式系统中应用的开发者来说，是不可多得的工具书。

CHAPTER 2.

C++ TRANSLATOR

currency is accomplished by a combination of interleaved execution and true parallel execution. Furthermore, µC++

uses a shared-memory model. This single memory may be the address space of a single UNIX process or a memory

shared among a set of kernel threads. A memory is populated by routine activations, class objects, coroutines, moni-

tors, coroutine monitors and concurrently executing tasks, all of which have the same addressing scheme for accessing

the memory. Because these entities use the same memory they can be

lightweight, so there is a low execution cost for

creating, maintaining and communicating among them. This approach has its advantages as well as its disadvantages.

Communicating objects do not have to send large data structures back and forth, but can simply pass pointers to data

structures. However, this technique does not lend itself to a distributed environment with separate address spaces.

2 Approaches taken by distributed shared-memory systems may provide the necessary implementation

mechanisms to make the distributed memory case similar to the shared-memory case. 2

2.2 Compile Time Structure of a µC++ Program

A µC++ program is constructed exactly like a normal C++ program with one exception: the main (starting) routine

is a member of an initial task called uMain, which has the following structure (Section

2.12, p. 29 details the task

construct):

Task uMain {

private:

int argc; // number of arguments on the shell command line

char

argv; // pointers to tokens on the shell command line

int &uRetCode; // return value to the shell

void main(); // user provides body for this routine

public:

uMain( int argc, char

argv[ ] ) : argc(argc), argv(argv) {}

};

A µC++ program must deﬁne the body for the main member routine of this initial task, e.g.:

. . . // normal C++ declarations and routines

void uMain::main() { // body for initial task uMain

. . .

switch( argc ) { // use argc from uMain

case 2:

no = atoi(argv[1]); // use argv from uMain

. . .

uRetCode = 0; // use uRetCode from uMain

}

µC++ supplies the free routine main to initialize the µC++ runtime environment and creates the task uMain, of which

routine uMain::main is a member. Member uMain::main has available, as local variables, the same two arguments that

are passed to the free routine main: argc, and argv. To return a value back to the shell, set the variable uRetCode and

return from uMain::main; uRetCode is initialized to zero.

2.3 µC++ Runtime Structure

The dynamic structure of an executing µC++ program is signiﬁcantly more complex than a normal C++ program. In

addition to the ﬁve kinds of objects introduced by the elementary properties, µC++ has two more runtime entities that

are used to control concurrent execution.

2.3.1 Cluster

A cluster is a collection of tasks and virtual processors (discussed next) that execute the tasks. The purpose of a cluster

is to control the amount of parallelism that is possible among tasks, where

parallelism is deﬁned as execution which

occurs simultaneously. Parallelism can only occur when multiple processors are present.

Concurrency is execution

that, over a period of time, appears to be parallel. For example, a program written with multiple tasks has the potential

to take advantage of parallelism but it can execute on a uniprocessor, where it may appear to execute in parallel

because of the rapid speed of context switching.

Normally, a cluster uses a single-queue multi-server queueing model for scheduling its tasks on its processors (see

Chapter 10, p. 123 for other kinds of schedulers). This simple scheduling results in automatic load balancing of tasks

2.3.

C++ RUNTIME STRUCTURE

on processors. Figure

2.1 illustrates the runtime structure of a µC++ program. An executing task is illustrated by its

containment in a processor. Because of appropriate defaults for clusters, it is possible to begin writing µC++ programs

after learning about coroutines or tasks. More complex concurrency work may require the use of clusters. If several

clusters exist, both tasks and virtual processors, can be explicitly migrated from one cluster to another. No automatic

load balancing among clusters is performed by µC++.

clusterprocessormonitortaskcoroutine

System Cluster

Processors

Blocked Tasks

Ready Tasks

Other Cluster(s)User Cluster

Figure 2.1: Runtime Structure of a µC++ Program

When a µC++ program begins execution, it creates two clusters: a system cluster and a user cluster. The system

cluster contains a processor that does not execute user tasks. Instead, the system cluster handles system-related opera-

tions, such as catching errors that occur on the user clusters, printing appropriate error information, and shutting down

µC++. A user cluster is created to contain the user tasks; the ﬁrst task created in the user cluster is uMain, which begins

executing the member routine uMain::main. Having all tasks execute on the one cluster often maximizes utilization of

processors, which minimizes runtime. However, because of limitations of the underlying operating system or because

of special hardware requirements, it is sometimes necessary to have more than one cluster. Partitioning into clusters

must be used with care as it has the potential to inhibit parallelism when used indiscriminately. However, in some situ-

ations partitioning is essential, e.g., on some systems concurrent UNIX I/O operations are only possible by exploiting

the clustering mechanism.

2.3.2 Virtual Processor

A µC++ virtual processor is a “software processor” that executes threads. A virtual processor is implemented by ker-

nel thread (normally created through a UNIX process) that is subsequently scheduled for execution on a hardware

processor by the underlying operating system. On a multiprocessor, kernel threads are usually distributed across the

hardware processors and so some virtual processors are able to execute in parallel. µC++ uses virtual processors in-

stead of hardware processors so that programs do not actually allocate and hold hardware processors. Programs can

be written to run using a number of virtual processors and execute on a machine with a smaller number of hardware

processors. Thus, the way in which µC++ accesses the parallelism of the underlying hardware is through an interme-

diate resource, the kernel thread. In this way, µC++ is kept portable across uniprocessor and different multiprocessor

hardware designs.

When a virtual processor is executing, µC++ controls scheduling of tasks on it. Thus, when UNIX schedules a

virtual processor for a runtime period, µC++ may further subdivide that period by executing one or more tasks. When

multiple virtual processors are used to execute tasks, the µC++ scheduling may automatically distribute tasks among

virtual processors, and thus, indirectly among hardware processors. In this way, parallel execution occurs.

CHAPTER 2.

C++ TRANSLATOR

2.4 µC++ Kernel

After a µC++ program is translated and compiled, a runtime concurrency library is linked in with the resulting pro-

gram, called the µC++ kernel. There are two versions of the µC++ kernel: the unikernel, which is designed to use a

single processor (in effect, there is only one virtual processor); and the multikernel, which is designed to use several

processors. Thus, the unikernel is sensibly used on systems with a single hardware processor or when kernel threads

are unavailable; the multikernel is sensibly used on systems that have multiple hardware processors and when kernel

threads are available. Table 2.2 shows the situations where each kernel can be used. The unikernel can be used in a

system with multiple hardware processors and kernel threads but does not take advantage of either of these capabili-

ties. The multikernel can be used on a system with a single hardware processor and kernel threads but performs less

efﬁciently than the unikernel because it uses multiprocessor techniques unnecessarily.

no kernel threads kernel threads

single unikernel, yes unikernel, yes

processor

multikernel, no multikernel, yes, but inefﬁcient

multiple unikernel, yes unikernel, yes, but no parallelism

processors multikernel, no multikernel, yes

Table 2.2: When to Use the Unikernel and Multikernel

Each of the µC++ kernels has a debugging version, which performs a number of runtime checks. For example,

the µC++ kernel provides no support for automatic growth of stack space for coroutines and tasks because this would

require compiler support. The debugging version checks for stack overﬂow whenever context switches occur among

coroutines and tasks, which catches many stack overﬂows; however, stack overﬂow can still occur if insufﬁcient

stack area is provided, which can cause an immediate error or unexplainable results. Many other runtime checks are

performed in the debugging version. After a program is debugged, the non-debugging version can be used to increase

performance.

2.5 Using the µC++ Translator

To use the concurrency extensions in a C++ program, include the ﬁle:

#include <uC++.h>

at the beginning of each source ﬁle needing access to µC++,

and it must appear before all other include ﬁles.

2.5.1 Compiling a µC++ Program

The u++ command is used to compile a µC++ program. This command works just like the GNU g++ [

Tie90] command

for compiling C++ programs, e.g.:

u++ [C++ options] yourprogram.C [assembler and loader ﬁles]

The following additional options are available for the u++ command:

-debug The program is linked with the debugging version of the unikernel or multikernel. The debug version

performs runtime checks to help during the debugging phase of a µC++ program, but substantially slows the ex-

ecution of the program. The runtime checks should only be removed after the program is completely debugged.

This option is the default.

-nodebug The program is linked with the non-debugging version of the unikernel or multikernel, so the execution

of the program is faster.

However, no runtime checks or asserts are performed so errors usually result in

abnormal program termination.

-yield When a program is translated, a random number of context switches occur at the beginning of each member

routine so that during execution on a uniprocessor there is a better simulation of parallelism. (This non-

determinism in execution is in addition to random context switching due to pre-emptive scheduling, see Sec-

tion

8.4.1, p. 115). The extra yields of execution can help during the debugging phase of a µC++ program, but

substantially slows the execution of the program.

-noyield Additional context switches are not inserted in member routines. This option is the default.

2.5. USING THE

C++ TRANSLATOR

-verify When a program is translated, a check to verify that the stack has not overﬂowed occurs at the beginning of

each member routine. (This checking is in addition to checks on each context switch provided by the -debug

option.) Verifying the stack has not overﬂowed is important during the debugging phase of a µC++ program,

but slows the execution of the program.

-noverify Stack-overﬂow checking is not inserted in member routines. This option is the default.

-multi The program is linked with the multikernel.

-nomulti The program is linked with the unikernel. This option is the default.

-quiet The µC++ compilation message is not printed at the beginning of a compilation.

-noquiet The µC++ compilation message is printed at the beginning of a compilation. This option is the default.

-U++ Only the C preprocessor and the µC++ translator steps are performed and the transformed program is written

to standard output, which makes it possible to examine the code generated by the µC++ translator.

-compiler path-name The path-name of the compiler used to compile a µC++ program(s). The default is the com-

piler used to compile the µC++ runtime library. It is unsafe to use a different compiler unless the generated code

is binary compatible. (See Section

11.3, p. 138 for supported compilers.)

When multiple conﬂicting options appear on the command line, e.g., -yield followed by -noyield, the last option takes

precedence.

2.5.2 Preprocessor Variables

When programs are compiled using u++, the following preprocessor variables are available:

U CPLUSPLUS is always available during preprocessing and its value is the current major version number

of µC++.

U CPLUSPLUS MINOR is always available during preprocessing and its value is the current minor version

number of µC++.

U CPLUSPLUS PATCH is always available during preprocessing and its value is the current patch version

number of µC++.

U DEBUG is available during preprocessing if the -debug compilation option is speciﬁed.

U YIELD is available during preprocessing if the -yield compilation option is speciﬁed.

U VERIFY is available during preprocessing if the -verify compilation option is speciﬁed.

U MULTI is available during preprocessing if the -multi compilation option is speciﬁed.

These preprocessor variables allow conditional compilation of programs that must work differently in these situa-

tions. For example, to allow a normal C/C++ program to be compiled using µC++, the following is necessary:

#ifdef

U CPLUSPLUS

void uMain::main() {

#else

int main( int argc, char

argv[ ] ) {

#endif

// body of main routine

}

which conditionally includes the correct deﬁnition for main if the program is compiled using u++.

The C preprocessor allows only integer values in a preprocessor variable so a value like “5.7.0” is not allowed. Hence, the need to have three

variables for the major, minor and patch version number.

CHAPTER 2.

C++ TRANSLATOR

2.6 Labelled Break/Continue

While C++ provides break and continue statements for altering control ﬂow, both are restricted to one level of nesting

for a particular control structure. Unfortunately, this restriction forces programmers to use goto to achieve the equiv-

alent for more than one level of nesting. To prevent having to make this switch, µC++ extends the break and continue

with a target label to support static multi-level exit [

Buh85, GJSB00]. For the labelled break, it is possible to specify

which control structure is the target for exit, e.g.:

C++ µC++

for ( .. . ) {

for ( . . . ) {

. . . goto L1; ...

. . . goto L2; ...

. . . goto L3; ... // or break

} L3: ;

} L2: ;

} L1: ;

L1: for ( ... ) {

L2: for ( . . . ) {

L3: for ( ... ) {

. . . break L1; .. .

. . . break L2; .. .

. . . break L3; .. . // or break

}

The innermost loop has three exit points, which cause termination of one or more of the three nested loops, respectively.

For the labelled continue, it is possible to specify which control structure is the target for the next loop iteration, e.g.:

C++ µC++

for ( .. . ) {

for ( . . . ) {

. . . goto L1; ...

. . . goto L2; ...

. . . goto L3; ... // or continue

L3: ; }

L2: ; }

L1: ; }

L1: for ( . . . ) {

L2: for ( ... ) {

L3: for ( . . . ) {

. . . continue L1; . . .

. . . continue L2; . . .

. . . continue L3; . . . // or continue

}

The innermost loop has three restart points, which cause the next loop iteration to begin, respectively. For both break

and continue, the target label must be directly associated with a for, while or do statement; for break, the target label

can also be associated with a switch or compound ({}) statement, e.g.:

L1: {

. . . declarations . . .

L2: switch ( . . . ) {

L3: for ( . . . ) {

. . . break L1; . . . // exit compound statement

. . . break L2; . . . // exit switch

. . . break L3; . . . // exit loop

}

. . .

}

. . .

}

Both break and continue with target labels are simply a goto restricted in the following ways:

• They cannot be used to create a loop. This means that only the looping construct can be used to create a loop.

This restriction is important since all situations that can result in repeated execution of statements in a program

are clearly delineated.

• Since they always transfer out of containing control structures, they cannot be used to branch into a control

structure.

The advantage of the labelled break/continue is that it allows static multi-levelexits without having to use the goto

statement and ties control ﬂow to the target control structure rather than an arbitrary point in a program. Furthermore,

the location of the label at the beginning of the target control structure informs the reader that complex control ﬂow is

剩余189页未读，继续阅读

stone421

粉丝: 9
资源: 9

uC++参考手册：带注释的C++扩展解析

c++注释引用参考（中文版本）

The Annotated C++ Reference Manual(ARM)-Ch17

_The+Annotated+C+++Reference+Manual

The Annotated C++ Reference Manual part4

The Annotated C++ Reference Manual part3

The Annotated C++ Reference Manual.part2

The Annotated C++ Reference Manual.part1

The Annotated C++ Reference Manual.zip.001

The Annotated C++ Reference Manual.7z.002

The Annotated C++ Reference Manual.7z.003

最新资源