CA2074615A1 - Method and apparatus for compiling code in a computer system having a limited number of registers - Google Patents

Abstract

AN IMPROVED METHOD AND APPARATUS FOR COMPILING CODE
IN A COMPUTER SYSTEM HAVING A LIMITED NUMBER OF REGISTERS

ABSTRACT

Computer software developers have avoided using register oriented linkage conventions in systems having a limited number of registers where the programs to be compiled may include an indeterminate number of parameters of differing types. By creating a formal parameter descriptor with each call being processed that includes an indeterminate number and type of parameters, the program may be compiled using a register oriented linkage convention. The formal parameter descriptor is located in a location accessible to the executing subprogram but unaffected by it. The invention is particularly useful for compiling unprototyped C language programs using processors having limited registers such as the Intel? 80x86 processors.

Description

CAg-92-00~

AN IMPROVED METHOD AND APPARATUS FOR COMPI~ING CODE
IN A ~OMPUTER SYSTEM H~ING A LIMITED NU~BER OE REGISTERS

BACKGROUND OF THE INVENTI~N

The present invention relates to methods for compiling code in a computer system and more particularly to a method for improving the execution performance of subroutine or function parameter transfers when executed on computer systems having limited register resources.

At the present time, software architec-ts, when defining rules to make efficient use of a particular computer, define what are known as "suhroutine linkage conventions". ~hese conventions define how parameters are passed between subroutines or functions. Subroutine linkage conventions are generally classified into one of two categories. A memory oriented convention uses addressable memory units known to both routines to hold parameters during a call from one subroutine to another. A register oriented convention uses the registers available in the processors to hold the parameters. Software architects will usually select register oriented linkage conventions before the memory orien-ted conventions since most modern processors can perform operations faster when not re~uired to access operands in memory.

Register oriented linkage conventions have their limitations. Processor registers are much scarcer than memory in a computer system and some language protocols permit calls to subroutines or functions which may receive a number of parameters in excess of the registers available in the processor. When this occurs, the local linkage model used will be either a memory oriented convention or a mixture of the memory oriented and register oriented conventions. An example of processors which have a limited number of reyisters are -the Intel~ 80x86 family of processors.

At the present time, compilers for the C programming language targeting the Intel 80x86 family of processors implement a subroutine linkage convention which is defined by the 3~6 Intel ABI (Application Binary Interface~. This convention is a memory oriented linkage convention. There are two primary reasons for this decision. First, the small number of registers i.n the Intel processors limits the potential ability inherent in register oriented conventions to pass parameters more efficiently than is possible with memory oriented conventions. Second, the C language contains cons-tructs that may cause a register oriented linkage convention to function incorrect].y and thereby cause abnormal behavior of otherwise well behaved programs.

However, there are available some C compilers for the Intel processors that support register oriented linkage conventions. The MicrosoftlM 6.0 C compiler uses a Pascal linkage convention which requires that the C language program be written so that it conforms with the requirements of the Pascal linkage convention. Accordingly, while the Microsoft 6.0 C compiler uses a register linkage convention it cannot handle C language programs that have not been written to the Pascal linkage convention. The Watcom~ C
compiler uses a register linkage conven-tion but restricts its use io programs which conform -to the ANSI standard for C
programs. When this linkage convention is used with the large body of K~R styl.e C programs, previously functioning programs may behave incorrectly. Since the vast majority of C code is written in the K~R style~ this restriction on the use of a register linkage convention is significant.
Furthermore, it puts the burden oE choosing a linkage convention that provides the bes-t and correct behavior on a user who may not be the original author of the program and, therefore, is not conversant with al] the idiosyncrasies of the program.

This invention permits a compiler to enhance the performance and reduce the code size of programs through the implementation of a combination of register and memory oriented linkage conventions which do no-t produce abnormal behavior in programs which embody -them. Further, it defines a framework for defining a subroutine linkage convention CA9--92-002 3 ~ ~ 7 ~
"

