GB2517192A

GB2517192A - Processing for application program deployment

Info

Publication number: GB2517192A
Application number: GB201314585A
Authority: GB
Inventors: Robert Sales
Original assignee: Micro Focus IP Development Ltd
Current assignee: Micro Focus IP Development Ltd
Priority date: 2013-08-14
Filing date: 2013-08-14
Publication date: 2015-02-18
Also published as: GB201314585D0

Abstract

Compiler 230 parses system independent language 210 for occurrences of numeric variables whose type is not native in an intermediate language. The compiler differentially compiles source-code by setting flags for conversion into an integer type for variables meeting a set of conditions or flags for not converting into an integer type if one of the conditions is not met, usually resulting in byte array type conversion. The conditions are: the numeric variable is independent or member of explicitly referenced groups; it is not referenced using reference modification; it is not passed by reference; it is not referenced using address operators. Preparation part 235 prepares common intermediate language code 225 as executable code 250, i.e. machine or assembly code. Arithmetic operations and storage involving integer types instead of bytearray makes a more efficient use of computing resources. Uses comprise converting binary coded decimals, e.g. comp-3, and picture clauses in COBOL.

Description

PROCESSING FOR APPLICATION PROGRAM DEPLOYMENT

Technical Field

The present invention relates to preparation of computer program code for deployment upon a computing system. In particular, but not exclusively, the present invention relates to improvements in how a given set of computer program code is translated into control instructions for a given computing system.

Background

Thcrc is often an inhcrcnt tcnsion in computing tcchnology bctwccn thc pacc of change of computer architectures and the need for stable, reliable solutions that operate for decades. Before personal computers entered the market in the 1980s and 1990s, the concept of "computing" as a technical field was associated with large-scale, centralised "mainframe" computing systems. These systems were often cabinet or room-sized and were used for mission-critical tasks in large organisations, scientific institutions and government, in the 1960s and 1970s, many mainframe computing systems were manufactured and supplied by International Business Machines Corporation (IBM®).

For example, well-known systems included the IBM 700/7000 series, and those based on the SystemI36O and System!370 computing architectures. Many features that are now taken for granted, such as transistors then complementary metal-oxide-semiconductor (CMOS) central processing units (CPUs), 8-bit bytes, 32-bit words, hardware floating point support and 32-bit words wcrc introduccd slowly ovcr dccadcs in these systems.

In parallel with the development of modem computing architectures based on mainframe innovations, there was a need to better control computing operations.

Although difficult to comprehend in the modern era, the Systeni/360 computing architecture was one of the first computers in wide use to include dedicated hardware provisions for the use of an operating system. Before that time, mainframe systems required computer program code to be manually initiated, often on punched cards.

Early mainframe systems were controlled and programmed using system-specific machine code. Over time, mnemonic assembly languages developed, which added support for macro instructions. This then led to the development of the first system-independent programming languages, such as FORTRAN, LISP, COBOL, PL/l and ALGOL 60. Grace Hopper, an early computing pioneer, developed the first compiler and later the COBOL language. Much of the work in this era paved the way for technical aspects of digital computing that are considered fundamental today, such as subroutines, formula translation, relative addressing, the linking loader, code optimization and symbolic manipulation. System-independent programming languages, and the compiler technology that allowed system-independent program code to be deployed as machine code to specific hardware architectures, greatly improved the portability of computer programs, benefiting the control of computing devices regardless of specific program content or function. It also enabled a computcr program to continue to control a computer system as a computer architecture evolved. Hardware features could be added to the computer system or architecture without requiring a rewrite of computer program code.

The success of system-independent programming languages brings its own set of technical problems. As computer programs could survive upheaval in physical architectures, resources could be invested in building stable, mission-critical computing functions. These functions could be designed to be in operation for decades, human lifetimes even. For example, over the years, many control, data recordal and file handling functions were developed, embodied in computer program code and became the foundation of modem engineering and production systems. As more functionality was added, this was often achieved by appending additional computer program code to cxisting computer programs. In the modem Intcmct cra at thc turn of the twenty-first century, many organisations were reliant on computer program code originally written and developed in the I 960s and I 970s.

