Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1998-08-03
2001-11-06
Courtenay III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C712S202000
Reexamination Certificate
active
06314445
ABSTRACT:
FIELD OF INVENTION
This invention relates to a system and method for providing a native function call facility. In particular it relates to a system and method for providing a native function call facility in a Java Virtual Machine (JVM) for platforms that do not have a native function call facility for dynamic parameter sets.
BACKGROUND OF INVENTION
IBM's AS/400 computer platform is one of IBM's more successful products, it has been available since the late seventies and has survived in the market for much longer than most other business hardware platforms. One reason for its success is that it incorporates a virtual machine layer as an interface between the AS/400 computer and AS/400 applications. This allows the platform to be defined by the virtual machine software rather than the platform hardware and the advantage follows that existing software need not be rewritten for new hardware. As hardware advances become available they may be incorporated into the AS/400 computer together with corresponding changes in the virtual machine layer which make the platform appear the same as before. Business software tends to be in use for long periods of time and this feature is particularly attractive for business users.
The virtual machine layer defines an independent virtual machine instruction set which maps on to the machine instructions of the computer; it is simple to use because it is high level but has the disadvantage that some machine instructions of the AS/400 computer are no longer available. In particular there are no machine stack manipulation instructions in the virtual machine instruction set and the address of a machine stack pointer may not be accessed or changed directly by an instruction from the AS/400 virtual machine set. Furthermore the AS/400 virtual machine does not allow function calls with dynamic parameter sets, where the parameters are assumed to be stored on a stack and only the signature or format of the parameters is known.
The idea of platform independence is not exclusive to the IBM AS/400 and has also been developed in another area. In particular the Java programming language was originally designed for use in the consumer electronics industry so that microprocessors in kettles, videos and cameras could be programmed in the same language. This platform independent property in the Java language was found to be ideal for programs distributed on the internet where different platforms are connected together in a network. Applications are written in high level Java source code, compiled into Java byte code by a Java compiler and interpreted by the Java Virtual Machine (JVM). Its main advantage is that it is ‘write once run anywhere’, that is, platform independent and portable.
IBM's AS/400 and Sun Microsystem's Java therefore have a virtual machine interface in common and when used together, a Java application running on an AS/400 uses a JVM to interface to the AS/400 virtual machine which interfaces to the AS/400 computer. This combination is advantageous in that it allows Java applications to run on present and future AS/400 computers. However a problem exists when the JVM needs to access the stack pointer of the AS/400 computer: since there is no facility in the AS/400 virtual machine to do this, there can be no direct access from the JVM.
This is a particular problem for interpreting native function call instructions in the JVM with respect to dynamic parameter sets. A native function call instruction instigates a jump to the address in memory outside the Java environment of a function indicated by a function identifier. The function identifier is used to find the address in the computer system where the function resides. The native function may have an operating system address and an operating system lookup table may allow the address to be located.
A native call is a procedure call to code external to the Java environment, for example to the platform operating system OS/400 or another platform specific routine. The Java specification states that native calls should be allowed although if implemented the Java application containing it will not be 100% Java and portable to other platforms. Native calls are necessary so that existing legacy systems may be integrated with new Java applications, for example a Java interface to an existing database application.
The Java native call instruction expects that the parameters required by the function will be on a Java stack and will not be part of the instruction. The format in which the function is expecting the parameter is defined in the instruction by a signature. When processing the instruction the JVM would normally retrieve the parameter from the Java stack and place it on the machine stack in its respective format as required by the native function and indicated by the signature.
A function call instruction has a dynamic parameter set when the parameters the function requires are stored in a stack before the function is called. This is as opposed to a function call instruction with a fixed set of parameters when the parameters are included in the instruction. An example of a Java function call instruction with a dynamic parameter set would be ‘Invoke native “Fred/A(CICI)VI”’ where ‘Fred/A’ is the function identifier ‘(CICI)’ is the parameter signature and ‘V’ is the return value. The parameters a, b, c, d may be stored on the stack before the instruction is processed. The parameter signature ‘(CICI)’ indicates that the function requires a character (C), integer (I), character (C), integer (I) sequence of parameters from the stack. An example of a C language function call instruction with a fixed parameter set would be Fred A (a,b,c,d),V′ where (a,b,c,d) are parameters declared as character, integer, character, integer.
A JVM running directly on a hardware platform without an intermediary virtual machine can usually access a stack pointer in the machine directly. When the JVM interprets a native function instruction it fetches the stack pointer from the machine register and loads the parameters of the dynamic function instruction directly into memory (the machine stack) pointed at by the stack pointer. The JVM then jumps to the address of the function with the stack pointer pointing at the parameters in memory. This is where the difficulty lies since the AS/400 virtual machine will not allow the JVM to manipulate the machine stack directly and the JVM does not have direct access to the AS/400 computer.
A known way of dealing with such a problem would be to write additional native function handling code which would directly access the underlying machine level as in the prior art solution. This code would place the selected parameters on the machine stack by accessing stack manipulation functionality in the machine. However, in the case of the AS/400, the architecture is such that direct calls to the AS/400 machine would bypass the intended control and precautions of the system and could cause potential problems.
SUMMARY OF INVENTION
According to one aspect of the invention there is provided a method of processing, within a virtual machine on a computer system, a native function call instruction with a dynamic parameter set, said method comprising the steps of;
interpreting code representing a native function call instruction;
storing the parameters of said dynamic parameter set in an array;
using the computer system to process the native function call with a fixed parameter set as represented by the array;
whereby the computer system transfers the parameters from the array to a machine stack used by the native function before the native function is called.
By using the functionality of the underlying computer system the method allows the JVM to avoid the use of stack manipulation machine instructions.
In a preferred embodiment the method further comprises acquiring a parameter set signature from the instruction and loading the parameters into the array in a format defined by the parameter set signature. Most preferably the parameters are loaded into the array in a contiguous fa
Bruzzone Lauren C.
Courtenay III St. John
International Business Machines Coproration
LandOfFree
Native function calling does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Native function calling, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Native function calling will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2578171