From: Matthew Deane To: 'SC 22 Distribution List' Subject: (SC22docs.1258) SC 22 N 3339 - Summary of Voting on SC 22 N 3269, Registration for PDTR 18037 Date: Friday, November 16, 2001 9:47 AM ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N3339 TITLE: Summary of Voting on SC 22 N3269, PDTR Registration Ballot for PDTR 18037, C Extensions to Support Embedded Processors DATE ASSIGNED: 2001-11-16 SOURCE: SC 22 Secretariat BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: 22.18037 STATUS: The results of this ballot are forwarded to SC 22/WG 14 for review and appropriate action. This project has been registered on the SC 22 programme of work as a PDTR. ACTION IDENTIFIER: ACT DUE DATE: DISTRIBUTION: Text CROSS REFERENCE: SC 22 N3269 DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat Matt Deane ANSI 25 West 43rd Street New York, NY 10036 Telephone: (212) 642-4992 Fax: (212) 840-2298 Email: mdeane@ansi.org __________end of cover page, beginning of summary____________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N3269 Circulated by: JTC 1/SC22 Circulation Date: 2001-07-26 Closing Date: 2001-10-26 SUBJECT: Summary of Voting on SC 22 N 3269, PDTR Registration Ballot for PDTR 18037, C Extensions to Support Embedded Processors ---------------------------------------------------------------------- The following responses have been received on the subject of PDTR registration: "P" Members supporting registration without comment 6 (Czech Republic, Denmark, Germany, Japan, Netherlands, United States of America) "P" Members supporting registration with comments 2 (Ireland, Norway) "P" Members not supporting approval 1 (United Kingdom) "P" Members abstaining 2 (Austria, France) "P" Members not voting 10 (Belgium, Brazil, Canada, China, Egypt, Finland, Romania, Russian Federation, Slovenia, Ukraine) Ireland There are two principal parts to this PDTR: - Fixed-Point data type - Hardware I/O abstraction Both of these parts have serious shortcomings regarding generality. START OF COMMENTS ON "Fixed-Point" ================================== The proposal on Fixed-Point addresses only binary fixed point numbers in the range -1.0 through +1.0. Fixed-Point umbers have been requested as extension to C for more than 12 years, mostly by members of the Financial sector whose requirements call for a decimal Fixed- Point data type. While a Fixed-Point data type is useful to the embedded community, a more generalised multi-radix Fixed-Point data type covering at least binary and decimal systems would have much wider application and would benefit a much larger community of C programs and programmers. ================================ END OF COMMENTS ON "Fixed-Point" START OF COMMENTS ON "Hardware I/O" =================================== The original proposal on Hardware I/O was categorically "fixed" to systems with byte addressable hardware, and devices with 8, 16, 32 and possibly 64-bit data paths. The current PDTR dilutes the "fixing" of the Hardware I/O abstraction to these widths, but still requires that a conforming implementation of C supports at least these widths. While byte-addressable memory, and data-paths of 8, 16, 32 and 64-bits may be common enough for discrete components, the System-on-Chip (SoC) requirements built typically around ASIC and FPGA technologies are not tied to the limitations of discrete component technology. With the rapid growth in the Silicon IP (Intellectual Property) market, devices that are fully customised to match the requirements of the problem being solved are becoming dominant. Such systems cover the SoC requirements for devices such as Wireless networking, where 4, 16 and 48-bit problem spaces occur; voice processing where 12 and 24-bit data paths are natural; and cryptographic systems and smart cards where 128 or even 256-bit solutions are natural. However, in some of these systems, it may or may not be practical to provide 16, 32 and 64-bit support. The lack of specificity in the PDTR regarding how conforming implementations can be built where the "Natural" word widths are not factorable into units of 8, 16, 32 or 64 is a significant problem for developers of embedded system in several Irish technology markets. ================================= END OF COMMENTS ON "Hardware I/O" Norway The Report should be layed out according to JTC 1 directives, for example by using one of the ISO templates for standards." United Kingdom The UK feels that no changes should be made that are likely to disturb the stability of C until after a period of consolidation to allow C99 to stabilise, most particularly not in the areas that were most affected by the new features in C99. This period should last until an industry consensus has emerged on which optional facilities in C99 are needed in almost all implementations and how of the unspecified aspects of C99 should be interpreted (as described below). This is not a position against fixing identified problems in C99, as one of the main purposes of consolidation is to resolve problems introduced by the changes in C99. Therefore significant TRs should be excluded if they are at all likely to disturb the stability of C99, but DRs that make changes should be encouraged if the changes remove identified problems or improve the quality of the C99 standard. Thus adding new classes of arithmetic types (or headers that add new arithmetic properties) is precisely what should not be considered at the present time, whereas adding suitably orthogonal library functions would be less of an issue (even if still probably undesirable). On the other hand, the sequence point issue is precisely the sort of thing that should be addressed, because it is attempting to improve a known problem area. The Rationale C99 has added a great deal of complexity to the C90 language, as well as increasing the compiler/library interactions many fold, especially in and around the floating-point area. Because much of this extra complexity is likely to be difficult or impossible to implement on many systems, most of it is optional and the implementer may choose how much of it to support and how. For related reasons, there has been an increase in the amount of the language that has been left unspecified, often as a "quality of implementation" matter, with the hope that market forces will produce an industry-wide consensus on appropriate subsets of C99 and their exact behaviour. Unfortunately, this means that those aspects of C99 cannot be used in portable programs because the programmer cannot know how widely a feature will be supported, or the exact meaning of his program even when the feature is supported. Perhaps the clearest example of this is in the area of floating-point exception and error handling, where there are 5 mechanisms (signals, errno, specific return values, exception flags and NaNs), most of which are optional at the choice of the implementer and several of which have no specification of precisely when they will and will not occur. Though it is outside the direct scope of the C99 standard, its interactions with other standards must be considered. C99 has changed the specification of the type handling in some important ways; this was usually because the previous specification had been discovered to be inadequate or to not match reality. Examples include the struct and union punning changes, the concept of effective type, the restrict qualifier, and so on. Because of the way that objects, lvalues and types interact, these changes have consequential changes on on exactly what object is being referred to in any particular context and on C's aliasing constraints. C is used as a base language for many other formal and informal standards, such as POSIX and OpenMP. It is extremely important to be sure that the new features in C99 do not conflict with such standards, not merely explicitly but also implicitly. One example here is the vast increase in shared memory parallelism at all levels from hardware to programming paradigms (e.g. POSIX threads and OpenMP), where the exact semantics of C's object and aliasing rules are critical to whether two threads are operating on independent objects or not. There are similar issues to do with exception and error handling which, as described above, has been changed quite radically. For these reasons, we need a period of consolidation so that the industry can reach a consensus, which will give the C99 language the stability it needs in order for the new C99 features to be usable in practical, portable programs. It is not enough that several vendors have conforming implementations, both because it is possible to conform to C99 without implementing many of the new features in full and because there are many different ways of conforming to some of the new features. The period of consolidation needs to be long enough so that there is evidence that these new features can be used as they are intended to be used in reasonably portable, reasonably robust, realistic programs. Prior art for needing this includes Algol 60, where integer labels and dynamic own arrays were excluded by the consensus.