As hardware developments have accumulated and incorporated global networking aspects, modem computer systems are required to operate in an environment quite different from that of the early eras of mainframe computing.

However, as described above, organisations, entities and control systems are deeply reliant on legacy computer program code in programming languages that date from these earlier eras. Migration is one option but may not be entirely possible. Legacy computer programs can run to millions of lines of computer program code, contributed by thousands of different programmers over tens of years. Early system-independent computing languages were often sequential in nature, making it difficult to identify and extract individual frmnctions and often requiring a so-called "big bang" migration where all computing functions are transferred to a new implementation at once. Even though they are often rigorously tested, these tests cannot cover all of the complexities of the legacy computer program. For implementations in hospitals, civil infrastructure, and aviation, as just a few examples, the risk of failure may be too great to attempt migration. This then requires aligning the technical benefits of modem hardware systems with computer program code that may pre-date the implementing computer engineers.

Summary

Aspects of the present invention are set out in the appended claims.

Further features and advantages of the invention will become apparent from the following description of preferred embodiments of the invention, given by way of example only, which is made with reference to the accompanying drawings.

Brief Description of the Drawings

Figure 1 is a schematic diagram showing a first set of system components for controlling a mainframe computing device according to embodiments; Figure 2 is a schematic diagram showing a second set of system components for controlling a computing device according to embodiments; Figures 3A and 3B are a flow chart showing operation of a computer system according to embodiments; and Figure 4 shows an application program comprising computer program code in a programming language that is computing-system independent according to embodiments.

Detailed Description

Figure 1 shows a first set of system components 100 for controlling a mainframe computer system 160 according to embodiments. Source code 110, e.g. data in the form of command statements and/or variable declarations, comprises computer program code for a computer program written in a system-independent programming language.

The system-independent programming language may for example comprise one of FORTRAN, LISP, COBOL, PUT and ALGOL 60. Source code 110 may be retrieved from a computer-readable storage medium 120. Source code 110 is typically human-readable. To control mainframe computer system 160, source code 110 is converted to a machine-readable version. This is performed by a compiler unit 130 of a computer device 140. Compiler unit 130 takes source code 110 and converts it into object code 150. Object code 150 comprises a version of source code 110 that may be read and executed by mainframe computer system 160. The command statements and/or variable declarations in source code 110 arc converted into control instructions specific to mainframe computer system 160, i.e. instructions that may be interpreted by the specific hardware components of the mainframe computer system. Object code 150 is typically not human-readable, e.g. Figure 1 shows a binary version of the control instructions. Object code 150 is sometimes referred to as machine code or executable code. In this case, object code 150 is stored on a computer-readable storage medium 170. When the computer program is to be executed, object code 150 is loaded from computer-readable storage medium 170 into a memory 180 of mainframe computer system 160. Memory 180 is typically a random access memory. During execution, control instructions as defined in object code 150 are processed by one or more processors 190 (or a set of processors' or a processing system') of mainframe computer system 160. Each processor set typically has a different set of suitable control instructions. An instruction may control operations such as, among others, load, jump, and arithmetic logic unit commands.

In mainframe computer systems from the 1960s, 70s and 80s, the memory and the one or more processors may be limited when compared to modem computer systems. For example, a state-of-the-art system used by the National Aeronautics and Space Administration (NASA) and installed in 1969 had a central processing unit cycle time of 60 nanoseconds (e.g. a speed of 16MHz) and a memory cycle time of 780 nanoseconds (e.g. around 1.3MHz). The memory size was 2MB. Source code 110 may for example be representative of programs written to run on these mainframe systems.

The arrangement of Figure 1 described above may be referred to as a native environment, wherein source code is compiled to native code, i.e. object code 150 for mainframe computer system 1 60. In contrast, Figure 2 shows an arrangement that may be referred to as a managed environment. In this case, source code 210 is compiled by a first compiler unit 230 of a first computer device 240. The first compiler unit 230 converts the source code 210 to intermediate code 225. Intermediate code 225 is system-independent (e.g. processor and computer architecture independent).