which makes full use of the registers in areas previously regarded as unworkable.

FIELD OF T~E INVENTION

Programming languages like FORTRAN and PASCAL require type conformance be-tween subroutine parameters. For languayes such as these, register oriented linkage conventions are easily implem~nted. The C language does not require type conformanca between subroutine parameters and as a result much of the C language programming in existence cannot be compiled to be correct and efficient using a register oriented linkage convention for an archi-tecture such as that available in the INTEL 80x86 family of machines. The American National Standards Institute has recently adopted a standard ANSI X3.159~1989 which encourages, but does not mandate, the use of function prototypes which provide a compiler with conformant type information about subroutine parameters in much the same manner as mandated by FORTRAN
and PASCAL standards. However, this standard will not affect the large body of already existing non-prototyped C code which currently must be compiled using -the memory linkage conven-tions to ensure proper behavior of the code.

In any register oriented linkage convention, actual parameters are loaded into the machine reglsters using a set of consistently applied rules. These rules are constructed in such a way as to make it possible or the subprogram called and the subprogram executing the call to contain code to reference and to pass function parame~ers in a consistent manner.

By contrast to prior implementations of register oriented linkage conventions, -the present invention describes an additional set of constraints which, when implemented in a compiler, allow a linkage convention that uses registers to be safely applied to all valid programs writ-ten in the C
language. In addition, this invention describes a mechanism for enabling a compi1er to communi.cate parameter type conformance information between executillg subprograms.

By application of the inven-tion, it is possible to implement efficient linkage conventions using registers on machines with limited register resources. Additionally this invention can provide a mechanism for more efficient use of the machine resources normally active during calls to subroutines or functions.

DESCRIPTION OF '1~ DRA~INGS

Figures 1 to 7 illustrate the stack and register contents at different call points in an exemplary C source frayment.

D~SCRIPTION OF THE INVENI'ION

To facilitate the descrlption of this invention, the following terms are defined. Many of these terms are well understood in the fie:Ld of compilers, while others have specific application to this invention.

"Actual Parameter": The data passed as a parameter by the subprogram executing the call to the subprogram called in a specific instance of a call.

"Alias": A term applied to the relationship which exists between two or more distinct operands which by some mechanism, usually pointer manipulation, become indistinguishable.

"Ellipsis": An ANSI C construct in the "parameter_type_list"
of a function declaration that identifies the function as accepting an unknown number o~ parameters o unknown type.
It is an ANSI C requirement that the "ellips.is" be the last parameter in the li.st and that there must be at least one parameter of known type declared prior to the "allipsis" in the "parameter_type_list".

"Eyecatcher": Th.is is a fragment of code or data which is uniquely placed and accessib].e by subprograms called. The eyecatcher contains a record of the placement of the parameters and the type o~ subprogram parameters during a Call.

"Formal Parameter": The declaration of a func-tion parameter as viewed from the subprogram called.

"Home Location": The storage locatlon, typically in the local stack frame of the called subprogram, reserved for an actual parameter that has heen passed in a register. A home location exists for each parameter processed in a register.

"Parameter_type_list": An ANSI C grammar construct in the language definition which provides information -to a compiler about the number and type of parameters passed to a particular subprogram.

"Point of Call": The place in an instruction stream immediately prior to the machine instruction which performs the transfer of control to ano-ther subprogram.

"Prologue": Code which exists at any entry point to a subprogram which typically performs such administrative tasks as allocating a ].o~al stack frame for local automatic variables, or estab].ishing a base of addressability to parameters and loca]. au-tomatic variables.

"Prototype": A statement in the C programming language which describes the number and type of subroutine parameters and ~he type of the return value, if one exists.

"Save/Kill Sets": By convention, the processor s register set is divided into two mutually exclusive groups defined by a linkage conventi.on. Those which must be preserved across a subprogram boundary are members of the "saved" register set, while those which may be used freely are members of the "killed" register set.

