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.