Intermediate code 225 is of a lower level than source code 210, e.g. its instructions have a closer mapping to system-specific instruction sets. Intermediate code 225 may comprise common intermediate language (CIL) code, for example as defined by the common language infrastructure (CLI) standard and implemented as part of a Microsoft® .NET or Mono framework, or Java® bytecodc. Intcrmediate codc 225 in the form of common intermediate language code may be assembled into a form of bytecode called a CLI assembly. This may be performed by the first compiler unit 230.

In Figure 2, the intermediate code 225 is further compiled by a second compiler unit 235 of a second computer device 245 into object code 250. The first and second computer devices and/or the first and second compiler units may, in some cases, form part of the same device or unit. The second compiler unit 235 may comprise a just-in-time (JIT) and/or ahead-of-time (AOT) compiler unit: in the former case, the intermediate code 225 is converted into object code 250 at runtime, this may occur in a piece-meal or line-by-line (i.e. interpreted) fashion; in the latter case, the intermediate code 225 is converted into object code 250 before execution. In one case the second compiler unit 235 may comprise a virtual machine forming part of a runtime environment, for example a Java virtual machine or a common language runtime. When using an AOT compiler, the object code 250 may be stored in a computer-readable medium 270 before execution. In the JIT case, executable code in the form of Java bytecode or assembled CIL may be interpreted by a virtual machine, i.e. compiled and executed at runtime. In both cases, the object code is similar to object code 150 and at least a portion of object code 284 is loaded into a memory 280 of computer system 260 for execution by at least one processor 290.

In Figure 2, computer system 260 may comprise a modern server computing device (i.e. modem relative to the mainframe computer system 160). By compiling to intermediate code 225, source code 210 may be optimised to make use of advanced features of the computer system 260. For example, one or more of security, threading and memory management may be improved by making use of run-time management services 282. Run-time management services 282 are implemented by system libraries that comprise executable code -they may form part of an execution or runtime environment. This executable code is loaded into memory 280 along with at least a portion of the object code 284 during execution. In one case, run-time management services 282 may comprise the second compiler unit 235 in the form of a just-in-time compiler, wherein the second computer device 245 comprises the computer system 260 (as indicated by the dashed line). In this case, the second compiler unit 235 may comprise a virtual machine in the form of a common language runtime in the.NET framework or a Java virtual machine. The virtual machine may then handle exceptions, garbage collection (i.e. efficient use of space in memory 280), variable type safety (i.e. a discrepancy between data types) and thread management (i.e. control of machine code being processed by the at least one processor 290). These functions may not be available on mainframe system 160, or at least may be implemented in an inefficient manner due to the age of the hardware of the mainframe system 160. Even in a case where intermediate code 225 is compiled ahead-of-time (i.e. in advance of runtime) to object code 250, the same functions of the mn-time management services 282 may be implemented by suitable code conversion from intermediate code to object code (e.g. a given intermediate code statement may be compiled in a particular manner for a particular server computing device to make use of hardware functionality of said device using appropriate machine code functions).

Embodiments comprise measures, including a computer system configured to prepare an application program for deployment into a runtime environment of the computing system and a computer-implemented method of preparing an application program for deployment into a runtime environment of a computing system.

Embodiments also comprise a corresponding computer system and computer-implemented method for deploying a prepared application program into a runtime environment.

The computer system of embodiments comprises at least one processor, a memory comprising at least one computer-readable storage medium coupled to the at least one processor, and a compiler unit. The compiler unit comprises a receiver part, a parser part, a determination part, a flag setting, a compiler part, and a preparation part.

In certain examples, a computer system may operate by way of at least one processor and memory, wherein these components are provided by a separate entity.

Operation of the computer system of embodiments is now described in relation to the flow diagram of Figures 3A and 3B.

In item 300, the receiver part receives the application program, the application program comprising computer program code in a programming language that is computing-system independent.

In item 302, the parser part parses the computer program code of the application program for occurrences of at least one numeric variable, the at least one numeric variable being of a given numeric variable type, the given numeric variable type belonging to a plurality of numeric variable types that are defined in the programming language and that are not defined as native types in an intermediate language common to a plurality of programming languages including the programming language. For example, a variable that has a fixed number of digits before a decimal point and a fixed number of digits following a decimal point may not be represented as a specific variable type in the specification for the intermediate language.