Register linkage conventions on the Intel 80x86 machine have been unable to guarantee that programs written without prototype declarations will work properly when using functions that take a variable number of parameters. This is because the function itself doesn t know how many parameters are being passed or even their types, so it doesn t know whether a given parameter was passed in a general purpose register, a floating point register or in memory. It must determine this in order to work correctly as designed.

Our proposal solves this problem by leaving an encoded description of how the parameters were passed for each call to a function. If the function is one that takes a variable number of parameters, it can, when necessary, consult this information to find out where its parameters can be found.
This, along with a set of rules that are adhered to by both the calling function and the called function in passing the parameters, allows US -to guarantee that all valid programs in the C language work as expec-ted when using a linkage convention that uses registers to pass at least some of the parameters.

In any register oriented linkage convention, actual parameters are loaded into the machine registers using a set of consistently applied rules. These rules are constructed in such a way as to make it possible for the subprogram called and subprogram executing the call -to reference and to pass function parameters in a consistent manner. This invention describes an additional set of constrain-ts which, when implemented in a compiler, allow a register oriented linkage convention to be safely applied to all programs compiled for the C language. In addition, this invention describes a mechanism for a compiler to communicate parameter type conformance information between executing subprograms.

The following rules define a register oriented linkage convention. Application of these rules would enable the present invention Subroutine parameter passing is enhanced by application of the invention when embodied within a register oriented linkage convention.

1. Define the register partitioning with respect to the placement of the hardware registers into either the save or kill set.

, ~74~ ~

2. Define the register usage for return values from functions of various return types.

3. Partition the formal parameter declarations into the various register classes based on type. Parameters are passed using the processor s registers which are appropriate for evaluatincJ expressions of equivalent type. For example, if the type of parameter is such that its value would normally be evaluated using the floating point registers then it wi.ll be passed in a floating point register. Alternatively, a general purpose register would be used for ordinal valuad expressions.

4. When a subprogram transfer of control occurs and, if required as a result of source code context, determine the contents of a formal parameter descriptor, known as the eyecatcher. This eyecatcher, when encoded, enables the location and type of parameters passed during the call to be determined.

5. When a subprogram transfer of control occurs, establish the actual parameters into the corresponding hardware registers.

In a practical implementation of the invention the following constraints were applied to define an implementation of the register linkage convention for an Intel 80x86 targeting C
compiler which embodies this invention.

Rule ~1: Partitioning t~e S~ve and K.ill Sets of Registers When writing proyrams for the C Language a set of general purpose registers must ~e preserved across the call boundaries. In this example, which uses an Intel 80X86 processor, the registers identified as being members of the save set are the registers EBX~ EDI and ESI. The remaining reyisters form a second set of registers which may be used freely. These are known as the kill set of registers. In the present example of the Intel 80X86 processor, the kill set is identified as the registers E~X, EDX and ECX. This ~ 3 corresponds to the save/kill set description ~Jhich is defined by INTEL in the:ir Application Binary Interface ~ABI).

The floating point coprocessor (Intel 80x87) used in the present embodiment of the invention has eight floating point registers. The floating poi.nt reglster stack may contain up to four floating-point parameter values at the time of entry into the subprogram called. These values may be freely modified. The remaining four floating-point registers are guaranteed empty and may be modified by the subprogram called. Any lin}~age convention using the 80x87 coprocessor, which preserves floatinq point registers across subprogram or call boundaries, would have to employ extensive interprocedural analysis to maintain program correctness, which is beyond the scope of most of todays compilers.
Hence, in this implementation, no floating point registers are preserved across calls.

Rule ~2: Define Regi~ter Usage Return Value~

The general purpose register EAX wlll contain the return value of functions which return values of non-floating arithme-tic types. For aggregate return types, the address of the returned aggregate is contained in EAX.

