ISO/ IEC 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.