In item 304, the determination part, for each numeric variable located in the parsing, determines whether the following conditions are met: the numeric variable is an independent item or a member of one or more groups none of which are explicitly referenced within the computer program code; the numeric variable is not referenced within the computer program code using reference modification; the numeric variable is not passed by reference to a sub-program within the computer program code; and the numeric variable is not referenced within the computer program code using an address operator.

As per item 306, in response to all of the conditions being met, the flag setting part in 308A sets a flag for the numeric variable to a value indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language.

As per item 306, in response to at least one of the conditions not being met, the flag setting part in 308B sets a flag for the numeric variable to a value that is not indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language.

In item 310, the compiler part compiles the computer program code to the common intermediate language to produce common intermediate language code, the compiling comprising converting any numeric variable with a flag value indicative of a conversion candidate from the first numeric variable type to an integer type that is defined as a native type in the common intermediate language, and converting any numeric variable with a flag value that is not indicative of a conversion candidate to a byte array.

In item 312, the preparation part prepares the common intermediate language code for execution by a processor of the computing system. The preparation part prepares the application program for implementation in the mntime environment of the computing system. For example, this may comprise a further compilation to machine code, or it may comprise the assembly of common intermediate language code to a byteeode format. For example, in the latter case this may apply for assembled common intermediate language code (CIL) in the Microsoft NET framework. In some cases, the preparation part may form part for the compiler part, for example to output Java bytecode.

In embodiments, the executable code comprises machine code and/or assembly code.

In embodiments, the integer type that is defined as a native type in the common intermediate language comprises a 32 or 64 bit integer type.

