language.values.html

有关ecos2。0介绍了实时嵌入式的结构以及线程调度的实现和内存的管理等

VALIGN="TOP"
>logical and</TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>4</TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>||</TT
></TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>logical or</TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>3</TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>xor, eqv</TT
></TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>logical equivalance</TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>2</TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>implies</TT
></TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>logical implication</TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>1</TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
><TT
CLASS="LITERAL"
>? :</TT
></TD
><TD
WIDTH="33%"
ALIGN="CENTER"
VALIGN="TOP"
>conditional</TD
></TR
></TBODY
></TABLE
><P
></P
></DIV
><P
>Function calls have the usual format of a name, an opening bracket,
one or more arguments separated by commas, and a closing bracket. For
example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    requires { !is_substr(CYGBLD_GLOBAL_CFLAGS, " -fno-rtti") }</PRE
></TD
></TR
></TABLE
><P
>Functions will differ in the number of arguments and may impose
restrictions on some or all of their arguments. For example it may be
necessary for the first argument to be a reference to a configuration
option. The available functions are described in <A
HREF="language.values.html#LANGUAGE.FUNCTIONS"
>the Section called <I
>Functions</I
></A
>. </P
><P
>The logical <TT
CLASS="LITERAL"
>xor</TT
> operator evaluates to true if
either the left hand side or the right hand side but not both evaluate
to true The logical <TT
CLASS="LITERAL"
>eqv</TT
> operator evaluates to true
if both the left and right hand sides evaluate to true, or if both
evaluate to false. The <TT
CLASS="LITERAL"
>implies</TT
> operator evaluates
to true either if the left hand side is false or if the right hand
side is true, in other words <TT
CLASS="LITERAL"
>A&nbsp;implies&nbsp;B</TT
>
has the same meaning as <TT
CLASS="LITERAL"
>!A&nbsp;||&nbsp;B</TT
>. An
example use would be:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    requires { is_active(CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE) implies
                   (CYGNUM_LIBC_MAIN_DEFAULT_STACK_SIZE &#62;= (16 * 1024)) }</PRE
></TD
></TR
></TABLE
><P
>This constraint would be satisfied if either the support for a main
stack size is disabled, or if that stack is at least 16K. However if
such a stack were in use but was too small, a conflict would be raised.</P
><P
>A valid <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> identifier in an expression, for example
<TT
CLASS="VARNAME"
>CYGGLO_SPEED</TT
>, will be interpreted as a reference to
a configuration option by that name. The option does not have to be
loaded into the current configuration. When the component framework
evaluates the expression it will substitute in a suitable value that
depends on whether or not the option is loaded, active, and enabled.
The exact rules are described in <A
HREF="language.values.html#LANGUAGE.VALUES.VALUE"
>the Section called <I
>Option Values</I
></A
>.</P
><P
>A constant string is any sequence of characters enclosed in quotes.
Care has to be taken that these quotes are not stripped off by the
<SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> interpreter before the <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expression parser sees them.
Consider the following:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    default_value "RAM"</PRE
></TD
></TR
></TABLE
><P
>The quote marks will be stripped before the <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expression parser
sees the data, so the expression will be interpreted as a reference to
a configuration option <TT
CLASS="VARNAME"
>RAM</TT
>. There is unlikely to be
such an option, so the actual default value will be
<TT
CLASS="LITERAL"
>0</TT
>. Careful use of braces or other <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> quoting
mechanisms can be used to avoid such problems.</P
><P
>		
String constants consist of the data inside the quotes. If the data
itself needs to contain quote characters then appropriate quoting is
again necessary, for example:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    default_value { "\"/dev/ser0\"" }</PRE
></TD
></TR
></TABLE
><P
>An integer constant consists of a sequence of digits, optionally
preceeded with the unary <TT
CLASS="LITERAL"
>+</TT
> or <TT
CLASS="LITERAL"
>-</TT
>
operators. As usual the sequence <TT
CLASS="LITERAL"
>0x</TT
> or
<TT
CLASS="LITERAL"
>0X</TT
> can be used for hexadecimal data, and a leading
<TT
CLASS="LITERAL"
>0</TT
> indicates octal data. Internally the component
framework uses 64-bit arithmetic for integer data. If a constant is
too large then double precision arithmetic will be used instead.
Traditional syntax is also used for double precision numbers, for
example <TT
CLASS="LITERAL"
>3.141592</TT
> or <TT
CLASS="LITERAL"
>-3E6</TT
>. </P
><P
>Of course this is not completely accurate: <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> is not a typed
language, all data is treated as if it were a string. For example the
following two lines are equivalent:</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>    requires CYGNUM_UITRON_SEMAS &#62; 10
    requires { CYGNUM_UITRON_SEMAS &#62; "10" }</PRE
></TD
></TR
></TABLE
><P
>When an expression gets evaluated the operators will attempt
appropriate conversions. The <TT
CLASS="LITERAL"
>&gt;</TT
> comparison
operator can be used on either integer or double precision numbers, so
it will begin by attempting a string to integer conversion of both
operands. If that fails it will attempt string to double conversions.
If that fails as well then the component framework will report a
conflict, an evaluation exception. If the conversions from string to
integer are successful then the result will be either the string
<TT
CLASS="LITERAL"
>0</TT
> or the string <TT
CLASS="LITERAL"
>1</TT
>, both of which
can be converted to integers or doubles as required.</P
><P
>It is worth noting that the expression
<TT
CLASS="LITERAL"
>CYGNUM_UITRON_SEMAS&nbsp;&gt;10</TT
> is not ambiguous.
<SPAN
CLASS="APPLICATION"
>CDL</SPAN
> identifiers can never begin with a digit, so it is not possible
for <TT
CLASS="LITERAL"
>10</TT
> to be misinterpreted as a reference to an
identifier instead of as a string.</P
><P
>Of course the implementation is slightly different again. The <SPAN
CLASS="APPLICATION"
>CDL</SPAN
>
language definition is such that all data is treated as if it were a
string, with conversions to integer, double or boolean as and when
required. The implementation is allowed to avoid conversions until
they are necessary. For example, given
<TT
CLASS="LITERAL"
>CYGNUM_UITRON_SEMAS&nbsp;&gt;&nbsp;10</TT
> the
expression parsing code will perform an immediate conversion from
string to integer, storing the integer representation, and there is no
need for a conversion by the comparison operator when the expression
gets evaluated. Given
<TT
CLASS="LITERAL"
>{&nbsp;CYGNUM_UITRON_SEMAS&nbsp;&gt;&nbsp;"10"&nbsp;}</TT
>
the parsing code will store the string representation and a conversion
happens the first time the expression is evaluated. All of this is an
implementation detail, and does not affect the semantics of the
language. </P
><P
>Different operators have different requirements, for example the
bitwise or operator only makes sense if both operands have an integer
representation. For operators which can work with either integer or
double precision numbers, integer arithmetic will be preferred.</P
><P
>The following operators only accept integer operands:
unary <TT
CLASS="LITERAL"
>~</TT
> (bitwise not), the shift operators
<TT
CLASS="LITERAL"
>&lt;&lt;</TT
> and <TT
CLASS="LITERAL"
>&gt;&gt;</TT
>, and the
bitwise operators <TT
CLASS="LITERAL"
>&#38;</TT
>, <TT
CLASS="LITERAL"
>|</TT
> and
<TT
CLASS="LITERAL"
>^</TT
>.</P
><P
>The following operators will attempt integer arithmetic first, then
double precision arithmetic: unary <TT
CLASS="LITERAL"
>-</TT
>,
the arithmetic operators <TT
CLASS="LITERAL"
>+</TT
>, <TT
CLASS="LITERAL"
>-</TT
>,
<TT
CLASS="LITERAL"
>*</TT
>, <TT
CLASS="LITERAL"
>/</TT
>, and <TT
CLASS="LITERAL"
>%</TT
>;
and the comparision operators <TT
CLASS="LITERAL"
>&lt;</TT
>,
<TT
CLASS="LITERAL"
>&lt;=</TT
>, <TT
CLASS="LITERAL"
>&gt;</TT
> and
<TT
CLASS="LITERAL"
>&gt;=</TT
>. </P
><P
>The equality <TT
CLASS="LITERAL"
>==</TT
> and inequality
<TT
CLASS="LITERAL"
>!=</TT
> operators will first attempt integer conversion
and comparison. If that fails then double precision will be attempted
(although arguably using these operators on double precision data is
not sensible). As a last resort string comparison will be used.</P
><P
>The operators <TT
CLASS="LITERAL"
>!</TT
>, <TT
CLASS="LITERAL"
>&#38;&#38;</TT
> and
<TT
CLASS="LITERAL"
>||</TT
> all work with boolean data. Any string that can
be converted to the integer <TT
CLASS="LITERAL"
>0</TT
> or the double
<TT
CLASS="LITERAL"
>0.0</TT
> is treated as false, as is the empty string or
the constant string <TT
CLASS="LITERAL"
>false</TT
>. Anything else is
interpreted as true. The result is either <TT
CLASS="LITERAL"
>0</TT
> or
<TT
CLASS="LITERAL"
>1</TT
>.</P
><P
>The conditional operator <TT
CLASS="LITERAL"
>?&nbsp;:</TT
> will interpret
its first operand as a boolean. It does not perform any processing on
the second or third operands.</P
><P
>In practice it is rarely necessary to worry about any of these
details. In nearly every case <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expressions just work as expected,
and there is no need to understand the full details.</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>The current expression syntax does not meet all the needs of component
writers. Some future enhancements will definitely be made, others are
more controversial. The list includes the following:</P
><P
></P
><OL
TYPE="1"
><LI
><P
>An option's value is determined by several different factors: whether
or not it is loaded, whether or not it is active, whether or not it is
enabled, and the data part. Currently there is no way of querying
these individually. This is very significant in the context of options
with the <TT
CLASS="LITERAL"
>bool</TT
> or <TT
CLASS="LITERAL"
>booldata</TT
>
flavors, because there is no way of distinguishing between the option
being absent/inactive/disabled or it being enabled with a data field
of <TT
CLASS="LITERAL"
>0</TT
>. There should be unary operators that allow
any of the factors to be checked.</P
></LI
><LI
><P
>Only the <TT
CLASS="LITERAL"
>==</TT
> and <TT
CLASS="LITERAL"
>!=</TT
> operators can
be used for string data. More string-related facilities are needed.</P
></LI
><LI
><P
>An implies operator would be useful for many goal expression, where
<TT
CLASS="LITERAL"
>A&nbsp;implies&nbsp;B</TT
> is equivalent to
<TT
CLASS="LITERAL"
>!A&nbsp;||B</TT
>.</P
></LI
><LI
><P
>Similarly there is inadequate support for lists. On occasion it would
be useful to write expressions involving say the list of implementors
of a given CDL interface, for example a sensible default value could
be the first implementor. Associated with this is a need for an
indirection operator.</P
></LI
><LI
><P
>Arguably extending the basic <SPAN
CLASS="APPLICATION"
>CDL</SPAN
> expression syntax with lots of new
operators is unnecessary, instead expressions should just support
<SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> command substitution and then component writers could escape
into <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> scripts for complicated operations. This has some major
disadvantages. First, the inference engine would no longer have any
sensible way of interpreting an expression to resolve a conflict.
Second, the component framework's value propagation code keeps track
of which options get referenced in which expressions and avoids
unnecessary re-evaluation of expressions; if expressions can involve
arbitrary <SPAN
CLASS="APPLICATION"
>Tcl</SPAN
> code then there is no simple way to eliminate
unnecessary recalculations, with a potentially major impact on
performance.</P
></LI
></OL
></BLOCKQUOTE
></DIV
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>The current implementation of the component framework uses 64 bit
arithmetic on all host platforms. Although this is adequate for
current target architectures, it may cause problems in future. At some
stage it is likely that an arbitrary precision integer arithmetic
package will be used instead.</P
></BLOCKQUOTE
></DIV
></DIV
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A