Multics Technical Bulletin MTB-691 Multics C Exe. Env. Spec. To: Distribution From: Douglas Howe Date: 27 November 1985 Subject: Multics C Execution Environment Specification 1. Abstract This MTB describes the execution environment that will be used by C programs. In this environment, C programs and programmers can limit the amount of interpretation to be done by Multics. Changes will be marked with change bars. | Comments should be sent to the authors: via Multics mail to: DGHowe.Multics via posted mail to: Douglas G. Howe Advanced Computing Technology Centre Foothills Professional Building 1620 29th St., N.W. Calgary Alberta Canada T2N-4L7 via telephone to: (403)-270-5400 (403)-270-5437 (Howe) via forum on System-M to: >udd>m>DGHowe>mtgs_dir>c>c_imp (c) _________________________________________________________________ Multics project internal documentation; not to be reproduced or distributed outside the Multics project. MTB-691 Multics Technical Bulletin Multics C Exe. Env. Spec. TABLE OF CONTENTS Section Page Subject ======= ==== ======= 1 i Abstract 2 1 Preface 3 2 Introduction 3.1 2 . . Goal 3.2 3 . . References For This Document 4 4 Background 5 6 Link Editor 5.1 6 . . Similarities With The Binder 5.2 6 . . Extensions From The Binder 6 7 `Main_' 6.1 7 . . Cleanup and Abort Handlers 6.2 8 . . Heap and Execution Environment Initialization 6.3 8 . . Convert Argc and Argv 6.4 8 . . Initialize I/O Structures 6.5 8 . . Call main 6.6 9 . . Cleanup of Space and Files 6.7 9 . . Reset Execution Environment Multics Technical Bulletin MTB-691 Multics C Exe. Env. Spec. 2. Preface This document defines the execution environment that C will have on Multics. Most of the documentation needed to implement the C compiler on Multics will be supplied by this MTB, along with MTB-647 and the other related MTBs. We wish to thank those people who have made this possible either by creating tools for analysis or through input of subject matter. These people are Ron Barstad, Greg Baryza, Rick Gray, Steve Herbst, Dave Mason, Audrey Neal, Tom Oke, Doug Robinson, Melanie Weaver and Brian Westcott. MTB-691 Multics Technical Bulletin Multics C Exe. Env. Spec. 3. Introduction This Mtb describes the execution environment that C will use under on Multics. Although C programs on Multics will execute in the standard Multics execution environment, the environment will have a few extentions to allow it to be similar to the environment that C programs and programmers expect for the C language. C will be compatible with all the usual tools, such as profile and trace, and will be able to use the system debugging tools. 3.1. Goal The goal of this project is to create a Multics native C compiler. Our objective is to allow the porting of existing software to Multics and the use of basic Multics tools. The compiler is to be consistent with Multics compiler products, while not losing compatibility with System V Release 2.0 C.(1) The product produced by this project, while following Multics standards, will introduce a new idea to Multics. This idea is to create an environment in which third party software groups can port their software without having to Multicize it. This will be done by the introduction of a linked environment where the possibility of dynamic linking can be limited to a specific group of routines. _________________________________________________________________ (1) Unix and System V Release 2.0 are registered trademarks of AT & T Multics Technical Bulletin MTB-691 Multics C Exe. Env. Spec. 3.2. References For This Document 1) MTB-647 created by Greg Baryza. 2) The C Programming Language Kernighan, Brian W. & Ritchie, Dennis M. Prentice-Hall (1978) Englewood Cliffs, New Jersey 4) Multics Programmers Reference Manual (10.2 AG91-03A) (hereafter referred to as MPRM) 5) MTB 689 titled The C Runtime System on Multics by Doug Howe 6) MTB 688 titled The Multics C Implementation Specification by Doug Howe. 7) MTB entitled the Multics Link Editor Specification by Dean Elhard and Doug Howe. MTB-691 Multics Technical Bulletin Multics C Exe. Env. Spec. 4. Background In the development of the C language on Multics a series of environemntal dependancies have become apparent. Some of these dependancies are: 1) Programs are completely contained in load modules prior to execution. All references to C's external and static variables are resolved prior to execution via a link editor or by compiling module dependencies together creating a self contained execution structure. Multics is one of the few systems that uses dynamic linking. 2) All external initialization is done prior to referencing the external items, and pertains only to the current execution unit. All of C's heap allocations are on a per-execution-process, not on a per-login-process. Most other systems work on a per-execution-process rather than the Multics per-login-process environment. 3) All functions in C (unless defined as static) are considered to be external. 4) A C execution unit is entered through an entrypoint named `main'. All other functions within the execution unit are considered to be unavailable from the system level. 5) The arguments passed to main programs from the command processor are expected to be in a defined format. This format is defined in two variables passed to programs called 'Argc' and 'Argv'. Argc contains the number of parameters contained in the command processors argument list, and Argv is a pointer to an array of pointers to the character strings contained in the command line terminated with the null character. The value of Argv is a pointer to the name used to enter the routine at command level. 6) C has no internal structure that is defined to be a character string. So called character strings are arrays of characters terminated with a null character. These structures are user defined. 7) C's normal environment ensures the resetting of storage and the environment on exit from a program. Multics Technical Bulletin MTB-691 Multics C Exe. Env. Spec. Most C users expect to write their program, compile it, link edit it with a library and execute it. The equivalent mechanism on Multics includes the coordinated use of run units and the Multics binder. The current binder while being a general Multics tool does not produce relocatable output nor does it allow a simple user interface similar to what is available on other systems. The current binder can not be altered to use VLO's and remain compatable with ealier versions. To allow the binder to remain in its current form we will be introducing a new user tool to be named "The Multics Linkage Editor". Run units are currently used to encapsulate an execution environment allowing users to initialize their external references with set_fortran_common and it gives them the ability to have an epiloge handler to clean up their environment by doing such things as closing opened files. The run unit mechanism is unfortunately set up to operate on a per-login-process environment. Run units do allow a user to alter the environment prior to the execution of a program but for C the biggest problem occurs when a program calls out of its current encapsulation into another program. Due to C requiring that inter-execution unit calls have an initialized environment a new mechanism similar to run unitis will be developed. This new mechanism will be a combination of an entrypoint `main_' and a new link type. With this in mind we will now discuss the solution which is proposed for C on Multics. This solution is made up of a coordinated use of a new Link Editor, the entrypoint 'main_' and the new link type. MTB-691 Multics Technical Bulletin Multics C Exe. Env. Spec. 5. Link Editor A new tool will be introduced to handle the resolution of external references and the initialization of C's external and static variables. This tool will be called the Multics Link Editor and will be fully defined in a later MTB. The entire purpose of the Link Editor is to facilitate the porting of third party software to Multics from systems that do not support dynamic linking and single process environments. 5.1. Similarities With The Binder The function of the Link Editor will be similar to the current Multics Binder in that it will join together a series of compiled segments. It will resolve all external references that can be found within the supplied segments. Any references not resolved by the combining of the object segments will be left as Multics external references, and will be dynamically linked at runtime. The Link Editor will also combine initialization of all externally defined and static variables into a single block or group definition. This will be contained at the global level of the execution unit, as is currently done with the Multics Binder. 5.2. Extensions From The Binder There are a series of extensions that the new Link Editor will have over the current Binder. These extensions can be defined as follows: 1) The Link Editor will allow specification of a library/directory in which external references may be resolved. If the external reference can not be resolved, it is left as an external reference. 2) The Link Editor will have a different user interface than the current Binder. The Link Editor will allow a user to define a link request on a single command line and will also understand a more precise link definition request which will be contained in an archive or directory (as is currently done with the Binder). Multics Technical Bulletin MTB-691 Multics C Exe. Env. Spec. 3) In the future, the Link Editor may produce what we will call a `Very Large Object' that will execute on Multics. 4) The Link Editor will produce relocatable output. 5) The Link Editor should be easy to use, and should have a set of defined defaults that may be replaced by the users as they see fit. 6. `Main_' To allow Multics to find an entrypoint within an executable unit an entrypoint named `main_' will be linked by the normal C command or by the user. If `main_' is not linked with the executable unit, Multics will enter the executable unit via the entrypoint "segname$segname". The entrypoint `main_' will be responsible for the control of the per-execution-process environment. This entrypoint will have a specific set of functions which can be defined as follows: 1) Set up cleanup handlers and abort condition handlers. 2) Initialize the heap area and stack execution environment. | 3) Convert the output of the Multics command processor into Argc and Argv. 4) Initialize the C standard I/O descriptors 0,1,2 and the I/O descriptor block. This is defined in MTB 689. 5) Call the main entrypoint within the execution unit. 6) Cleanup malloced space and close files. 7) Reset the Execution Environment. | The following sections outline each function in more detail: 6.1. Cleanup and Abort Handlers In order for the per-execution-process environment to be reset after an abort has taken place, a series of condition handlers have to be set up in 'main_'. These condition handlers will take care of freeing allocated space and closing opened files, or they will handle the returning of an execution unit to the command level after a break has taken place. MTB-691 Multics Technical Bulletin Multics C Exe. Env. Spec. 6.2. Heap and Execution Environment Initialization To allow for the creation of C default structures such as the iocb block (defined in MTB 689) the heap will be initialized in 'main_'. This will also allow for future improvements in allocation if a user can specify how much space is to be initialized at the begining of the execution unit. If the program is being entered recursively the LOT and ISOT will | have to be saved and reinitialized so that links snapped within | this execution unit are resolved to new copies of the objects. | 6.3. Convert Argc and Argv The conversion of the input line from the command processor to the Argc, Argv format will be done in 'main_'. Argc and Argv will be allocated in the heap in contiguous space. Argv points at the invocation name of the execution unit. Currently the Multics command processor does not have this information available. Changes will be made to cu_ and the command processor that will allow the command name to be retreived. For a more detailed description see the Mtb entitled "Changes to the Command Processor Required by C". This implies that calls to C main routines should be done only via the C system call or by cu_$cp elsewhere. 6.4. Initialize I/O Structures The iocb block will be allocated in the heap to allow it to be reallocated by the user. Included in this is the initialization of indexes 0, 1 and 2 to be the IOCB pointers to stdin, stdout and stderr. 6.5. Call main The entrypoint main in the execution unit will be called with the parameters Argc and Argv. 6.6. Cleanup of Space and Files 'Main_' will set up a method for freeing allocated space and resetting the per-execution-process environment upon exit under normal circumstances. Multics Technical Bulletin MTB-691 Multics C Exe. Env. Spec. 6.7. Reset Execution Environment If the routine was entered recursively the LOT and ISOT will have | to be reset to the previous values to reset the external | references. | With this entrypoint included in an execution unit, the problems of operating under a per-login-process environment will be resolved. This entrypoint will ensure that the environment is reset each time it is exited or entered. The implementation of the proposed solution will be done over two versions of the compiler; the Demo version and the Production version. In the Demo version of the compiler `main_' will be implemented. This along with the current binder will allow for C programs to execute in the standard Multics environment. This implies that C external and static variables will be implemented as *system links. With C external and static variables defined as *system links the following limitations will be placed on C in the Demo version of the compiler: 1) A method is required to specify link initialization to alm. This will be defined in another MTB entitled Required C Pseudo Ops for Alm. 2) Execution units will have to be self contained; no guarantee will be given that initialization will be done across execution units. 3) The user must ensure that the C library is second in the standard search rules after their current working directory. The Production version of the compiler will include the use of the Link Editor to resolve library conflicts and external storage definitions. `main_' will be responsible for initializing the LOT and ISOT tables if it was called recursively. It will save the current values of the LOT and ISOT and will then set the entries to lot_fault. With this in place when a C execution unit is called recursively the lot_fault will force the combined linkage section to be copied out reseting all external references including *system links. `main_' will reset the LOT and ISOT entries on exit resetting the environment. Again, the proposed solution for C is a coordinated use of `main_' and the new Multics Link Editor. At this point no attempt will be made to propose a solution for tasking, as we feel that tasking is a function of the operating system and not a function of the C language.