The C floating type return values are returned on -the Intel 80x87 top of stack (ST~O)) in 80-bi-t(ten byte) precision format with no other registers being active at the point of return. FORTRAN complex type return values are returned in 80-bit precision format in the two 80-bit precision registers ST(O) and ST(l).

Rule #3: Formal Parameter Partiti.oning General purpose regis-ters RAX, EDX and ECX are used to receive the first three non-floating point parameters of the call. These parame-ters are assigned -to the registers in the order EAX, EDX and EC~ starting with the lexically leftmost non-floating point parameter. Although the actual parameters exist only in the appropriate registers at the point of CA9-g2-002 9 ~ 3 call, a corresponding portion of stack storaye i.s allocated to each of the formal parameters in the registers so as ts maintain address consisterlcy with the remainder of the parameters. This is the allocation of the home location. As the general purpose registers in the Intel 80X~6 processor are 32 bits long, a corresponding four bytes of stack storage at a Home Location is assigned for each register allocated to a parameter.

For the purpose of this implementation, a conforming parameter is any integra]. or pointer valued parameter. An alternate implementation which includes aggregate types could be implemented and a possible implementation is shown in Figure 3.

If there is no known prototype for the function being called, an eyecatcher is placed after -the CALL instruction.
The eyecatcher describes the correspondence between register usage and the home location in the stack where the parameter would have been placed if it had not been put in the register. The eyecatcher need only be interrogated by called subprograms with known alias relationships within their parameter lists.

If a prototype is visible which contains an ellipsis, then only the invariant portion of the formal parameter list, that prior to the ellipsis, is eligible for placement of actual parameters into registers. If an eyecatcher were used here it would then be possible to pass parameters from the varying portion of the parameter list in registers subject to their eligibility under the previous rules. All functions with an ellipsis in their parameter list would then have to consult the eyecatcher to determine the locations and types of the parameters in the varying portion of the list. For our particular implementation, we have chosen not to attempt to put parameters which are passed to the ellipsis port.ion into registers. This is analogous to the decision we made not to pass structures/aggregates in registers in our preferred embodiment even -though we have provided an example where the structures/aggregates were passed in registers.

CA9-92-002 10 ~4 ~ , These are choices that must be made when implementing the invention but are not essential to the implementation of it In our embodiment using the Intel 80X87 processor, the first four floating point registers can be used to pass up to the first four actual floating point parameters in the parameter list. The parameters are passed in 80-bit precision format as this is the internal precision of the 80X87 machine. The lexically leftmost floating point parameter is held in register ST(0) (top of the register stack), the next leftmost in register ST(l), the next in register ST(2) and the last that can go into the floating point registers in register ST(3). A corresponding portion of the memory stack is allocated to maintain home location alignment for each parameter.

For calls to A~ISI C functions declared with prototypes the rules governing the placement of actual parameters into registers are sufficient to ensure that the subprogram called can always deduce which parameters the subprogram executing the call has placed into which registers without consulting an eyecatcher.

The parameter types that are eligible to be passed are separated into two groups that correspond to the two types of registers used for value transfers. All non-floating type parameters are eligible to be passed in the integer registers that are reserved for passing parameters. All floating type parameters are eligible to be passed in the floating point registers reserved for passing parameters.
In the preferred embodiment of the invention, aggregates or structures passed by value are not eligible to be passed in registers, even though their overall size may have permitted it However, Figure 3 cloes illustrate an example of how aggregates could be passed in registers if considered desirable. Furthermore, when there is an ellipsis in the parameter list of the function, only parameters occurring lexically to the left of the ellipsis are eligible to be passed in registers. This restriction, applicable to ellipsis parameters, results in fewer eyecatchers being generated after calls, and fewer actual parameters passed in CA9-9~ 2 11 registers, when calling functions which are likely to have alias relationships hetween the actual parameters.

