JTC1/SC22/WG14
N923
WG14 N923
Title: Further notes on Embedded C
Source: Willem Wakker (ACE, The Netherlands)
Date: September 2000
Status: For discussion at the October 2000 WG14 meeting
===================================================================
===== Responses NWI to ballot comments =====
===================================================================
During the adoption process of the New Work Item proposal (WG14
N889), a first ballot was held at SC22 level (SC22 N3039). The
result of this ballot (see SC22 N3083) was that the document was
approved without NO votes. Only the following comment from Japan
was received during this ballot:
Japan basically agrees with this New Work Item Proposal
provided that the work covers over the various kinds of
embedded processors (not limited to the specific kind of
processor, such as Digital Signal Processors) as described
in "title" and "scopes".
However, it seems that the proposed specification described
in "purpose and justification" and the referenced document
SC22/WG14 N 854 in "relevant document" discuss only about
the specifications for DSP. If the new work and the
resulted Technical Report are limited to the specification
only for DSP, Japan does not agree with the work.
During the subsequent ballot at JTC1 level, 2 NO votes (with
comments) were issued: one from Japan and one from Ireland; the
result of that ballot is in document SC22 N3120.
The comment from Ireland is:
While Ireland acknowledges the need for standardization in the
area of Embedded C, the paper being pursued by SC22/WG14,
N854 (and others) does not meet with our approval;
specifically, while there is a liaison with SC22/WG21, there is
no requirement for the TR to remain compatible with C++. The
specific extensions for Fixed Point Arithmetic and Hardware
I/O are too constrained in purpose and generality, which is
completely at variance with the tradition, purpose and definition
of C as a general purpose programming language.
Ireland's vote could be changed to a YES if the adoption of the
TR, is required to provide complete compatibility with the C++
programming language [ISO-IEC 14882-1998 (E)] the
proposed extensions for Fixed Point Arithmetic and Hardware
I/O are corrected to provide a degree of generality that is
consistent with the rest of the C programming language.
The comments from Japan are:
Japan basically agrees with this New Work Item Proposal
provided that ...
1. the work covers over the various kinds of embedded
processors (not limited to the specific kind of processor, such as
Digital Signal Processors) as described in "title" and "scopes".
However, it seems that the proposed specification described in
"purpose and justification" and the referenced document JTC
1/SC22 WG14 N854 in "relevant document" discuss only about
the specifications for DSP. If the new work and the resulted
Technical Report are limited to the specification only for DSP,
Japan does not agree with the work.
2. the work does NOT cover the additional API and the
extension of the language specification to support "low level I/O
operation". Japan thinks that such a kind of addition and
extension should not be included into the Type 2 Technical
Report. They should be published as a Type 3 Technical
Report.
Response to the comments from Ireland:
Since some time it is recognized that the C standard and the
C++ standard serve different communities, and the old
document "C and C++: as close as possible but not closer"
that described the relationship between C and C++ is no
longer considered to be valid. It is therefore inappropriate
to require that extensions for C are only allowed when they
are compatible with C++ (whatever that may imply).
It is furthermore recognized that fixed point proposal is
not as general as it could have been: it focuses on binary
fixed point datatypes and does not discuss fixed point
datatypes with other (or even arbitrary) radixes; such an
approach would however not serve the Embedded C community,
since their problem might get lost in a general approach
which makes it far more difficult to produce optimal code.
Yet it is the intention that the TR discusses ways to extend
the binary fixed point datatypes to fixed point datatypes
with other radixes.
Finally, examples for C++ fixed point implementation (such
as the CORBA/OMG specification) always provide a C binding
that exists of a large set of functions with type-less
(mostly integer) or structure type arguments; both approaches
are not acceptable to the Embedded C community.
It remains the firm intention of WG14 to work closely together
with WG21 in making the Embedded C TR as useful as possible
for the C++ community.
Response to the comments from Japan:
The proposed features to be described in the Technical Report
were a few years ago considered to be the key features of DSPs.
However nowadays also processors that are not considered to
be a typical DSP (such as the MMX Pentium and the P604)
support (some of) these features. Therefore we do not share the
fear expressed in the comments from Japan.
Responses on the comments related to the low level I/O operations
will be given elsewhere.
===================================================================
===== Notes on the C extensions for Embedded processors =====
===================================================================
Based on our previous contribution (see WG14 N907) and the
discussions at the WG14 meeting in Tokyo, here are some further
notes to be used for the discussion on the fundamentals for the
Embedded C extensions TR.
To recap: after the previous round it was established that
- there should be 2 different fixed point datatypes (typeA with only
fractional bits, and typeB with integral and fractional bits);
- saturation is associated with a type, not with a variable.
Open questions resulting from the previous discussions:
Q1: overview of commercially available processors supporting the
proposed (fixed point, circular buffers, memory spaces), with
their characteristics;
A1: to collect all this information in tabular (or otherwise
manageable) format has the large risk of producing something that
is quickly outdated. There is however information available on
the web (see for instance the overview by Berkeley Design
Technology at www.bdti.com/procsum containing lists of a.o. fixed
point DSP processors); it is assumed that these type of overviews
will be kept more up-to-date.
Q2: based on those characteristics, are there minimal values for the
number of fractional and integral bits in a fixed point datatype?
A2: based on the information available some detailed
characteristics are proposed in the text below.
Q3: does saturation also works on pointer arithmetic? And on mul/div
instructions?
saturation only works on integers and fixed point datatypes.
Q4: in the current proposals, the circular functionality is more
connected with buffers than with pointers. Isn't it more natural
to have the circular `size' specified in the pointer declaration?
A4: the current proposal allows for `generic' circular pointers to
be passed as parameters to functions; to have the size of the
buffer associated with the pointer makes this impossible (or at
least less generic).
Based on the analysis of existing fixed point hardware implementations,
the following assumptions can be made for a standardized (conforming)
fixed point implementation:
1- the implementation has at least 2 typeA datatypes and at most 3
typeA datatypes;
2- the smallest typeA datatype has at least 8 databits (i.e. at
least 8 fractional bits);
3- the qualifier keywords short, (int) and long are associated with
the typeA datatypes (if there are only 2 typeA datatypes, then the
combination shall be either short-int, or int-long); the short type
shall have the least databits, and the long type shall have the most
databits;
4- the implementation has at least 1 typeB datatype;
5- for each supported typeB datatype, there is a (corresponding)
typeA datatype with the same number of fractional databits; the
typeB datatype shall have the same qualifier (short, (int) or long)
as its corresponding typeA datatype; if there is more than 1 typeB
datatype supported, then a typeB datatype with a larger number of
fractional bits than another typeB datatype shall have at least the
same amount of integral bits as that other typeB datatype.
Then, on conversions:
6- Add a paragraph after 6.3.1.7 on fixed point with (as a minimum)
as text: "The conversion rank of a fixed point type shall be its
number of fractional bits."
Add to 6.3.1.8 of the C standard, before the paragraph on integer
promotions:
7- Otherwise, if both operands have the same fixed point type, then
no further conversion is needed.
8- Otherwise, if both operands have a typeB fixed point datatype,
the operand with the lesser conversion rank shall be converted to
the type of the operand with greater rank.
9- Otherwise, if either operand has a typeB fixed point type, then
the other operand shall be converted to that type.
10- Otherwise, if both operands have a typeA fixed point datatype,
the operand with the lesser conversion rank shall be converted to
the type of the operand with greater rank.
11- Otherwise, if either operand has a typeA fixed point type, then
the other operand shall be converted to that type.