From rinehuls@access.digex.net Fri Jul 17 19:29:02 1998 Received: from access5.digex.net (qlrhmEbBUV1EY@access5.digex.net [205.197.245.196]) by dkuug.dk (8.6.12/8.6.12) with ESMTP id TAA01862 for ; Fri, 17 Jul 1998 19:28:59 +0200 Received: from localhost (rinehuls@localhost) by access5.digex.net (8.8.4/8.8.4) with SMTP id NAA05762 for ; Fri, 17 Jul 1998 13:28:54 -0400 (EDT) Date: Fri, 17 Jul 1998 13:28:54 -0400 (EDT) From: "william c. rinehuls" To: sc22docs@dkuug.dk Subject: SC22 N2767 - Denmark Contribution on Standardization of Basic I/O Hardware Addressing in C - PLENARY AGENDA ITEM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ___________________ beginning of title page ________________________ ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretriat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N2767 TITLE: Denmark Member Body Contribution on Standardization of Basic I/O Hardware Addressing in ISO/IEC 9989 - Programming Language C - PLENARY AGENDA ITEM DATE ASSIGNED: 1998-07-16 SOURCE: Secretariat, ISO/IEC JTC 1/SC22 BACKWARD POINTER: N/A DOCUMENT TYPE: Member Body Contribution PROJECT NUMBER: N/A STATUS: Discussion of this contribution will be an agenda item for the August 1998 JTC 1/SC22 Plenary ACTION IDENTIFIER: FYI DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: N/A DISTRIBUTION FORM: Def Address reply to: ISO/IEC JTC 1/SC22 Secretariat William C. Rinehuls 8457 Rushing Creek Court Springfield, VA 22153 USA Telephone: +1 (703) 912-9680 Fax: +1 (703) 912-2973 email: rinehuls@access.digex.net _________ end of title page; beginning of contribution __________________ Danish input to Plenary Meeting, August 1998 Dato: 1998-07-03 Standardization of Basic I/O hardware addressing in ISO/IEC 9899:99 - Programming Language C. Late input from Danish MB to the ISO/IEC JTC1/SC22 - Plenary Meeting, August 1998, Copenhagen (Snekkersten). The Danish Memberbody would appreciate to have the below Danish input discussed in conjunction with SC22/WG14 Work Program, "C" Standards etc. Basic I/O hardware addressing. Denmark would like to see basic addressing of I/O hardware registers standardized in ISO/IEC 9899:99 - Programming Language C. A need for standardization of prior art. Today there is a lot of prior art for having compiler support of I/O hardware register addressing in C compilers for freestanding environments. It is also common practice that major parts of existing embedded application code depends heavily on efficient handling of I/O hardware register addressing from the C source level. The major problems we see today comes from the fact that the syntax for doing basic addressing of I/O hardware registers were not standardized in ISO/IEC9899:89. As a result source code with I/O addressing operations written today will usually not be portable between compilers from different vendors, not even between compilers for the same processor architecture. In order get current practice standardized, with C compiler support of basic I/O hardware addressing, Denmark strongly request that the syntax for basic I/O hardware addressing becomes standardized in ISO/IEC 9899:99 - Programming Language C. Why standardize the syntax for basic I/O addressing As embedded program applications grows in numbers and sizes it raises a growing need for reuse of program parts with new projects and for buying complete C function libraries for special application areas. Here the market for free-standing environments (embedded market) is far behind for instance the PC market. This is primarily caused by the large hardware diversity in the embedded market, and the simple fact that the most common I/O operations, basic I/O hardware addressing, does not have a standardized syntax in C. A standardization of the syntax for the basic I/O addressing operations in C will give the individual programmer, the individual company, and the industry as a whole, considerable benefits: * Easier programming. The same I/O syntax for all processors reduces the need for special knowledge about compilers and processors of a specific make. * More flexible development cycle. For instance can an I/O driver be written and tested before the final selection of a specific processor type and compiler make. * Source code will no longer be written to a specific compiler make but to standard C. This allow for instance standard PC compiler tools to be used for static test of embedded programs. An advantage in a project group when members compete for test time at the target system. * Better possibility for reuse of I/O drivers. A well functioning I/O driver often represent a considerable know-how. If an I/O driver can directly be used by other programmers in the company, significant cost can be saved. * Reduction in number of software versions. The same I/O driver source code can be reused across CPU families and C compilers from different vendors. This can give significant savings when code are developed for multiple processor types. Typical application areas are communication protocols, drivers for serial communication etc. * Software "components" for embedded use. A standardized I/O syntax will create a new market for embedded software libraries. The problem today is that the embedded market, because of C compiler dependencies, is too fragmented and therefore too small to be interesting for third party vendors. * I/O driver support from I/O chip vendors. It becomes easier for chip vendors to deliver a general software support for their chips. Each software module will be able to cover a much larger market. In principle it become possible to reuse the same I/O driver module with all processor systems where the I/O chip itself can be connected. * Generally applicable debugging tools and simulators. It becomes a lot easier to produce development tools based on C, which can be used across processor families and compilers makes. The I/O addressing proposal The I/O addressing method, as described in the current ISO/IEC JTC1/SC22 - WG14 document N731, propose a complete solution to the above standardization problems. The solution corresponds with a "standardization" practice which have been in use in the industry for many years. The standardization method used is simply to define a few functions in the standard for doing basic addressing operations on fixed sized I/O hardware registers, plus an abstract access_type descriptor which represent a complete description of how a given I/O register should be addressed in a given hardware system. This concept is new in the sense that it change the perception of I/O registers from something only related to processors busses and address ranges, to I/O registers as being individual object with individual properties, features, limitations and access mechanisms. This new concept enables and promote both I/O driver source code portability across multiple processor architectures and simplify the task of writing portable code. Single register functions (prototype overview) I/O functions for operations on single registers. For 8, 16, 32, 64 bit and 1 bit register sizes: /* Read operations: */ uint_8t iord8(access_type); uint_16t iord16(access_type); uint_32t iord32(access_type); uint_64t iord64(access_type); bool iord1(access_type); /* Write operations: */ void iowr8(access_type, uint_8t); void iowr16(access_type, uint_16t); void iowr32(access_type, uint_32t); void iowr64(access_type, uint_64t); void iowr1(access_type, bool); /* AND operations (Clear group of bits) */ void ioand8(access_type, uint_8t); void ioand16(access_type, uint_16t); void ioand32(access_type, uint_32t); void ioand64(access_type, uint_64t); void ioand1(access_type, bool); /* OR operations (Set group of bits) */ void ioor8(access_type, uint_8t); void ioor16(access_type, uint_16t); void ioor32(access_type, uint_32t); void ioor64(access_type, uint_64t); void ioor1(access_type, bool); Buffer functions (prototype overview) I/O functions for operations on I/O circuitry with internal buffers or multiple registers. Ex. a peripheral chip with a linear hardware buffer. index is the offset in the buffer starting from the I/O location specified by access_type, where element 0 is the first element located at the address defined by access_type, and element n+1 is located at a higher physical address than element n. /* Read operations on hardware buffers */ uint_8t iordbuf8(access_type, unsigned int index); uint_16t iordbuf16(access_type, unsigned int index); uint_32t iordbuf32(access_type, unsigned int index); uint_64t iordbuf64(access_type, unsigned int index); /* Write operations on hardware buffers */ void iowrbuf8(access_type, unsigned int index, uint_8t dat); void iowrbuf16(access_type, unsigned int index, uint_16t dat); void iowrbuf32(access_type, unsigned int index, uint_32t dat); void iowrbuf64(access_type, unsigned int index, uint_64t dat); /* AND operations on hardware buffers (Clear group of bits)*/ void ioandbuf8(access_type, unsigned int index, uint_8t dat); void ioandbuf16(access_type, unsigned int index, uint_16t dat); void ioandbuf32(access_type, unsigned int index, uint_32t dat); void ioandbuf64(access_type, unsigned int index, uint_64t dat); /* OR operations on hardware buffers (Set group of bits) */ void ioorbuf8(access_type, unsigned int index, uint_8t dat); void ioorbuf16(access_type, unsigned int index, uint_16t dat); void ioorbuf32(access_type, unsigned int index, uint_32t dat); void ioorbuf64(access_type, unsigned int index, uint_64t dat); Rationale for the I/O addressing proposal The proposed solution allow standardized I/O addressing operations to be added to the existing draft for ISO/IEC JTC1/SC22 9899:99 Programming language C with no impact on the rest of the standard. Function syntax versus an assignment syntax The reasons for choosing a function syntax instead a assignment operator syntax are: 1. A function syntax allows standardized hardware register addressing to be added to the standard without the need to extend the existing native type system or the abstract machine concept used by the C standard. 2. A function syntax still allow compilers to implement I/O register addressing with exactly the same runtime efficiency as we have with current practice, but now using a standardized syntax. This can be done simply by implementing the new I/O functions as either function like macros or with the new keyword inline. 3. Functions is the C way to do encapsulation. Although the new I/O functions looks like API functions, the real purpose with the function syntax is to provide a portable and standardized mechanism for enabling use of the different compiler specific extended types needed for I/O access with different kinds of processor architecture, without sacrificing portability. 4. A function syntax provides an encapsulation of the underlying addressing method and provides a save and portable migration path for compiler support to still more advanced addressing mechanisms. 5. The standard I/O functions limits the types of operation done on I/O hardware registers to the native access operations (read, write) which can be accomplished on I/O registers with all embedded processor architectures, plus I/O functions for the common bit-set and bit-clear operations (and, or) done on I/O registers. Other arithmetic operations is accomplished by use of these native access functions. 6. The function syntax emphasis the fact that I/O registers usually does not behave like memory cells in the sense that I/O registers often have an asymmetric read / write behavior. This again can simplify compiler implementations as it makes the use of ordinary arithmetic operations on asymmetric I/O registers a non-issue. New abstract access type The reason for using a new abstract access type are: 1. The new type provides a uniform and portable mechanism for referencing I/O registers in the C source code. 2. The abstract access_type provides a standardized method to isolate the actual addressing method used by a given I/O register with a given processor system from the C source code itself. In effect it enables a programmer to write C source code with hardware addressing operations in a compiler (and platform) independent manner. 3. It is a continuation of good programming practice, where I/O registers are identified by symbolic names instead of physical addresses, and where symbolic names for I/O registers are defined in separate header files, to order to make the source code itself more readable and portable. 4. The access definition encapsulation provides a uniform, safe and portable migration path for the implementation of still more advanced compiler supported access mechanisms. For instance from direct-addressing over indirect-addressing to addressing via different access drivers and the use of different mapping methods. 5. A standardized access_type encourage vendors to implements still more advanced compiler diagnostics for illegal I/O registers operations in future compilers (for instance AND operations on a write-only register). An abstract data type used for maximum portability A very wide range of different processor architectures are supported by different C compilers for free-standing environments. How access_type's should be defined, implemented and eventually initialized will therefore depend heavily on the characteristics of the underlying hardware system. With many architectures the access_type implementation will need to be system dependent in order to be efficient. Because of this, and because processor and bus architectures are assumed to evolve rapidly in the next decade, the definition of access_type is intentionally made loose. The standard promotes source code portability by defining the access_type only as an abstract type with certain properties. This however, does not prevent the overall standardization goals to be fulfilled, and there is prior art for using such abstract types in the C standard. For instance the FILE type. Some general properties for FILE and streams are defined in the standard, but the C standard deliberately avoid to tell how the underlying file system as such should be implemented or initialized. A similar philosophy is used with access_type. Basic I/O addressing in C, not as a separate API standard It is inadequate to have basic I/O addressing standardized as an API standard used by third party vendors. Basic I/O addressing concerns the very basic operations done by processor architectures and the access_type must be directly supported by the C compilers in order to have both efficient support for I/O at the C source level, and the same efficient machine code generation we have today with the different non-standardized solutions. With many processor architectures special machine instructions are required to make I/O operations, and compilers for free-standing environments are required to support special internal types in order to be able to implement I/O access at C level. Because of this, and because the purpose with the I/O proposal is to standardized existing practice with free-standing environments, basic I/O hardware addressing is required to be standardized as a part of the C standard. Informative or Normative but optional Today the primary target for this standardization of basic I/O hardware addressing is the market for free-standing environments, which is also the market that will get the largest economical benefit from such a standardization. However, to allow compilers for hosted environments not to implement basic I/O hardware registers addressing it is proposed that basic I/O hardware addressing is standardized in ISO/IEC 9899:99 - Programming Language C as an informative annex or a normative but optional annex. Proposal History and Conclusion The principle of I/O access "standardization" has been in practical use by the industry since the early nineties and had since then been adopted by several companies. The first I/O standardization proposal was presented to ISO/IEC JTC1/SC22 -WG14 in 1995 and had since be refined at several WG14 committee meetings to the form it has today. The final wordings for Basic I/O hardware addressing had since 1997 been ready for adoption in the standard. However C support for basic I/O addressing had not yet been voted in. The resistance against having basic I/O addressing support in C had mainly come from people representing companies which main business area is related to hosted environments. People with practical experience with I/O hardware drivers and free-standing environments have in general been in favor for the proposal, but have been outnumbered at committee meetings. The C standard covers both the market for free-standing environments and the market for hosted-environments. The need and request for a standardization of basic I/O addressing is mainly related to free-standing environment, and this standardization can be done in in ISO/IEC 9899:99 - Programming Language C without causing any harm to the market for hosted environments. Denmark therefore recommend that a broader view is taken by SC22, and recommend that SC22 support inclusion of basic I/O addressing as an annex to ISO/IEC 9899:99 - Programming Language C, for benefit of the electronic industry as a whole. ________________________ end of SC22 N2767 _________________________