For calls to C functions having no prototype, the eligibility of parameters to be passed in registers is the same as above, except that, since -there are no ellipsis declarations, the subprogram execut:ing the call considers all actual parameters as eligible for registers.
Furthermore, since, in most cases the subprogram executing the call is unable to determine whether the subprogram being called needs to consult an eyecatcher to discover the parameter-register mapping for this particular call, an eyecatcher must be built. However, it should be recognized that there are instances when the compiler may deduce that a func-tion defined in the curren-t compile unit does not consult its eyecatcher and thereby may safely elide the eyecatcher.

From the point of view of the subprogram called, the eyecatcher must be consulted whenever the address of a parameter is taken within the body of the subprogram called.
This makes the assumption, which is always safe, that the reason the address of a parameter was taken was to establish an alias relationship with the remainder of the parameter list via the pointer which is so established. These are usually functions which, if prototyped, would have a trailing ellipsis in their parameter lists. When a function aliases the actual parameters, the compiler inserts code in the prologue of the function to examine -the eyecatcher and, using the information provided therein, restore the register parameters to their home locations By the above constraints, eyecatchers need only be applied to unprototyped calls, however, when choosing an appropriate eyecatcher the following behavior ought to be considered.

First, if the eyecatcher is to appear in the instruction stream and executed as part of the normal execution process then it ought to be an instruction which cloes not modify the operands which it references. It should be noted that an executable eyecatcher implementation precludes the use of CA9-92-002 12 ~7~

execute-only code segments. A dlfferent mechanism, for example, using s-torage at pre--defined offsets in the static storage or local stack frame of the subprogram, would be necessary to support execute-only code segments.

Second, the eyecatcher must be uniquely detectable either by placement or convention.

Thirdly, if the eyecatcher is placed in writable storage, care must be taken to avoid its unintentional des-truction.

In this implementation the eyecatcher instruction was chosen to follow the CALL instruction. In our preferred embodiment we developed the eyecatcher in the form of a TEST
instruction. We selected the TEST EAX,Imm32 or the equivalent "A9,Imm32" as best suited to the functionality required of the eyecatcher. The value of the Imm32 operand of -this instruction, is a 32-bit encoding of the actual parameters using a sequence of 2-bit fields. The two most significant bits of the operand refer to the lexically left most parameter in the instruction being called. Each successive field ref]ects -the next lexical parameter position. With the 32 blt field, a description of up to sixteen formal parameter positions ls possible.

For example, an eyecatcher can be built and placed immediately after the CALI, instruction. The choice of the TEST instruction, its presence immediately after the CALL, the two bit tags, the meaning associated with the tag values, the choice of registers, the size of the corresponding home location, etc. are all implementation specific items which describe our preferred embodiment of the invention for use on an Intel processor. Other processors or choices could be made, if desired, in implementing our invention.

The following table describes the meaning of the various possible field values used to make up the eyecatcher operand.

'3 Value Interpretation 00 Two bits of the eyecatcher which indicate that a four byte slot at the home location is an actual parameter and is located in this home location in the stack and not in any register. This can be used, for example, to skip over small structures. When all remaining unprocessed fields of the eyecatcher are zero there are no remaining actual parameters in registers. This allows the implementation to employ an "early out test"
in the prologue code to avold unnecessary processing.

01 This coding of two bits would indicate a four byte slot defining the home location for an actual parameter whose value is in a yeneral purpose register. The identity of the particular register holding the parameter would be determined by the position of the bits in the eyecatcher itself. For example, if a previous two bits had identified a general purpose register EAX as holding a parameter, then the current two bits would indicate that the general purpose register EDX holds this parameter.

This codin~ of two bits would .indicate an eight byte slot defining the home location for an actual parameter whose value is in a floating-point register. Floating point registers in the 80x87 stack zero through three (zero is the top o:E stack), will contain the lexically first four actual floating-point paxameters.