The byte array of embodiments is an array of bytes. Each entry (or element') in a byte array is a byte of binary data, for example an 8-bit data item which is capable ofrepresenting any decimal number in the range 0 to 255.

The output of the preparation part may be referred to as executable code, as the code may be executed directly or by way of a just-in-time compiler. Compilation may be performed on a first computing device for execution within a runtime environment installed on a second computing device, wherein compilation prepares control instructions based on the source code that may make use of functions provided by the runtime environment. As such compilation is described as a preparation step for subsequent deployment into a runtime environment that generates a concrete output -executable code to control a computing device.

In certain cases, output code may then be executed by the computer device performing the operations described with reference to Figures 3A and 3B. For example, this may be the case if executable code needs to be run in a test environment. In the same, or other case, the executable code may be communicated to a further computer device for execution. In the latter case, the further computer device has a runtime environment that is configured to execute the compiled code. In one case, the entity performing at least the parser and compiler operations may be different from the entity executing the finalised code, e.g. the former may comprise a system developer and the latter an end-user. As such the operations may be performed ahead of, and independently from, subsequent execution. For example, executable code may be packaged upon and/or copied to a computer-readable storage medium that is then accessed by a flirther computer device. In one case, executable code may be communicated over a network and stored within a storage device of the further computer device (e.g. stored on a hard disk or flash-memory drive). In use, the executable code may then be retrieved from storage and loaded into memory ready for execution by one or more processors.

Figure 4 shows an example of an application program 400 comprising computer program code in a programming language that is computing-system independent according to embodiments.

In application program 400, a numeric variable ni (see item 400) is declared within a reference level (in this ease 01 level) group gI (see item 402). The numeric variable nI is declared at a 03 level (see item 404) which is lower than the reference level of the group gi. The numeric variable ni is declared as a variable of type var_type. In the example case of a COBOL program, var type could for example be eomp-3 which is a binary field type with two digits in each byte using binary coded decimal (BCD) notation. The numeric variable ni is declared using a picture clause (pie') including the characters 9(6)v9(3), which notation indicates 6 numeric digits before and 3 numeric digits after a decimal point.

Application program 400 then declares two variables dtl and dt2 of date-time data type and a variable tsl of timespan data type. The remainder of application program 400 performs various computation on the declared variables, the details of which are not described in detail herein. Note that the dtl, dt2 and tsl variables are examples used to demonstrate performance improvement and should not be taken to limit embodiments of the present invention.

Application program 400 is processed according to embodiments to prepare an application program for deployment into a runtime environment of a computing system.

Application program 400 is received, at a compiler unit of the computer system and parsed for occurrences of at least one numeric variable, the at least one numeric variable being of a given numeric variable type, the given numeric variable type belonging to a plurality of numeric variable types that are defined in the programming language and that are not defined as native types in an intermediate language common to a plurality of programming languages including the programming language. In this case, the parsing locates numeric variable nl, whose variable type var type is not defined as a native type in an intermediate language (for example.NET) common to a plurality of programming languages including the programming language of application program 400. It is then determined for the rnimeric variable ni located in the parsing whether several conditions are met.

A first condition of the several conditions is whether the numeric variable is an independent item or a member of one or more groups none of which are explicitly referenced within the computer program code of application program 400. The numeric variable nl is not an independent item because it is declared at a 3 level. The numeric variable n I is a member of the group gl,but this group is not explicitly referenced with the computer program code of application program 400. The first condition is therefore met by numeric variable ni.

A second condition of the several conditions is whether the numeric variable is referenced within the computer program code of application program 400 using reference modification. Reference modification involves defining a data item by speci'ing a starting position and length for the item. Numeric variable ni is not referenced within the computer program code of application program 400 using reference modification so the second condition is met by numeric variable ni.

A third condition of the several conditions is whether the numeric variable is passed by reference to a sub-program within the computer program code of application program 400. Numeric variable ni is not passed by reference to a sub-program within the computer program code of application program 400 so the third condition is met by numeric variable nl.

A fourth condition of the several conditions is whether the numeric variable is referenced within the computer program code of application program 400 using an address operator. Numeric variable ni is not referenced within the computer program code of application program 400 using an address operator so the fourth condition is met by numeric variable ni.

Since all of the conditions are met by numeric variable ni, a flag is set for numeric variable nl to a value indicative of a candidate for conversion from the given numeric variable type (var_type) to an integer type that is defined as a native type in the common intermediate language.

No other numeric variables are located in the parsing of application program 400 so no flag is set for any numeric variable to a value that is not indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language.

The computer program code of application program 400 is then compiled to the common intermediate language to produce common intermediate language code. The compiling comprises converting the numeric variable ni with a flag value indicative of a conversion candidate from the first numeric variable type to an integer type that is defined as a native type in the common intermediate language. Since no flag has been set for any numeric variable to a value that is not indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language, the compiling does not involve converting any numeric variable with a flag value that is not indicative of a conversion candidate to a byte array.

The common intermediate language code is then prepared as code executable by a processor of a computing system. This computing system is arranged to implement application program 400 in a runtime environment and may be the same or a different computer system as described above.

By use of embodiments, numeric variable ni is converted into an integer type that is native to the common intermediate language. Without the use of embodiments, numeric variable ni would instead have been converted into a bytearray type. Such conversion (or promotion') of numeric variable ni according to embodiments means that the resulting executable code runs faster in the runtime environment, i.e. the runtime environment of the computing system is more efficient. For example, arithmetic operations performed on integer numeric variable types are much more computationally efficient than arithmetic operations performed on bytearray numeric variable typcs. For example, the data storage requirements for integer numeric variable types arc considerably lower than those required for bytearray numeric variable types.

A tangible measure of such efficiency improvement of embodiments is demonstrated by the execution time for executable code produced in relation to application program 400 deployed in the runtime environment of the computer system according to embodiments being over 20 times faster than for executable code produced in relation to application program 400 deployed in the runtime of the computer system without use of embodiments. Such efficiency gains in the runtime environment are advantageously gained without changes in the underlying program semantics.

Embodiments are particularly suited for use in relation to application programs containing a high number and/or a high frequency of use of byte-array implemented numeric variable types. Embodiments are also particularly suited for use in relation to application programs where there is a large variety of different numeric variable types with different associated storage layouts. Embodiments work by recognizing situations where the precise storage requirements can be disregarded and instead treating the field as a simple integer (for example 32 or 64 bit). The resulting code is much more efficient when deployed in a runtime environment, but there is no discemible change to program behaviour. Embodiments provide performance advantages for standard application programs running in a managed code environment. This makes it more likely that users will consider retaining their original application program code while making the transition to a managed code environment.

Certain embodiments described herein provide technical improvements when deploying legacy computer programs. The term "legacy" is used herein to describe features that relate to a computing architecture that is no longer in use. For example, a legacy programming language is a programming language that was configured to operate on a superseded (i.e. legacy) computing architecture. In certain case, the legacy programming language may relate to a specification that has itself been superseded.

For example, computer program code that was originally written in a computer programming language for use with legacy mainframe computer systems, such as those based on the IBM Systenv'360 computing architecture, may be optimised for use with modem computing architectures. In this sense the optimisation is independent of clever programming techniques in the computer program itself; rather it is provided by adapting thc control instructions that are used to operate the underlying computer hardware, i.e. a more efficient set of control instructions are provided that are independent of high-level program function. Optimisation may involve improving the speed at which a computer implements a program for a fixed Cpu speed and/or making more efficient use of working memory, for example by reducing the amount of memory used and/or optimising memory readi'write operations. Hence, the embodiments described herein make a computing system implementing any machine code that results from embodiments work better, faster or more reliably in terms of its perfonnance; the computing system is better controlled to provide measurable, deep-level improvements.

By use of embodiments, it is also possible to make use of techthcal frmnctionality that was never available on the legacy mainframe systems, for example modem Intemet and networking functions that may be employed and linked in a suitable runtime environment. These advantages may be realised without the need to alter the original legacy computer program code. This is of benefit in mission critical computing systems, for example in health-care or transportation, where it is not possible to modify the computer program code for fear of failure or eror. As the original legacy program is not modified, a technical contribution provided by certain described examples is not provided within the computer program as such; indeed in mission critical computing systems, functionality of the computer program code must not change. The embodiments described herein do not relate to a better way to write a program; rather, they provide a measurable improvement as compared with fundamental programming conventions.

Certain embodiments described herein are arranged to be implemented on one or more computing systems, for example a system comprising one or more processors and a memory, such as a random access memory. The embodiments described herein do not comprise a method that is implemented manually or in the mind, indeed this is impossible. The term "deployment" is used herein to describe the process of placing an application program in a suitable form for execution by one or more processors.

Deployment may comprise an installation process that copies object or intermediate code to a storage device of a computer system and that configures said code for execution. This configuration may comprise registering the object or intermediate code with an operating system and/or a runtime environment. The phrase "preparing for deployment" is used to describe a compilation process that operates upon source code to producc intcrmediatc codc suitable for cxccution, which may comprise a frirther compilation step. In one case, both preparing for deployment and deployment may form part of a common process.

Embodiments comprise a computer system configured to prepare an application program for deployment into a runtime environment, the computer system comprising at least a compiler unit, the compiler unit comprising: a receiver part, configured to, with the at least one processor and memory, receive the application program, the application program comprising computcrprogram code in a programming language that is computing-system independent; a parser part configured to, with the at least one processor and memory, parse the computer program code of the application program for occurrences of at least one numeric variable, the at least one numeric variable being of a given numeric variable type, the given numeric variable type belonging to a plurality of numeric variable types that are defined in the programming language and that are not defined as native types in an intermediate language common to a plurality ofprogramming languages including the programming language; a determination part configured to, with the at least one processor and memory, for each numeric variable located in the parsing, determine whether one or more conditions associated with the data storage layout of the numeric variable arc met; a flag setting part configured to, with the at least one processor and memory: in response to the one or more conditions associated with data storage layout of the numeric variable being met, set a flag for the numeric variable to a value indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language; and in response to at least one of the conditions associated with data storage layout of the numeric variable not being met, set a flag fbr the numeric variable to a value that is not indicative of a candidate fbr conversion am the given numeric variable type to an integer type that is defined as a native type hi the common intermediate language; a compiler part configured to, with the at least one processor and memory, compile the computer program code to the common intermediate language to produce common intermediate language code, thc compiling comprising: converting any numeric variable with a flag value indicative of a conversion candidate am the first numeric variable type to an integer type that is defined as a native type in the common intermediate language; and converting any numeric variable with a flag value that is not indicative of a conversion candidate to a byte array; and a preparation part configured to, with the at least one processor and memory, prepare the common intermediate language code to code executable by a processor of the computing system, the executable code implementing the application program in a runtime environment.

lii embodiments, the one or more conditions associated with data storage layout of the numeric variable comprise one or more of the following: thc numeric variable is an independent item or a member of one or more groups none of which are explicitly referenced within the computer program code, the numeric variable is not referenced within the computer program code using reference modification, the numeric variable is not passed by reference to a sub-program within the computer program code, and the numeric variable is not referenced within the computer program code using an address operator.

The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged.

Certain executable code produced by the examples described above may be implemented by a runtime environment. This is sometimes alternatively referred to as a runtime system or runtime. It may generally be considered as a confrol system to implement a programming language. In certain cases it comprises a virtual machine for implementing bytecode or equivalent. It refers to system components that are present and usable at the time when executable code is loaded into memory to be executed by a processor, i.e. the time at which a computer program is run. The system components provide system resources, i.e. resources at an operating system level or below, to enable the computer system comprising the processor to operate as a programmed machine.

System resources may comprisc thc managcmcnt of threads (in single or multi-thrcaded environments), error and exit handling, file handling and file access and/or virtual machine code execution. The system components used by a runtime environment may comprise so-called system libraries. These are packages of executable code to provide the system resources. For example, they may comprise dynamic link libraries or associated assemblies in a Microsoft Windows environment. A set of one or more system libraries may comprise core runtime environment files and/or may comprise executable code relating to other application programs that is imported into the run-time environment.

Compilation as described herein may insert function calls to libraries that form part of the runtime environment. As such, a specific runtime environment is required to execute executable code generated by the described examples; the executable code would not run on a diffcrcnt runtimc environment.

Example embodiments are described above in relation to an application program containing a single numeric variable nI of var_type variable type. Embodiments can also be applied to application programs containing multiple numeric variable types, including multiple numeric variable types of different variable types.

It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope ofthc invention, which is defined in the accompanying claims.

Claims

Claims 1. A computer system configured to prepare an application program for deployment into a runtime environment, the computer system comprising a compiler unit, the compiler unit comprising: a receiver part, configured to, by way of at least one processor and a memory, receive the application program, the application program comprising computcrprogram code in a programming language that is computing-system independent; a parser part configured to, with the at least one processor and memory, parse the computer program code of the application program for occurrences of at least one numeric variable, the at least one numeric variable being of a given numeric variable type, the given numeric variable type belonging to a plurality of numeric variable types that are defined in the programming language and that are not defined as native types in an intermediate language common to a plurality ofprogramming languages including the programming language; a determination part configured to, with the at least one processor and memory, for each numenc variable located in the parsing, determine whether the following conditions are met: the numeric variable is an independent item or a member of one or more groups none of which are explicitly referenced within the computer program code; the numeric variable is not referenced within the computer program code using reference modification; the numeric variable is not passed by reference to a sub-program within the computer program code; and the numeric variable is not referenced within the computer program code using an address operator; a flag setting part configured to, with the at least one processor and memory: in response to all of the conditions being met, set a flag for the numeric variable to a value indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language; and in response to at least one of the conditions not being met, set a flag for the numeric variable to a value that is not indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language; a compiler part configured to, with the at least one processor and memory, compile the computer program code to the common intermediate language to produce common intermediate language code, the compiling comprising: converting any numeric variable with a flag value indicative of a conversion candidate from the first numeric variable type to an integer type that is defined as a native type in the common intermediate language; and converting any numeric variable with a flag value that is not indicative of a conversion candidate to a byte array; and a preparation part configured to, with the at least one processor and memory, prepare the common intermediate language code as executable code, the executable code being executable by a processor to implement the application program in the runtime environment.
2. A computer system according to claim 1, wherein the executable code comprises machine code and/or assembly code.
3. A computer system according to claim 1 or 2, wherein thc intcgcr type that is defined as a native type in the common intermediate language comprises a 32 or 64 bit integer type.
4. A computer system according to claim 1 or 2, wherein the common intermediate language comprises one of a common intermediate language within the NET framework, a language within the Mono framework and Java bytecode.
5. A computer-implemented method of preparing an application program for deployment into a runtime environment of a computing system, the method comprising: receiving, at a compiler unit, the application program, the application program comprising computer program code in a programming language that is computing-system independent; parsing thc computer program code of the application program for occurrcnces of at least one numeric variable, the at least one numeric variable being of a given numeric variable type, the given numeric variable type belonging to a plurality of numeric variable types that are defined in the programming language and that are not defined as native types in an intermediate language common to a plurality of programming languages including the programming language; for each numeric variable located in the parsing, determining whether the following conditions are met: the numeric variable is an independent item or a member of one or more groups none of which are explicitly referenced within the computer program code; the numeric variable is referenced within the computer program code using reference modification; the numeric variable is passed by reference to a sub-program within the computer program code; and the numeric variable is referenced within the computer program code using an address operator; in response to all of the conditions being met, setting a flag for the numeric variable to a value indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language; and in response to at least one of the conditions not being met, setting a flag for the numeric variable to a value that is not indicative of a candidate for conversion from the given numeric variable type to an integer type that is defined as a native type in the common intermediate language; compiling the computer program code to the common intermediate language to produce common intermediate language code, the compiling comprising: converting any numeric variaNe with a flag value indicative of a conversion candidate from the first numeric variable type to an integer type that is defined as a native type in the common intermediate language; and converting any numeric variable with a flag value that is not indicative of a conversion candidate to a byte array; and preparing the common intermediate language code as code executable by a processor of the computing system to implement the application program in the runtime environment of the computing system.
6. A computer-implemented method according to claim 5, wherein the executable code comprises machine code and/or assembly code.
7. A computer-implemented method according to claim 5 or 6, wherein the integer type that is defined as a native type in the common intermediate language comprises a 32 or 64 bit integer type.
8. A computer-implemented method according to any of claims 5 to 7, wherein the common intermediate language comprises one of a common intermediate language within the NET framework, a language within the Mono framework and Java bytecode.
9. A computer program comprising a set of instructions, which, when executed by a computerised device is configured to perform the method of any one of claims 5 to 8.
10. A computer-readable storage medium having recorded thereon the computer program of claim 9.
11. A computer system for deploying an application program comprising: a runtime environment arranged to support execution of the application program by way of at least one processor and a memory, the runtime environment comprising: one or more system libraries comprising executable code to implement at least the runtime environment on the computer system, the one or more system libraries comprising: one or more classes configured to load a first sct of executable code representative of the application program from a computer-readable storage medium, wherein the fir st set of executable code comprises code prepared by the computer system of any one of claims I to 4; a first set of functions arranged to instruct the at least one processor to store, in a first manner in the memory, variables of an integer type; and a second set of functions arranged to instruct the at least one processor to store, in a second manner in the memory, byte arrays, wherein the executable code, by way of a virtual machine, is arranged to instruct the at least one processor to use the one or more system libraries, wherein the at least one processor is arranged to use the first set of functions to store in memory one or more variables of a native integer type that are defined in theexecutable code, andwherein the at least one processor is arranged to use the second set of functions to store in memory one or more variables of a byte array type that are defined in theexecutable code.
12. A computer-implemented method to deploy an application program into a processing environment comprising: loading object code into memory, said object code being derived from executable code generated by a computer-implemented method according to any one of claims 5 to 8; processing said object code by way of at least one processor communicatively coupled to said memory, said processing comprising: responsive to said object code comprising one or more variables defined as a native integer type, executing a first set of executable code by way of the at least one processor and the memory, the first set of executable code forming part of one or more system libraries arranged to implement a runtime environment, the first set of executable code implementing a first set of one or more functions arranged to instruct the at least one processor to store, in a first manner in the memory, variables of an integer type, and responsive to said object code comprising one or more variables defined as byte arrays, executing a second set of executable code by way of the at least one processor and the memory, the second set of executable code forming part of one or more system libraries arranged to implement a runtime environment, the second set of executable code implementing a second set of one or more frmnctions arranged to instruct the at least one processor to store, in a second manner in the memory, byte arrays.
13. A computer program comprising computer program code arranged to, when loaded into system memory and processed by one or more processors, cause said one or more proeessers to implement the computer-implemented method of claim 12.
14. A computer-readable storage medium having recorded thereon the computer program of claim 13.
15. A computer system, substantially as hereinbefore described with reference to the accompanying drawings.
16. A computer-implemented method substantially as hereinbefore described with reference to the accompanying drawings.