CA2167306C - Multiple entry point method dispatch - Google Patents
Multiple entry point method dispatch Download PDFInfo
- Publication number
- CA2167306C CA2167306C CA002167306A CA2167306A CA2167306C CA 2167306 C CA2167306 C CA 2167306C CA 002167306 A CA002167306 A CA 002167306A CA 2167306 A CA2167306 A CA 2167306A CA 2167306 C CA2167306 C CA 2167306C
- Authority
- CA
- Canada
- Prior art keywords
- field
- code
- function
- entry point
- prolog
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Lifetime
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/448—Execution paradigms, e.g. implementations of programming paradigms
- G06F9/4488—Object-oriented
- G06F9/449—Object-oriented method invocation or resolution
Abstract
The invention is a new object construct (40) that allows a functional object in a dynamic language to be efficiently used as both a directly-invoked function and as a method in a generic function. To accomplish this use, the new object construct comprises four dis tinct but related contiguous storage regions designated as a header (41), a meth-info field (42), a fn-prolog field (43), and the method b ody (44). When called as a component of a generic function, one entry point is at the method body or at the method-information field. When cal led directly, another entry point exists at the function prolog field.
Description
94/OG~6$
~. ~ 7 ~ ~ '~ ~P~/~S 1 '. FE8 199 A SYSTEM AND METHOD FOR MULTIPLE ENTRY
POINT ACCESS TO AN OBJECT
- This invention relates to a computer programming language construct, and a 5 system and method for using such construct.
Many computer languages used for program development are so-called static language, in which most of the information about objects is discarded during compilation, so programs cannot be modified without recompilation. Dynamic languages, on the other hand, are much more flexible and allow certain actions to be taken at runtime that could not be accomplished with a static language. A
popular example of a dynamic language is Common Lisp (CL). In addition, there is a strong trend toward object-oriented dynamic languages, which include Common Lisp Object System (CLOS) and Dylan as examples.
Some object-oriented languages generally provide generic function constructs.
Generic functions are a class of objects used for performing actions, and correspond generally to functions and procedures of other languages. Generic functions typically contain multiple methods. Such methods typically contain a typed argument list and a code body. In Dylan, for example, a generic function contains a number of methods.
When you call a generic function with certain arguments, the generic functions uses the classes and identifies of the arguments to determine which of the multiple methods to call. This process is called method dispatch.
When a programmer defines a method, he or she specifies the classes or identifies of the arguments appropriate for the method. This is called specializing the method. A method can only be called with arguments that match the specializers of the argument list. In the most common case, the specializer is a class, and the corresponding argument must be a general instance of the class. When the specializers -of a method match a set of arguments, the method is said to be applicable to the arguments. When the generic function is called, the arguments ~,;...='.~='~ ~'.'==T
,, , ~~
~ 1 fi ~ 3 O ~ IPEA/US ~ r FEB l~~s are compared to the specializers of all the method in the generic function.
The method with the most appropriate is run.
In a dynamic language, the type of an object being called is generally not known at compile time. Therefore, the code to call a functional object must be compiled in such a way as to work for all types of functions. This is typically done by having all functional objects entered in the same way, by having a single entry point at a fixed offset which is the same for all types of functional objects. When the compiler is compiling a function call, it will arrange to enter the object at that fixed offset.
CL has three types of functional object: generic functions, ordinary functions and methods. An ordinary function cannot be added to a generic function. A
method cannot be invoked outside of a generic function, except in the very restricted context of method combination, and then only using specialized syntax. Aside from these restrictions, ordinary functions and methods provide the same functionality to the user;
hence, the distinction between them is an unnecessary complication of the language.
SUMMARY OF THE INVENTION
An object of the invention is a new language construct that simplifies the language semantics of a dynamic language.
Another object is a language construct for generic functions and methods that simplifies invocation of these objects.
In accordance with an aspect of the present invention, a novel construct for a method object is provided. By constructing the method object in accordance with the invention, it allows a functional object in a dynamic language to be efficiently used as both a directly-invoked function and as a method in a generic function. This allows a language to combine the two concepts, simplifying the language semantics.
~. ~ 7 ~ ~ '~ ~P~/~S 1 '. FE8 199 A SYSTEM AND METHOD FOR MULTIPLE ENTRY
POINT ACCESS TO AN OBJECT
- This invention relates to a computer programming language construct, and a 5 system and method for using such construct.
Many computer languages used for program development are so-called static language, in which most of the information about objects is discarded during compilation, so programs cannot be modified without recompilation. Dynamic languages, on the other hand, are much more flexible and allow certain actions to be taken at runtime that could not be accomplished with a static language. A
popular example of a dynamic language is Common Lisp (CL). In addition, there is a strong trend toward object-oriented dynamic languages, which include Common Lisp Object System (CLOS) and Dylan as examples.
Some object-oriented languages generally provide generic function constructs.
Generic functions are a class of objects used for performing actions, and correspond generally to functions and procedures of other languages. Generic functions typically contain multiple methods. Such methods typically contain a typed argument list and a code body. In Dylan, for example, a generic function contains a number of methods.
When you call a generic function with certain arguments, the generic functions uses the classes and identifies of the arguments to determine which of the multiple methods to call. This process is called method dispatch.
When a programmer defines a method, he or she specifies the classes or identifies of the arguments appropriate for the method. This is called specializing the method. A method can only be called with arguments that match the specializers of the argument list. In the most common case, the specializer is a class, and the corresponding argument must be a general instance of the class. When the specializers -of a method match a set of arguments, the method is said to be applicable to the arguments. When the generic function is called, the arguments ~,;...='.~='~ ~'.'==T
,, , ~~
~ 1 fi ~ 3 O ~ IPEA/US ~ r FEB l~~s are compared to the specializers of all the method in the generic function.
The method with the most appropriate is run.
In a dynamic language, the type of an object being called is generally not known at compile time. Therefore, the code to call a functional object must be compiled in such a way as to work for all types of functions. This is typically done by having all functional objects entered in the same way, by having a single entry point at a fixed offset which is the same for all types of functional objects. When the compiler is compiling a function call, it will arrange to enter the object at that fixed offset.
CL has three types of functional object: generic functions, ordinary functions and methods. An ordinary function cannot be added to a generic function. A
method cannot be invoked outside of a generic function, except in the very restricted context of method combination, and then only using specialized syntax. Aside from these restrictions, ordinary functions and methods provide the same functionality to the user;
hence, the distinction between them is an unnecessary complication of the language.
SUMMARY OF THE INVENTION
An object of the invention is a new language construct that simplifies the language semantics of a dynamic language.
Another object is a language construct for generic functions and methods that simplifies invocation of these objects.
In accordance with an aspect of the present invention, a novel construct for a method object is provided. By constructing the method object in accordance with the invention, it allows a functional object in a dynamic language to be efficiently used as both a directly-invoked function and as a method in a generic function. This allows a language to combine the two concepts, simplifying the language semantics.
A",~~;.'~rD ~'-;~ET
In essence, a single method object is created that can be directly invoked as well as invoked when a generic function is called, by providing multiple entry points to the method object.
In a preferred embodiment, the method object construct of the invention comprises a header, a method-information (meth-info) field of fixed size at a fixed offset from the header and including as information the offset of the method body, a function prolog (fn-prolog) field of variable size at a fixed offset from the meth-info field, and finally the method body of variable size. The method object can have multiple entry points, at the fixed offset of the fn-prolog field, or at the offset of the method body as determined by computation.
The multiple entry points allows the passing of more information on generic function dispatch, or the avoidance of certain tasks deemed unnecessary. As one example, entering the function at a first point may involve type-checking of function arguments and certain bookkeeping activities, whereas entry to the same method at a second point may avoid or by-pass type-checking and bookkeeping tasks.
More particularly, according to one aspect the invention provides a process of using a method object stored in a memory of a computer, said method object configured for operation by a processor in accordance with a dynamic object-oriented programming language, said process comprising the steps of: creating said method object comprising a method-information field stored at a fixed location relative to a starting memory location of said method object and a variable size method body of program code stored at another location, said method-information field containing an offset identifying the location of said method body; executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and entering said method object at one of a first entry point to directly invoke said method body in response to execution of the ordinary function call and a second entry point to invoke said method body in the context of a generic function dispatch in response to execution of the generic function call, wherein said first entry point is different from said second entry point and other than the location of said method body, said first and second entry points enabling the processor to execute the program code contained in the method body.
According to another aspect the invention provides for use with a dynamic object-oriented computer language used to specify code for execution by a central processing unit of a computer, a process of using a method object stored in a memory of the computer, said process comprising the steps of: (a) creating the method object having a fixed size header, a method-information field of code stored at a fixed offset from the header, a variable size function-prolog field of code stored at a fixed offset from the header, and a variable size method body of code stored at a given offset from the header, said method-information field containing the given offset of the method body; (b) executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and 3a one of, (c) directly invoking the method object by entering the method object at a first entry point at the function-prolog field in response to execution of the ordinary function call and executing the code of the function-prolog field, and (d) invoking the method object in the context of a generic function dispatch by entering the method object at a second entry point at the method-information field in response to execution of the generic function call and executing the code of the method-information field.
According to yet another aspect the invention provides for use with a dynamic object-oriented computer program language used to specify code for execution by a central processing unit of a computer, apparatus for using a method object stored in a memory of a computer, said apparatus comprising: means for creating said method object having a method-information field of code stored at a fixed location relative to a starting memory address of said method object, a variable size function-prolog field of code stored at another fixed location relative to the starting memory address, and a variable size method body field of code stored at a predetermined location relative to the starting memory address, said method-information field containing an offset identifying the predetermined location of said method body field; means for executing one of an ordinary function call and a generic function call during run time to invoke said method body field of code; and one of, means for directly invoking said method object by entering the method object at a first entry point at the function-prolog field in respanse to execution of the ordinary function call and means for executing the code of the function-prolog field; and means for invoking said method object in the context of a generic function dispatch 3b by entering the method object at a second entry point at said method-information field in response to execution of the generic function call and means for executing the code of the method-information field, wherein said first and second entry points enable the central processing unit to execute the code contained in the method body.
According to still another aspect the invention provides an arrangement for using a method object in accordance with a dynamic object-oriented programming language of a computer, said arrangement comprising: a memory for storing the method object, the method object comprising: a header field having a starting memory address;
a method-information field located at a first offset from the starting memory address, said method-information field containing a predetermined address value; a function-prolog field of code located at a second offset from the starting memory address; and a method body field located at said predetermined address value from the starting memory address, said method body field containing program code for execution by said computer, and a processor for invoking said method object in response to entering said method object at one of a first entry point and a second entry point wherein said first entry point is different from said second entry point.
The above and further objects, details and advantages of the present invention will become apparent from the following detailed description of preferred embodiments thereof, when read in conjunction with the accompanying drawings.
3c SUMMARY OF THE DRAWINGS
Fig. 1 is a block diagram of a typical computer system containing in memory, among other things, a method object in accordance with the invention;
Fig. 2A shows schematically the format of a generic function when called by a program statement;
Fig. 2B shows schematically the format of an ordinary function when called by a program statement;
Fig. 3 is a schematic view of one form of method object in accordance with the invention;
3d Fig. 4 is a flow chart indicating how code representing multiple entry points can be generated.
m~~rmr ~m nFC~mpZ'ION OF PRFFERRED EMBODIMENT
The following conceptual framework is helpful in understanding the broad scope of the invention, and the terms defined below have the indicated meanings throughout this application, including the claims.
"Data" refers herein to signals that indicate or include information. For example, data could exist as an electromagnetic or other transmitted signal or as a signal stored in electronic, magnetic, or other form.
1 o A "data processing system" is a system that processes data. A "data processor" or "processor" is any component or system that can process data.
and may include one or more central processing units or other processing components.
"Memory" is any component, combination of components, or system that can store data, and may include local and remote memory and input/output 15 devices.
A processor "accesses" data in memory by any operation that retrieves or modifies the data, such as by reading or writing a location in memory that includes the data.
A processor "operates on" data by performing an operation that includes 20 obtaining resulting data that depends on the data operated on. For example.
the resulting data could result from an operation that accesses the data operated on or from a logical or numerical operation on the data operated on.
A processor "uses" data in performing an operation when the result of the operation depends on the value of the data. Stored data can be accessed using or 25 accessible using other data if the memory containing the stored data responds to the other data or to data that depends on the other data by permitting access to the stored data. For example, the other data may be an address, an offset used to produce an address, or a content-addressable value stored with the stored data.
216~~r~6 An "instruction" is an item of data that a processor can use to determine its own operation. A processor "executes" a set of instructions when it uses the instructions to determine its operations.
Fig. 1 is a block diagram of a typical computer system for program development, comprising a workstation 10 including a console 11 containing a CPU 12, RAM memory 13, and I/O circuitry 14 for communicating with a display 1 S, mass memory 16, a keyboard 17, and the usual mouse 18 with button switches 19. The usual display 15 contains a title or menu bar 21 and a cursor 22.
Stored 25 in the memory 13 or 16 would be the usual operating system. the program being run, and assorted objects created by the program as would be typical of a program developed under a dynamic object-oriented language.
Some general information known to all those skilled in the art may also help the reader. Source code when run through a compiler generates object code.
Compilers take the textual symbolic representation of the program in the source code and provide usually via assembly code a translated, machine-usable, output file. As is common, programs are divided up into modules and library routines or include files. An executable program is produced when the object code modules are linked with the called library routines. The executable code, among other things, keeps track of variables, constants, functions and methods by allocating 2o memory locations, fixed or relocatable, where such objects are stored, and for convenience often identifies a particular object, such as an array element or structure field, as being located so many memory locations offset from some known starting point. This approach is used both for heap memory as well as for stacks. Thus, a routine designed to perform a function would be stored at a particular location in memory, and a jump table would be typically constructed by the operating system listing the name of the routine and its start address or entry point for accessing the routine. Thus, when the program includes a statement calling this particular routine by name, the operating system knows where to find the beginning of the sequence of instructions which when run will execute the ~J ~J
f FEB 1~9~
function desired. If arguments are included in the function call, the routine is run with the arguments substituted for the formal parameters of the function. For a more detailed description, see "Inside Macintosh", published by Addison-Wesley, and "How to Write Macintosh Software" by S. Knoster, also published by Addision-Wesley.
Assume, as would be normal, that the program code in an object-oriented language created a generic function and then created under that generic function methods A, B; and C, to be respectively invoked when the generic function is called with specializers A, B, and C, respectively. When a generic function method is invoked from a called generic function, it receives a hidden extra argument which is not visible to the user. This extra argument contains information about the position of this method in the applicable method chain for this invocation of the generic function.
When a function as an object separate from the generic function is invoked directly, it doesn't need and doesn't receive the hidden argument. On the other hand, when a function is invoked directly, it performs a function entry prolog (argument type-1 S checking, etc.) which it need not perform when invoked from a generic function.
Furthermore, when a function is invoked directly, the caller doesn't know whether it's invoking a method or some other kind of function. Thus, having a single general entry at a fixed offset in all functional objects allows an efficient invocation protocol.
These differences are illustrated in Figs. 2A and 2B of which Fig. 2A shows a typical generic function 30 with its chain of methods A, B, and C, designated 31A, 31B, 31C, respectively. The hidden extra argument 32 is, for example, a table of memory addresses for the three methods. When the generic function is called with a specializer that matches the parameter of one of the methods, B for example, method B
is run by the operating system being given the memory address of the method B
body.
No type checking is necessary because the offset to the body 31B of method B
would not be available to be run unless the specializer matched the method B
parameter which means its type, in essence, had already been checked.
AMF?'.~3cD ~''aET
2167~r~~
Fig. 2B shows function 33 being called directly. Since no generic function dispatch is involved, argument checking is highly desirable. Thus, a function conventionally performs argument checking as part of its body.
It will be observed from Figs. 2A and 2B that two independent objects 30 and 33 exist in memory, each with its own unique entry point address. In accordance with the present invention, a new single method object is created in memory that can be called directly, or via a generic function call, and carry out or avoid carrying out the same tasks as illustrated in Fig. 2. This new object construct is illustrated at 40 in Fig. 3, and comprises four distinct but related contiguous 1o storage regions designated as a header 41, a meth-info field 42, a fn-prolog field 43, and the method body 44. The header is the normal object header that is, however, defined by the implementation. The size of this header must be fixed, so that the following field, meth-info, occurs at a fixed offset 1 from the starting location of the header. Meth-info contains method specific information such as specializers and flags, as well as the offset of the method body (offset X
above).
The size of meth-info is fixed (any variable data are stored as fixed-size pointers to additional data structures), so that the following field, fn-prolog, occurs at a fixed offset B. Fn-prolog is variable size, so that the method body starts at different offsets in different methods.
2o The function prolog, fn-prolog, within the method object of the invention looks and behaves as follows:
1. Performs standard function entry actions as required by the language (e.g., check the number and types of arguments, poll for events, etc.). This may perform arbitrary computations, hence this field is of variable size.
2. Places the initial value of the hidden extra argument into a standard place as specified by the runtime architecture (e.g. in a dedicated register or on top of stack).
3. Falls into the method body.
WO 95102862 ~ ~ '~' ~ PCTIUS94/06868 For ordinary functional invocation, i.e., to invoke the method object of Fig. 3 directly as a function, simply jump to the fixed ~ offset B in the method object entry point I. Sample assembly code is:
LOAD method object into REGISTER
JUMP to contents (REGISTER) + B ;B is a constant The value of B is preferably the same for all method objects.
For generic function method invocation, the following steps are carried out:
1. Compute the proper value of the hidden extra argument, as specified by language semantics, given the specializer used in the call.
2. Place the hidden extra argument in a standard place as specified by the runtime architecture (e.g., in a dedicated register, or top of stack.) 3. Use the information in the meth-info field at offset A to compute the method body offset X and jump to it. This may be done in one of two ways, depending on which is faster/smaller in the target machine architecture. The value of the offset X may be fetched from meth-info 42 and added to the method address to compute the address of the method body 44. Sample assembly code is:
LOAD method-object into REGISTER1 LOAD contents (REGISTERI) + A into REGISTER2 ;fetch method ;body offset ;Aisa ;constant ADD REGISTER2 to REGISTERI
JUMP to contents (REGISTERI) Or, as an alternative, the meth-info field may contain within it a branch to the method body, and hence the method body 44 may be reached by jumping into the meth-info field 42. Sample code for this alternative is:
LOAD method-object into REGISTER
JUMP to contents (REGISTER) + A ;jump to a branch to method.
;body The value of offset A is preferably the same for all method objects.
s rt:-iIUS~ 9 4 / 0 ~ 8 6 8 ~P~/~$ 1 '- FEB 7995 2~~~~0 Fig. 4 illustrates the action that occurs when programming statements are executed at runtime with an ordinary function call or a generic function call using a method object in accordance with the invention. Each of method objects Q, R
and S
would have been created during program development and each would contain the four fields indicated in the preferred embodiment of Fig. 3, In the usual way, a jump table 50 is created with the address for each of the three method objects Q, R and S.
When encountering each program statement 52, if it is an ordinary function call of, say, method Q, then the right branch is taken and code is generated 54 that loads 55 the address of method object Q, and then jumps 56 to the B offset to entry point I (Fig.
3) to run the code 58 in the function prolog 43 and then falls through to the method body 44 and eventually returns to the caller 59.
If it is not an ordinary function call, meaning that it is a generic function call with applicable method Q, then the left branch is taken. When the operating system creates a generic function, it places some canned code (a small set of instructions to select the appropriate method and call it) inside the generic function object.
See 34 in Fig. 2A. In other words, the body of a generic function is filled with canned code by the operating system, and the compiler is not involved at all. The canned code in this case would include the instructions shown in the left branch in the figure, as follows.
The code loads 62 the address of method Q, then loads 63 in a second register the contents of address plus offset A, adds 64 the two registers together to get the address of entry point II, and jumps to the latter 65 (entry point II). The method body code is the run 66 followed by usual return. This is one way of computing then offset X to the method body 44. As an alternative, shown with the dashed lines, if the method information field 42 contains a branch to the method body, then jumping 68 to the method information 42, indicated in Fig. 3 by entry point III, will enable control following the branch to fall through to the method body 44. _ All~'~,'O:cp ,.~cf~E?
2 ~ ~6 ~ ~ c~
As has been described, the method object illustrated in Fig. 3 can be invoked in the normal way in an object-oriented language as one component of a generic function having plural method objects with the method object selected to be run determined in the normal way by the specializers in the calling statement.
So, in a simple example, a single generic function intended to apply to several argument types, such as integer, string, or vector, when called with the integer, string or vector argument will invoke the function method appropriate for that type. In this instance the entry point for the method object would be at entry point II to the method body. A typical call in Dylan would be as follows:
to (double 17) Alternatively, the method object of Fig. 3 can be used directly to, for example, perform a local calculation, or as a function that does not require class dispatch, or to build up generic functions programmatically. The format would be similar to the lambda special fonm of Lisp or to blocks in Smalltalk. A simple example is given below:
(add-twice 17) In this instance, the entry point would be at entry point I in Fig. 3.
The method object of Fig. 3 can be created in a straightforward way by creating a generic function and automatically adding the desired method to it.
For 2o the example given above, the method and generic function would be defined in Dylan by:
(define-method double ((n <integer>)) (+ n n)) Alternatively, the exact same method object of Fig. 3 can be created and used directly without being added to a generic function. This would be done by the following definition in Dylan:
(define add-twice (method ((n <integer>)) (+ n n))) This method can then be added directly to the generic function if desired, as follows:
(add-method add-twice double) 2167~0~
The invention is not limited to the above-described formats and other formats are usable. The important point is that the compiler, upon encountering either of the above formats, knows to allocate memory storage space adequate to store an instance of the method object of Fig. 3, and to preserve in, for example, a jump table a pointer corresponding to the address of the method object.
Although there have been described what are at present considered to be the preferred embodiments of the invention, it will be understood that the invention may be embodied in other specific forms without departing from the essential characteristics thereof. The present embodiments are therefore to be t o considered in all respects as illustrative, and not restrictive. This scope of the invention is indicatcd by the appended claims rather than by the foregoing description.
tt
In essence, a single method object is created that can be directly invoked as well as invoked when a generic function is called, by providing multiple entry points to the method object.
In a preferred embodiment, the method object construct of the invention comprises a header, a method-information (meth-info) field of fixed size at a fixed offset from the header and including as information the offset of the method body, a function prolog (fn-prolog) field of variable size at a fixed offset from the meth-info field, and finally the method body of variable size. The method object can have multiple entry points, at the fixed offset of the fn-prolog field, or at the offset of the method body as determined by computation.
The multiple entry points allows the passing of more information on generic function dispatch, or the avoidance of certain tasks deemed unnecessary. As one example, entering the function at a first point may involve type-checking of function arguments and certain bookkeeping activities, whereas entry to the same method at a second point may avoid or by-pass type-checking and bookkeeping tasks.
More particularly, according to one aspect the invention provides a process of using a method object stored in a memory of a computer, said method object configured for operation by a processor in accordance with a dynamic object-oriented programming language, said process comprising the steps of: creating said method object comprising a method-information field stored at a fixed location relative to a starting memory location of said method object and a variable size method body of program code stored at another location, said method-information field containing an offset identifying the location of said method body; executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and entering said method object at one of a first entry point to directly invoke said method body in response to execution of the ordinary function call and a second entry point to invoke said method body in the context of a generic function dispatch in response to execution of the generic function call, wherein said first entry point is different from said second entry point and other than the location of said method body, said first and second entry points enabling the processor to execute the program code contained in the method body.
According to another aspect the invention provides for use with a dynamic object-oriented computer language used to specify code for execution by a central processing unit of a computer, a process of using a method object stored in a memory of the computer, said process comprising the steps of: (a) creating the method object having a fixed size header, a method-information field of code stored at a fixed offset from the header, a variable size function-prolog field of code stored at a fixed offset from the header, and a variable size method body of code stored at a given offset from the header, said method-information field containing the given offset of the method body; (b) executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and 3a one of, (c) directly invoking the method object by entering the method object at a first entry point at the function-prolog field in response to execution of the ordinary function call and executing the code of the function-prolog field, and (d) invoking the method object in the context of a generic function dispatch by entering the method object at a second entry point at the method-information field in response to execution of the generic function call and executing the code of the method-information field.
According to yet another aspect the invention provides for use with a dynamic object-oriented computer program language used to specify code for execution by a central processing unit of a computer, apparatus for using a method object stored in a memory of a computer, said apparatus comprising: means for creating said method object having a method-information field of code stored at a fixed location relative to a starting memory address of said method object, a variable size function-prolog field of code stored at another fixed location relative to the starting memory address, and a variable size method body field of code stored at a predetermined location relative to the starting memory address, said method-information field containing an offset identifying the predetermined location of said method body field; means for executing one of an ordinary function call and a generic function call during run time to invoke said method body field of code; and one of, means for directly invoking said method object by entering the method object at a first entry point at the function-prolog field in respanse to execution of the ordinary function call and means for executing the code of the function-prolog field; and means for invoking said method object in the context of a generic function dispatch 3b by entering the method object at a second entry point at said method-information field in response to execution of the generic function call and means for executing the code of the method-information field, wherein said first and second entry points enable the central processing unit to execute the code contained in the method body.
According to still another aspect the invention provides an arrangement for using a method object in accordance with a dynamic object-oriented programming language of a computer, said arrangement comprising: a memory for storing the method object, the method object comprising: a header field having a starting memory address;
a method-information field located at a first offset from the starting memory address, said method-information field containing a predetermined address value; a function-prolog field of code located at a second offset from the starting memory address; and a method body field located at said predetermined address value from the starting memory address, said method body field containing program code for execution by said computer, and a processor for invoking said method object in response to entering said method object at one of a first entry point and a second entry point wherein said first entry point is different from said second entry point.
The above and further objects, details and advantages of the present invention will become apparent from the following detailed description of preferred embodiments thereof, when read in conjunction with the accompanying drawings.
3c SUMMARY OF THE DRAWINGS
Fig. 1 is a block diagram of a typical computer system containing in memory, among other things, a method object in accordance with the invention;
Fig. 2A shows schematically the format of a generic function when called by a program statement;
Fig. 2B shows schematically the format of an ordinary function when called by a program statement;
Fig. 3 is a schematic view of one form of method object in accordance with the invention;
3d Fig. 4 is a flow chart indicating how code representing multiple entry points can be generated.
m~~rmr ~m nFC~mpZ'ION OF PRFFERRED EMBODIMENT
The following conceptual framework is helpful in understanding the broad scope of the invention, and the terms defined below have the indicated meanings throughout this application, including the claims.
"Data" refers herein to signals that indicate or include information. For example, data could exist as an electromagnetic or other transmitted signal or as a signal stored in electronic, magnetic, or other form.
1 o A "data processing system" is a system that processes data. A "data processor" or "processor" is any component or system that can process data.
and may include one or more central processing units or other processing components.
"Memory" is any component, combination of components, or system that can store data, and may include local and remote memory and input/output 15 devices.
A processor "accesses" data in memory by any operation that retrieves or modifies the data, such as by reading or writing a location in memory that includes the data.
A processor "operates on" data by performing an operation that includes 20 obtaining resulting data that depends on the data operated on. For example.
the resulting data could result from an operation that accesses the data operated on or from a logical or numerical operation on the data operated on.
A processor "uses" data in performing an operation when the result of the operation depends on the value of the data. Stored data can be accessed using or 25 accessible using other data if the memory containing the stored data responds to the other data or to data that depends on the other data by permitting access to the stored data. For example, the other data may be an address, an offset used to produce an address, or a content-addressable value stored with the stored data.
216~~r~6 An "instruction" is an item of data that a processor can use to determine its own operation. A processor "executes" a set of instructions when it uses the instructions to determine its operations.
Fig. 1 is a block diagram of a typical computer system for program development, comprising a workstation 10 including a console 11 containing a CPU 12, RAM memory 13, and I/O circuitry 14 for communicating with a display 1 S, mass memory 16, a keyboard 17, and the usual mouse 18 with button switches 19. The usual display 15 contains a title or menu bar 21 and a cursor 22.
Stored 25 in the memory 13 or 16 would be the usual operating system. the program being run, and assorted objects created by the program as would be typical of a program developed under a dynamic object-oriented language.
Some general information known to all those skilled in the art may also help the reader. Source code when run through a compiler generates object code.
Compilers take the textual symbolic representation of the program in the source code and provide usually via assembly code a translated, machine-usable, output file. As is common, programs are divided up into modules and library routines or include files. An executable program is produced when the object code modules are linked with the called library routines. The executable code, among other things, keeps track of variables, constants, functions and methods by allocating 2o memory locations, fixed or relocatable, where such objects are stored, and for convenience often identifies a particular object, such as an array element or structure field, as being located so many memory locations offset from some known starting point. This approach is used both for heap memory as well as for stacks. Thus, a routine designed to perform a function would be stored at a particular location in memory, and a jump table would be typically constructed by the operating system listing the name of the routine and its start address or entry point for accessing the routine. Thus, when the program includes a statement calling this particular routine by name, the operating system knows where to find the beginning of the sequence of instructions which when run will execute the ~J ~J
f FEB 1~9~
function desired. If arguments are included in the function call, the routine is run with the arguments substituted for the formal parameters of the function. For a more detailed description, see "Inside Macintosh", published by Addison-Wesley, and "How to Write Macintosh Software" by S. Knoster, also published by Addision-Wesley.
Assume, as would be normal, that the program code in an object-oriented language created a generic function and then created under that generic function methods A, B; and C, to be respectively invoked when the generic function is called with specializers A, B, and C, respectively. When a generic function method is invoked from a called generic function, it receives a hidden extra argument which is not visible to the user. This extra argument contains information about the position of this method in the applicable method chain for this invocation of the generic function.
When a function as an object separate from the generic function is invoked directly, it doesn't need and doesn't receive the hidden argument. On the other hand, when a function is invoked directly, it performs a function entry prolog (argument type-1 S checking, etc.) which it need not perform when invoked from a generic function.
Furthermore, when a function is invoked directly, the caller doesn't know whether it's invoking a method or some other kind of function. Thus, having a single general entry at a fixed offset in all functional objects allows an efficient invocation protocol.
These differences are illustrated in Figs. 2A and 2B of which Fig. 2A shows a typical generic function 30 with its chain of methods A, B, and C, designated 31A, 31B, 31C, respectively. The hidden extra argument 32 is, for example, a table of memory addresses for the three methods. When the generic function is called with a specializer that matches the parameter of one of the methods, B for example, method B
is run by the operating system being given the memory address of the method B
body.
No type checking is necessary because the offset to the body 31B of method B
would not be available to be run unless the specializer matched the method B
parameter which means its type, in essence, had already been checked.
AMF?'.~3cD ~''aET
2167~r~~
Fig. 2B shows function 33 being called directly. Since no generic function dispatch is involved, argument checking is highly desirable. Thus, a function conventionally performs argument checking as part of its body.
It will be observed from Figs. 2A and 2B that two independent objects 30 and 33 exist in memory, each with its own unique entry point address. In accordance with the present invention, a new single method object is created in memory that can be called directly, or via a generic function call, and carry out or avoid carrying out the same tasks as illustrated in Fig. 2. This new object construct is illustrated at 40 in Fig. 3, and comprises four distinct but related contiguous 1o storage regions designated as a header 41, a meth-info field 42, a fn-prolog field 43, and the method body 44. The header is the normal object header that is, however, defined by the implementation. The size of this header must be fixed, so that the following field, meth-info, occurs at a fixed offset 1 from the starting location of the header. Meth-info contains method specific information such as specializers and flags, as well as the offset of the method body (offset X
above).
The size of meth-info is fixed (any variable data are stored as fixed-size pointers to additional data structures), so that the following field, fn-prolog, occurs at a fixed offset B. Fn-prolog is variable size, so that the method body starts at different offsets in different methods.
2o The function prolog, fn-prolog, within the method object of the invention looks and behaves as follows:
1. Performs standard function entry actions as required by the language (e.g., check the number and types of arguments, poll for events, etc.). This may perform arbitrary computations, hence this field is of variable size.
2. Places the initial value of the hidden extra argument into a standard place as specified by the runtime architecture (e.g. in a dedicated register or on top of stack).
3. Falls into the method body.
WO 95102862 ~ ~ '~' ~ PCTIUS94/06868 For ordinary functional invocation, i.e., to invoke the method object of Fig. 3 directly as a function, simply jump to the fixed ~ offset B in the method object entry point I. Sample assembly code is:
LOAD method object into REGISTER
JUMP to contents (REGISTER) + B ;B is a constant The value of B is preferably the same for all method objects.
For generic function method invocation, the following steps are carried out:
1. Compute the proper value of the hidden extra argument, as specified by language semantics, given the specializer used in the call.
2. Place the hidden extra argument in a standard place as specified by the runtime architecture (e.g., in a dedicated register, or top of stack.) 3. Use the information in the meth-info field at offset A to compute the method body offset X and jump to it. This may be done in one of two ways, depending on which is faster/smaller in the target machine architecture. The value of the offset X may be fetched from meth-info 42 and added to the method address to compute the address of the method body 44. Sample assembly code is:
LOAD method-object into REGISTER1 LOAD contents (REGISTERI) + A into REGISTER2 ;fetch method ;body offset ;Aisa ;constant ADD REGISTER2 to REGISTERI
JUMP to contents (REGISTERI) Or, as an alternative, the meth-info field may contain within it a branch to the method body, and hence the method body 44 may be reached by jumping into the meth-info field 42. Sample code for this alternative is:
LOAD method-object into REGISTER
JUMP to contents (REGISTER) + A ;jump to a branch to method.
;body The value of offset A is preferably the same for all method objects.
s rt:-iIUS~ 9 4 / 0 ~ 8 6 8 ~P~/~$ 1 '- FEB 7995 2~~~~0 Fig. 4 illustrates the action that occurs when programming statements are executed at runtime with an ordinary function call or a generic function call using a method object in accordance with the invention. Each of method objects Q, R
and S
would have been created during program development and each would contain the four fields indicated in the preferred embodiment of Fig. 3, In the usual way, a jump table 50 is created with the address for each of the three method objects Q, R and S.
When encountering each program statement 52, if it is an ordinary function call of, say, method Q, then the right branch is taken and code is generated 54 that loads 55 the address of method object Q, and then jumps 56 to the B offset to entry point I (Fig.
3) to run the code 58 in the function prolog 43 and then falls through to the method body 44 and eventually returns to the caller 59.
If it is not an ordinary function call, meaning that it is a generic function call with applicable method Q, then the left branch is taken. When the operating system creates a generic function, it places some canned code (a small set of instructions to select the appropriate method and call it) inside the generic function object.
See 34 in Fig. 2A. In other words, the body of a generic function is filled with canned code by the operating system, and the compiler is not involved at all. The canned code in this case would include the instructions shown in the left branch in the figure, as follows.
The code loads 62 the address of method Q, then loads 63 in a second register the contents of address plus offset A, adds 64 the two registers together to get the address of entry point II, and jumps to the latter 65 (entry point II). The method body code is the run 66 followed by usual return. This is one way of computing then offset X to the method body 44. As an alternative, shown with the dashed lines, if the method information field 42 contains a branch to the method body, then jumping 68 to the method information 42, indicated in Fig. 3 by entry point III, will enable control following the branch to fall through to the method body 44. _ All~'~,'O:cp ,.~cf~E?
2 ~ ~6 ~ ~ c~
As has been described, the method object illustrated in Fig. 3 can be invoked in the normal way in an object-oriented language as one component of a generic function having plural method objects with the method object selected to be run determined in the normal way by the specializers in the calling statement.
So, in a simple example, a single generic function intended to apply to several argument types, such as integer, string, or vector, when called with the integer, string or vector argument will invoke the function method appropriate for that type. In this instance the entry point for the method object would be at entry point II to the method body. A typical call in Dylan would be as follows:
to (double 17) Alternatively, the method object of Fig. 3 can be used directly to, for example, perform a local calculation, or as a function that does not require class dispatch, or to build up generic functions programmatically. The format would be similar to the lambda special fonm of Lisp or to blocks in Smalltalk. A simple example is given below:
(add-twice 17) In this instance, the entry point would be at entry point I in Fig. 3.
The method object of Fig. 3 can be created in a straightforward way by creating a generic function and automatically adding the desired method to it.
For 2o the example given above, the method and generic function would be defined in Dylan by:
(define-method double ((n <integer>)) (+ n n)) Alternatively, the exact same method object of Fig. 3 can be created and used directly without being added to a generic function. This would be done by the following definition in Dylan:
(define add-twice (method ((n <integer>)) (+ n n))) This method can then be added directly to the generic function if desired, as follows:
(add-method add-twice double) 2167~0~
The invention is not limited to the above-described formats and other formats are usable. The important point is that the compiler, upon encountering either of the above formats, knows to allocate memory storage space adequate to store an instance of the method object of Fig. 3, and to preserve in, for example, a jump table a pointer corresponding to the address of the method object.
Although there have been described what are at present considered to be the preferred embodiments of the invention, it will be understood that the invention may be embodied in other specific forms without departing from the essential characteristics thereof. The present embodiments are therefore to be t o considered in all respects as illustrative, and not restrictive. This scope of the invention is indicatcd by the appended claims rather than by the foregoing description.
tt
Claims (12)
1. A process of using a method object stored in a memory of a computer, said method object configured for operation by a processor in accordance with a dynamic object-oriented programming language, said process comprising the steps of:
creating said method object comprising a method-information field stored at a fixed location relative to a starting memory location of said method object and a variable size method body of program code stored at another location, said method-information field containing an offset identifying the location of said method body;
executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and entering said method object at one of a first entry point to directly invoke said method body in response to execution of the ordinary function call and a second entry point to invoke said method body in the context of a generic function dispatch in response to execution of the generic function call, wherein said first entry point is different from said second entry point and other than the location of said method body, said first and second entry points enabling the processor to execute the program code contained in the method body.
creating said method object comprising a method-information field stored at a fixed location relative to a starting memory location of said method object and a variable size method body of program code stored at another location, said method-information field containing an offset identifying the location of said method body;
executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and entering said method object at one of a first entry point to directly invoke said method body in response to execution of the ordinary function call and a second entry point to invoke said method body in the context of a generic function dispatch in response to execution of the generic function call, wherein said first entry point is different from said second entry point and other than the location of said method body, said first and second entry points enabling the processor to execute the program code contained in the method body.
2. The process of claim 1, wherein said method object further comprises a function-prolog field stored at another fixed location relative to the starting memory location of said method object, and wherein said first entry point is the another fixed location of said function-prolog field.
3. The process of claim 1, wherein said second entry point is the fixed location of said method-information field.
4. The process of claim 1 wherein said second entry point is the location of said method body.
5. For use with a dynamic object-oriented computer language used to specify code for execution by a central processing unit of a computer, a process of using a method object stored in a memory of the computer, said process comprising the steps of:
(a) creating the method object having a fixed size header, a method-information field of code stored at a fixed offset from the header, a variable size function-prolog field of code stored at a fixed offset from the header, and a variable size method body of code stored at a given offset from the header, said method-information field containing the given offset of the method body;
(b) executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and one of, (c) directly invoking the method object by entering the method object at a first entry point at the function-prolog field in response to execution of the ordinary function call and executing the code of the function-prolog field, and (d) invoking the method object in the context of a generic function dispatch by entering the method object at a second entry point at the method-information field in response to execution of the generic function call and executing the code of the method-information field.
(a) creating the method object having a fixed size header, a method-information field of code stored at a fixed offset from the header, a variable size function-prolog field of code stored at a fixed offset from the header, and a variable size method body of code stored at a given offset from the header, said method-information field containing the given offset of the method body;
(b) executing one of an ordinary function call program statement and a generic function call program statement during run time to invoke said method body of said method object; and one of, (c) directly invoking the method object by entering the method object at a first entry point at the function-prolog field in response to execution of the ordinary function call and executing the code of the function-prolog field, and (d) invoking the method object in the context of a generic function dispatch by entering the method object at a second entry point at the method-information field in response to execution of the generic function call and executing the code of the method-information field.
6. The method of claim 5, wherein said directly invoking step (c) comprises the steps of:
checking types of arguments applicable to the method body;
providing a hidden extra argument to the method body in response to said checking step indicating acceptable argument types; and executing the code of the method body.
checking types of arguments applicable to the method body;
providing a hidden extra argument to the method body in response to said checking step indicating acceptable argument types; and executing the code of the method body.
7. The method of claim 5, wherein said invoking step (d) comprises the steps of:
computing a value for a hidden extra argument in response to types of arguments to the generic function;
providing the computed hidden extra argument to the method body;
jumping to the method body in accordance with the given offset contained in the method-information field; and executing the code of the method body.
computing a value for a hidden extra argument in response to types of arguments to the generic function;
providing the computed hidden extra argument to the method body;
jumping to the method body in accordance with the given offset contained in the method-information field; and executing the code of the method body.
8. The method of claim 7, wherein said jumping step further comprises the step of computing the location of the method body in the memory using the given offset.
9. For use with a dynamic object-oriented computer program language used to specify code for execution by a central processing unit of a computer, apparatus for using a method object stored in a memory of a computer, said apparatus comprising:
means for creating said method object having a method-information field of code stored at a fixed location relative to a starting memory address of said method object, a variable size function-prolog field of code stored at another fixed location relative to the starting memory address, and a variable size method body field of code stored at a predetermined location relative to the starting memory address, said method-information field containing an offset identifying the predetermined location of said method body field;
means for executing one of an ordinary function call and a generic function call during run time to invoke said method body field of code; and one of, means for directly invoking said method object by entering the method object at a first entry point at the function-prolog field in response to execution of the ordinary function call and means for executing the code of the function-prolog field;
and means for invoking said method object in the context of a generic function dispatch by entering the method object at a second entry point at said method-information field in response to execution of the generic function call and means for executing the code of the method-information field, wherein said first and second entry points enable the central processing unit to execute the code contained in the method body.
means for creating said method object having a method-information field of code stored at a fixed location relative to a starting memory address of said method object, a variable size function-prolog field of code stored at another fixed location relative to the starting memory address, and a variable size method body field of code stored at a predetermined location relative to the starting memory address, said method-information field containing an offset identifying the predetermined location of said method body field;
means for executing one of an ordinary function call and a generic function call during run time to invoke said method body field of code; and one of, means for directly invoking said method object by entering the method object at a first entry point at the function-prolog field in response to execution of the ordinary function call and means for executing the code of the function-prolog field;
and means for invoking said method object in the context of a generic function dispatch by entering the method object at a second entry point at said method-information field in response to execution of the generic function call and means for executing the code of the method-information field, wherein said first and second entry points enable the central processing unit to execute the code contained in the method body.
10. An arrangement for using a method object in accordance with a dynamic object-oriented programming language of a computer, said arrangement comprising:
a memory for storing the method object, the method object comprising:
a header field having a starting memory address;
a method-information field located at a first offset from the starting memory address, said method-information field containing a predetermined address value;
a function-prolog field of code located at a second offset from the starting memory address; and a method body field located at said predetermined address value from the starting memory address, said method body field containing program code for execution by said computer, and a processor for invoking said method object in response to entering said method object at one of a first entry point and a second entry point wherein said first entry point is different from said second entry point.
a memory for storing the method object, the method object comprising:
a header field having a starting memory address;
a method-information field located at a first offset from the starting memory address, said method-information field containing a predetermined address value;
a function-prolog field of code located at a second offset from the starting memory address; and a method body field located at said predetermined address value from the starting memory address, said method body field containing program code for execution by said computer, and a processor for invoking said method object in response to entering said method object at one of a first entry point and a second entry point wherein said first entry point is different from said second entry point.
11. The arrangement of claim 10 wherein said first entry point is said method-information field and wherein the processor computes the location of said method body field using said predetermined address value.
12. The arrangement of claim 10 wherein said second entry point is said function-prolog field and wherein the processor executes the code of the function-prolog field to provide a hidden extra argument to said method body.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US9220793A | 1993-07-15 | 1993-07-15 | |
| US08/092,207 | 1993-07-15 | ||
| PCT/US1994/006868 WO1995002862A1 (en) | 1993-07-15 | 1994-06-17 | Multiple entry point method dispatch |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CA2167306A1 CA2167306A1 (en) | 1995-01-26 |
| CA2167306C true CA2167306C (en) | 2003-08-19 |
Family
ID=22232159
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002167306A Expired - Lifetime CA2167306C (en) | 1993-07-15 | 1994-06-17 | Multiple entry point method dispatch |
Country Status (6)
| Country | Link |
|---|---|
| US (1) | US6427231B1 (en) |
| EP (1) | EP0708940B1 (en) |
| AU (1) | AU7355494A (en) |
| CA (1) | CA2167306C (en) |
| DE (1) | DE69427193T2 (en) |
| WO (1) | WO1995002862A1 (en) |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7013467B1 (en) * | 1997-12-09 | 2006-03-14 | Mci Communications Corporation | System and method for managing computer system resources using command control vectors |
| US6782532B1 (en) * | 1999-10-21 | 2004-08-24 | Oracle International Corporation | Object type system for a run-time environment using generated high-order language instructions for generic functions |
| US6966055B2 (en) * | 2001-03-02 | 2005-11-15 | International Business Machines Corporation | Optimizing post-link code |
| US20050160414A1 (en) * | 2004-01-21 | 2005-07-21 | Nokia Corporation | System and method for dynamically adding features to software applications |
| US8006250B1 (en) | 2004-06-22 | 2011-08-23 | Apple Inc. | Creating an object in an object-oriented programming platform |
| US7954110B1 (en) | 2004-06-22 | 2011-05-31 | Apple Inc. | Observing properties associated with an object in an object-oriented programming platform |
| US7743087B1 (en) | 2006-03-22 | 2010-06-22 | The Math Works, Inc. | Partitioning distributed arrays according to criterion and functions applied to the distributed arrays |
| US20100131803A1 (en) * | 2008-11-25 | 2010-05-27 | Express Logic | Computation of stack usage in embedded computing systems |
| US8997040B2 (en) * | 2010-03-24 | 2015-03-31 | Microsoft Technology Licensing, Llc | Variable closure |
| US9952843B2 (en) * | 2014-05-15 | 2018-04-24 | Nvidia Corporation | Partial program specialization at runtime |
| US10496378B2 (en) * | 2017-05-04 | 2019-12-03 | Microsoft Technology Licensing, Llc | Generating and executing multi-entry point functions |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4675810A (en) * | 1981-05-22 | 1987-06-23 | Data General Corp. | Digital data processing system having a uniquely organized memory system using object-based addressing and in which operand data is identified by names accessed by name tables |
| US4868745A (en) * | 1986-05-30 | 1989-09-19 | Hewlett-Packard Company | Data processing system and method for the direct and indirect execution of uniformly structured object types |
| US5226161A (en) * | 1987-08-21 | 1993-07-06 | Wang Laboratories, Inc. | Integration of data between typed data structures by mutual direct invocation between data managers corresponding to data types |
| US5261080A (en) * | 1987-08-21 | 1993-11-09 | Wang Laboratories, Inc. | Matchmaker for assisting and executing the providing and conversion of data between objects in a data processing system storing data in typed objects having different data formats |
| US5297284A (en) * | 1991-04-09 | 1994-03-22 | Microsoft Corporation | Method and system for implementing virtual functions and virtual base classes and setting a this pointer for an object-oriented programming language |
| US5421016A (en) * | 1991-12-12 | 1995-05-30 | International Business Machines Corporation | System and method for dynamically invoking object methods from an application designed for static method invocation |
-
1994
- 1994-06-17 EP EP94922442A patent/EP0708940B1/en not_active Expired - Lifetime
- 1994-06-17 CA CA002167306A patent/CA2167306C/en not_active Expired - Lifetime
- 1994-06-17 DE DE69427193T patent/DE69427193T2/en not_active Expired - Lifetime
- 1994-06-17 AU AU73554/94A patent/AU7355494A/en not_active Abandoned
- 1994-06-17 WO PCT/US1994/006868 patent/WO1995002862A1/en active IP Right Grant
-
1995
- 1995-08-04 US US08/509,753 patent/US6427231B1/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| CA2167306A1 (en) | 1995-01-26 |
| DE69427193D1 (en) | 2001-06-13 |
| WO1995002862A1 (en) | 1995-01-26 |
| EP0708940A1 (en) | 1996-05-01 |
| EP0708940A4 (en) | 1997-05-28 |
| DE69427193T2 (en) | 2001-09-20 |
| AU7355494A (en) | 1995-02-13 |
| US6427231B1 (en) | 2002-07-30 |
| EP0708940B1 (en) | 2001-05-09 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US5446900A (en) | Method and apparatus for statement level debugging of a computer program | |
| US5381547A (en) | Method for dynamically linking definable program elements of an interactive data processing system | |
| EP1280056B1 (en) | Generation of debugging information | |
| US5907707A (en) | Object model for Java | |
| US6199095B1 (en) | System and method for achieving object method transparency in a multi-code execution environment | |
| US5999732A (en) | Techniques for reducing the cost of dynamic class initialization checks in compiled code | |
| US6704927B1 (en) | Static binding of dynamically-dispatched calls in the presence of dynamic linking and loading | |
| US6651080B1 (en) | Techniques for implementing pluggable virtual machines | |
| US20020083416A1 (en) | Automatic stub/adapter generator | |
| US6138273A (en) | Programmable interpretive virtual machine | |
| Viroli et al. | Parametric polymorphism in Java: An approach to translation based on reflective features | |
| US20040268301A1 (en) | Adding new compiler methods to an integrated development environment | |
| US6072950A (en) | Pointer analysis by type inference combined with a non-pointer analysis | |
| CA2167306C (en) | Multiple entry point method dispatch | |
| Albahari et al. | C# Essentials: Programming the. NET Framework | |
| EP0950947B1 (en) | Static binding of dynamically dispatched calls in the presence of dynamic linking and loading | |
| US7181724B2 (en) | Representation of Java® data types in virtual machines | |
| JPH0738159B2 (en) | Method and apparatus for processing computer code in a code translator | |
| CN111767033B (en) | Programming system and function expansion method for mechanical arm program development | |
| Crary et al. | Type structure for low-level programming languages | |
| de Figueiredo et al. | The design and implementation of a language for extending applications | |
| US7356809B1 (en) | Programmable interpretive virtual machine | |
| US7082597B2 (en) | Representation of objects in a Java programming environment | |
| Farkas et al. | MProlog: an implementation overview | |
| Patnaik et al. | Implementation of CSP-S for description of distributed algorithms |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| MKEX | Expiry |
Effective date: 20140617 |