11 This coding of two bits would indicate a sixteen byte slot defining the home location for an actual parameter whose value is in a floating poin-t register. This is the double word length form of the floating point parameter. The distinction based on size of home location allows for efficient handling of the C
floating type "long double". Although the point register is only 10 bytes wide it is necessary to allocate 16 bytes in the stack to maintain address alignment of the stack.

CAg-92-002 1~ 2 The following C source fragment can be used to illustrate the various aspects of this implementation which might occur within a particular source module.

s-truct s ~
double fl;
int il;
~ ss;
extern int pl(int,int,double,double);
extern int p2(char *,...);
extern int p3(struct s,int,int,double);
extern double p~(long double);
extern int p5(),p6();
/* some K&R like non-prototyped function */

void foo()~
a=pl(10,20,10.0,20.0);
a=p2("1ike ANSI printf %d %f\n",10,10.0);
a=p3(ss,10,20,10.0);
f=p4((long double~10.0);
a=p5(20,10,10.0); /* eyecatcher present on this call */
a=p6(0,10); /* eyecatcher present on this call */
}

Figure 1 shows the stack and register contents at the point of call to procedure pl in the ~ source fragment. Contents of the memory stack between ESP and -the subprogram executing the call (foo s) local storage is undefined. As illustrated in Figure 1, -the first parameter 10, which is the first non-floating point parameter in the instruction, is placed in the first available register EhX. To maintain stack addressability, a 4 byte slot in the stack is set aside to represent the first parameter, although the parameter is not actually placed in the stack at this time. The next parameter, 20, which is also non-floating point, is placed in the next available register, EDX, and another ~ bytes of 'che stack are allocated to this parameter to maintain address conformity in the stack. The next two parameters are floating point and require ~0 bits of storage. They are stored in the -two floating point registers ST(0) and ST(l) as indicated in Figure 1. As each double requires more than CA9~92-002 15 ~7~
32 bits (4 bytes), at least that much storaye in the staGk must be allocated to them. As -the stack is subdivided into 4 byte addressable groups, two 4 byte groups are allocated to each of the floating point parameters put in registers ST~0) and ST(l) as shown in Figure 1.

As the procedure pl is well defined, it does not require an eyecatcher to identify the parameters to the calling subprogram. The parameters all go into regis-ters in the sequence in which they are ca].led.

Figure 2 shows the stack and register contents at the point of call to procedure p2 in the C source fragment. With procedure p2, only those parameters before the ellipsis are eligible to be passed in registers. Accordingly the ~"string" is put in register EAX and the first 4 byte slot in the stack reserved for lt. The remaining parameters are put into the stack and none of the other registers are used to pass parameters for procedure p2. Contents of the memory stack between ESP and the beginning of the ellipsis portion, located at the start of the 2nd 4 byte portion of the stack, of the parameter ].is-t i9 undefined.

Figure 3 shows the stack and register contents at the point of call to procedure p3. In this example, the structure portion of the procedure p3 is passed partly in the general purpose registers and partly in the fioating point registers. The other parameters , 10, 20 and 10.0, are also passed in the registers, as shown in Figure 3. The contents of the memory stack between ESP and the particular subprogram executing the call, in this example foo s, local storage is undefined. As shown, the first 28 bytes of the stack are undefined.

Figure 4 shows the stack and registe:r contents at the point of call to procedure p3 uslng an alternative implementation for structure or aggregate support. In this implementation structures or aggregates are not el~gible to be passed in registers. As shown in Figure ~, -the s-tructure fields ss.fl and ss.il are placed directly in the stack. The floating point structure field ss.fl occupies the first ~ bytes of C~g-92-002 16 ~ ~p~

the stack and the integer structure field ss.il occupies the next four bytes of the stack. The parameters 10, 20 and 10.0 are placed in registers EAX, EDX and ST(0), respectively.
Contents of the memory stack between ESP and the proyram executing the cal]. (foo s) local storaye is undefined.

