From: Matthew Deane <mdeane@ANSI.org>
To: 'SC 22 Distribution List' <sc22info@dkuug.dk>
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.



 