sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: PowerPC Header Files Submitted by: Bill Taylor File: psarc/1994/196/opinion.ms Date: July 5th, 1995. Committee: Joseph Kowalski, Steve C., Mark K., Terrence M., Bill Shannon, Glenn Skinner. Abstensions: David R.. 1. Summary This proposal establishes the modifications to be made to common, instruction set independent header files to support PowerPC. 2. Decision & Precedence Information The proposal is accepted. The project may be delivered in a minor release of Solaris. A true port to a new instruction set architecture would be expected to produce a micro change to the system. In this case, the project team decided to enhance the system in order to produce a superior port. It would have been possi- ble to define this project such as to qualify for a micro classification. This project is subset of the larger ``Solaris for PowerPC'' project, which was broken into subprojects to aid the review process. All of the subprojects must be delivered simul- taneously. PSARC/1993/685 PowerPC ABI PSARC/1994/188 Solaris Kernel for PowerPC PSARC/1994/196 PowerPC Headers PSARC/1994/197 PowerPC Commands PSARC/1994/198 PowerPC System Libraries PSARC/1994/302 PowerPC Booting 3. Opinion Although this case started out as complex and interesting, it was determined that most of the interesting bits were psarc/1994/196 Copyright 1994 Sun Microsystems, Inc. - 2 - better attributed to other cases. The controversial issues associated with the implementation of varargs(5) were assigned to PSARC/1993/685, "PowerPC ABI" although the implementation is visible in the headers. A similar deci- sion was made with respect to the value of _NFILES. 3.1. Global Flags PSARC/1993/444, ``Add isa_defs.h'', approves a policy of ``say what you mean'' for conditional compilation. If the code is dependent on the endianness of the platform, the conditional should be based on that, not on a disjunction of supported instruction set architectures. That case is incomplete because it doesn't specify a commitment level. This case clarifies PSARC/1993/444 to specify a commitment level of Public for both the name and feature test macros defined within. See reference [3] for more details. The port of Solaris to PowerPC has uncovered additional feature test macros that should be defined in . The additional macros and definitions which reflect processor characteristics are: _CHAR_ALIGNMENT _SHORT_ALIGNMENT _INT_ALIGNMENT _LONG_ALIGNMENT _LONG_LONG_ALIGNMENT _DOUBLE_ALIGNMENT _LONG_DOUBLE_ALIGNMENT _POINTER_ALIGNMENT: The ABI defines alignment requirements of each of the primitive object types. Some, if not all, may be hardware requirements as well. The values are expressed in "byte-alignment" units. _MAX_ALIGNMENT: The most stringent alignment requirement as speci- fied by the ABI. Equal to the maximum of all the above _XXX_ALIGNMENT values. _ALIGNMENT_REQ How absolute are the alignment requirements. _ALIGNMENT_REQ: This flag indicates that the hardware psarc/1994/196 Copyright 1994 Sun Microsystems, Inc. - 3 - requires the ABI alignment. _ALIGNMENT_OPT: This flag indicates that the hardware does not require the ABI alignment. Performance penalty is not considered. _FIRMWARE_NEEDS_FDISK This indicates the presence/absence of an fdisk table. _FIRMWARE_NEEDS_FDISK The fdisk table is required by system firmware. If present, it allows a disk to be subdivided into multiple fdisk partitions, each of which is equivalent to a separate, virtual disk. This enables the co-existence of multiple operating systems on a shared hard disk. _NO_FDISK_PRESENT If the fdisk table is absent, it is assumed that the entire media is allocated for a sin- gle operating system. 3.2. Variable Arguments The PowerPC ABI specifies the argument passing conventions and the majority of the interface changes required to sup- port variable arguments are discussed and approved in that case. Those discussions were extensive and contentious. A pair of related interfaces were not discussed in that case, nor should they have been. They are approved by this case. See references [1], [2] and [4] for more details. 3.2.1. va_copy() For most current processors and argument passing conven- tions, a simple pointer to memory is used as the underlying type of a va_list. PowerPC uses an array (of size one) of a structure to implement a va_list. It does this because the argument passing convention, which passes floating point arguments in floating point registers, requires multiple pointers to transverse the argument list (see [2]). This causes difficulties with applications that wish to ``save their place'' in an argument list. Currently, this is done in the non-portable way of simply assigning one instance of a va_list to another which assumes that a va_list is a assignable type, such as a pointer. This project proposes that a macro be defined to provide a portable method of ``saving your place'' across Solaris implementations. This does not address the problem of source portable across other operating systems. psarc/1994/196 Copyright 1994 Sun Microsystems, Inc. - 4 - The macro va_copy has the following definition: va_copy(va_list dest, va_list src) The va_copy() macro saves the state represented by the va_list src in the va_list dest. The va_list passed as dest should not be initialized by a previous call to va_start() and must be passed to va_end() before being reused as a parameter to va_start() or as the dest parameter of a subsequent call to va_copy. The behavior is undefined should any of the restrictions above not be met. This macro will be implemented in , and . (The multiple files are historic and not altered by this case.) Note that ANSI-C x3.159-1989 restricts the namespace in the first two of these files, so this macro will not be visible when ANSI-C, POSIX, or X/Open conformant compilations are specified. 3.2.2. __builtin_va_info PSARC/1993/138, ``Compiler Predefines'', defines Public interfaces between the ON headers and compilation systems to allow special compiler processing for a well defined set of symbols. These symbols are __builtin_alloca, __builtin_va_alist, and __builtin_va_arg_incr and are enabled by the feature test macro __BUILTIN_VA_ARG_INCR. See reference 3 for more details. Using the same feature test macro, __BUILTIN_VA_ARG_INCR, PowerPC does not use or define _builtin_va_alist or __builtin_va_arg_incr and additionally defines __builtin_va_info. The compilation system is able to gen- erate code to initialize the va_list structure when recog- nizing this symbol. Note that this case and definition alters/expands PSARC/1993/138. The formerly ISA independent specification is now ISA dependent. The original case defined the set of reserved words. These now apply only to SPARC and x86. This case alters that set for PowerPC. 3.3. Disk Layout Issues Although not directly related to header files, disk layout issues (``fdisk'' partitions, VTOC format) were raised dur- ing the discussion of this case and are addressed by this case. The industry standard specifications (PREP/CHRP) specify the use of an ``fdisk'' disk partitioning scheme as is the de facto standard on the Intel based platforms. The intent of this is to support multiple operating systems. Unfor- tunately, support of Virtual Open Firmware and legacy PROMS psarc/1994/196 Copyright 1994 Sun Microsystems, Inc. - 5 - means that Solaris consumes three of the four available par- titions. The project team informed the ARC that the NT port has the same property effectively negating the multiple OS intent of the ``fdisk'' partitioning. The ARC saw no alter- native to the use of ``fdisk'' partitions. The ARC was unsatisfied that there was no absolute alternative to con- suming three of the four partitions, but approved this usage. Currently, there are significant differences between the SPARC and x86 VTOC (Volume Table of Contents). One signifi- cant difference is that the SPARC VTOC only supports 8 slices while the x86 version supports 16. This disparity was justified by the assertion that x86 boot and alternate sector support requires additional partitions (leaving fewer for the user). In the case of alternate sectors, this turned out to be an implementation choice, rather than a requirement. However, there have been user requests for supporting a larger number of slices. The ARC expressed the desire for an architecture for VTOCs. There was some disagreement if this meant clear definitions of big-endian and little-endian versions or if a more ela- borate, XDR VTOC was the correct solution. The ARC did not believe that resolving this issue was the responsibility of the PPC Project Team and allowed the use of the current x86 form of the VTOC on a little-endian port of Solaris to PowerPC. This does not set a precedent for future ports. 3.4. Interface Table ___________________________________________________________________________________ | Interfaces Exported | |______________________|________________|_________________________________________| |Interface | Classification| Comments | |______________________|________________|_________________________________________| | | Public | File name | |_CHAR_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_SHORT_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_INT_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_LONG_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_LONG_LONG_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_DOUBLE_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_LONG_DOUBLE_ALIGNMENT| Public | Feature test macro (see PSARC/1993/444)| |_POINTER_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_MAX_ALIGNMENT | Public | Feature test macro (see PSARC/1993/444)| |_ALIGNMENT_REQ | Public | Feature test macro (see PSARC/1993/444)| |_ALIGNMENT_OPT | Public | Feature test macro (see PSARC/1993/444)| |_FIRMWARE_NEEDS_FDISK | Public | Feature test macro (see PSARC/1993/444)| |_NO_FDISK_PRESENT | Public | Feature test macro (see PSARC/1993/444)| |va_copy() | Public | Additional varargs macro | |__builtin_va_info() | Public | See PSARC/1992/138 | | | Uncommitted | File name | |______________________|________________|_________________________________________| psarc/1994/196 Copyright 1994 Sun Microsystems, Inc. - 6 - ___________________________________________________________________________________ | Interfaces Exported | |______________________|________________|_________________________________________| |Interface | Classification| Comments | |______________________|________________|_________________________________________| |Solaris FDISK ID (130)| Public | Identifies Solaris PPC partition | |______________________|________________|_________________________________________| 4. Minority Opinion(s) None. 5. Advisory Information This case touched upon the long unresolved issue of the cmdk driver. With one exception, the ARC expressed dismay that this implementation was ported to another instruction set architecture without the review it should have had before originally being shipped as part of the ``Solaris for Intel'' product. The possibility of adding a dependency on that review to the ``Solaris on PowerPC'' was considered (actually expressed at the inception review). However, such a dependency was not considered to be in the best interests of the corporation. Instead, the weak alternative of the following ``Advisory Information'' was decided upon. A project to unify the disk driver architectures for SCSI and direct attach devices should be initiated. Further investigation should be made into ways to restore the multiple OS support to the ``fdisk'' mechanism. This may not be possible or practical until the industry direc- tion is clearer. A project to regularize the VTOC should be created. There is some disagreement if this means clear definitions of big-endian and little-endian versions or if a more ela- borate, XDR VTOC is the correct solution. Backwards compa- tibility must be maintained. 6. Appendices 6.1. Appendix A: Technical Changes Required 1. Do not reserve the sys_sysppc system call. Allow the first project which asserts a need for it to define it. 6.2. Appendix B: Technical Changes Advised None. psarc/1994/196 Copyright 1994 Sun Microsystems, Inc. - 7 - 6.3. Appendix C: Reference Material 1. psarc/1993/685, PowerPC ABI, Steve Z. 2. System V Application Binary Interface, PowerPC Proces- sor Supplement (Draft), Steve Z., SunSoft; K. K., IBM, March 1995 3. psarc/1993/444, Add isa_defs.h, Joseph Kowalski 4. psarc/1993/138, Compiler Predefines, Lee Bieber 5. psarc/1994/168/materials/issue4.varargs (This case) 6. psarc/1993/015, x86 Disk Layout, Kevin S. psarc/1994/196 Copyright 1994 Sun Microsystems, Inc.