Figure 5 shows the stack and register contents at the point of call to procedure pg. As the procedure p4 only has the long double parameter 10.0~ this can be put in the register ST(0). However, as the long double uses up to 80 bits, sufficient stack memory must be allocated to maintain stack addressability. Accordingly, 16 bytes of stack is allocated, as shown in Figure 5. The contents of the memory stack between the E~P and the local storage of foo is undefined.

Figure 6 shows the stack and register contents at the point of call to procedure p5. As the number of parameters for procedure p5 is undefined, an eyecatcher must be created for it to enable the parameters to be passed without a problem.
In the actual example shown for procedure 5, the parameters to be passed are 20, 10 and 10Ø The 32 bit eyecatcher needed to indicate that these 3 parameters are being passed in registers EAX, EDX and ST(0) is 01011000000000000000000000000000. As shown in Figure 6, the contents of the memory stack between ESP and the local storage of foo is undefined as it ls usecl to maintain the ability to access the stack.

Figure 7 shows the stack and register contents at the point of call to procedure p6. The number of parameters in procedure p6 is also unspecified and, therefore, an eyecatcher must be defined to enahle the procedure to access the appropriate parameters. In the particular example illustrated in procedure p6, only two parameters are actually passed and they are both integers so the eyecatcher would be 01010000000000000000000000000000. The parameters would be put in registers EAX and EDX and the contents of the first 8 bytes of the memory stack between ESP and the local storage of foo would be undefined.

Claims (10)

1) In an improvement for a method for compiling a computer program, the steps of:

identifying Calls within said program to be compiled which include parameters having a type and location within the Call that may be inexplicit;

creating a formal parameter descriptor for each said parameter having an inexplicit type and location, said formal parameter descriptor explicitly defining said location and type for each inexplicitly defined parameter passed during said call.

2) In a method for compiling a computer program as defined in Claim 1, the additional steps of:

partitioning said parameters into register classes, said register classes being determined by the type of said parameter, passing said parameters in available registers in accordance with the type of the said parameter.

3) In a method for compiling a computer program implementing a register oriented subroutine linkage convention, the steps of:

partitioning registers into a first set and a second set wherein said first set is a save set and said second set is a kill set, defining register usage for return values from functions, said values being determined by a return type of said function, partitioning formal parameter declarations into register classes, said register classes being determined by a type of said parameter, determining contents of said formal parameter descriptor when required, and establishing parameters into corresponding hardware registers used to pass subprogram parameters.

4) An invention as defined in claim 2 or claim 3 wherein said formal parameter descriptor is in an instruction stream of an executing process.

5) An invention as defined in claim 2 or claim 3 wherein said formal parameter descriptor is in a predefined storage location local to an executing subprogram.

6) An invention as defined in claim 2 or claim 3 wherein said formal parameter descriptor is in a predefined storage location globally available to an executing program.

7) An improvement in a compiler for compiling programs in a computer having a plurality of processing registers and a stack storage, said improvement comprising:

means for identifying Calls, said Calls including parameters to be passed in which a type and location of the parameters within the Call may be inexplicit; and means for defining a formal parameter descriptor for each Call in which the location and type of said parameters are inexplicit, said formal parameter descriptor explicitly defining the type and location of each parameter transferred during each such said Call.

8) An improvement in a compiler for compiling programs as defined in Claim 7 further including:

means for accessing said formal parameter descriptor when said Call is active and the location and type of parameters within said Call cannot be determined from within the Call itself.

9) An improvement in a compiler for compiling programs as defined in Claim 7 or Claim 8 further including:

means for maintaining home location alignment in a stack storage while transferring at least some of said parameters in said selected registers.

10) An improvement in a compiler for compiling programs as defined in Claim 7, Claim 8 or Claim 9 further including:

means for allocating selected registers in said computer to receive parameters to be transferred during a Call.