WO2001016719A1

WO2001016719A1 - Method and device for translating a program unit

Info

Publication number: WO2001016719A1
Application number: PCT/DE2000/002856
Authority: WO
Inventors: Andreas Geisler
Original assignee: Siemens Aktiengesellschaft
Priority date: 1999-08-26
Filing date: 2000-08-22
Publication date: 2001-03-08

Abstract

According to the inventive method for translating a program unit, the program unit references several modules. If one of the modules has a more recent time stamp than a preexisting translation of the program unit, the program unit is translated. Otherwise there is no new translation of the program unit.

Description

description

Method and arrangement for translating a program unit

The invention relates to a method and an arrangement for translating a program unit.

A program unit is in particular a program code (also: source code) comprising several modules of a given programming language, which is to be translated by means of a compiler

The program unit includes a definition unit that references one or more declaration units, i.e. refers to this. For each unit of declaration there is a definition unit that defines the declared part, i.e. filled with content.

In the example of a C program, there are so-called H files as declaration files and so-called C files as definition files. The program unit's C file references several H files, whereby an H file can in turn contain several H files. The "#mclude" instruction common to the C programming language is usually used for this purpose, which inserts a (declaration) file in the place of this instruction during translation.

Since there are enormous amounts of H files (and corresponding C files) in large systems, it takes a long time to translate the entire program unit. This is particularly disadvantageous because often only individual C files are worked on and a translation of the entire system (all H files including the definition unit of the program unit) can be omitted.

It should be noted that a general distinction is made between the translation process (compiling process) and a binding process (linking). In the above example of the C program, so-called ob ect files (also O-files) are generated, which in particular each include a C file (the program unit also includes a C file) and the H files referenced therein. The declarations mentioned in the H files for translating the C file into an O file are required, but not the definitions of the declarations! The definitions (further C files) are translated into an O file, whereby each C file can refer to no, one or more H files (here: contain). The O-files are combined in the binding process to form an (executable) program. A library file can also be created from the O-Files.

The object of the invention is to carry out a translation of a program unit only when this is necessary.

This object is achieved in accordance with the features of the independent claims. Further developments of the invention also result from the dependent claims.

To solve the problem, a method for translating a program unit is specified, in which several modules are referenced by the program unit. The program unit is translated if one of the modules is a younger one

Has a timestamp as an existing translation of the program unit, otherwise the program unit is not re-translated.

The time stamp preferably represents a date for the time when the module or the program unit was last saved. A change of a module or the program unit is usually completed with the last storage. If the date of the last saving of the translation of the program unit (O-file) is later than any date of the storage of a module, the program unit does not have to be translated again. In the other case, the program unit is translate again. This ensures that the translated program unit always has the most recent date compared to (the source code) the program unit and the modules referenced therein.

It should be noted here that even the program unit itself is a module to be translated, e.g. em C-file, the program unit references several other modules, i.e. refers to these other modules.

A further development consists in the fact that the translation of the program unit, and thus also the modules contained therein, is carried out as soon as a module is determined with a newer (= younger) time stamp than the program unit already translated.

This advantageously enables the earliest possible decision as to whether a translation is necessary or not.

In particular, it is a further training to translate all modules referred to when translating the program unit.

One embodiment consists in that (at least) one interface compiler is translated by an interface compiler if there is no translation of the interface module yet or the interface module is more recent than an existing translation of the interface module.

Another embodiment is that the interface module is not translated if the translation of the interface module already exists and the interface module itself is not more recent than its translation. In this case the translation is the most current version, a further translation would be a waste of time. It is also a further development that the program unit is re-compiled as soon as a used interface module has been compiled by the interface compiler.

Another embodiment is that the translated program unit is used to control or to design a technical system.

Another embodiment comprises the use of the program unit as an executable program or a part of the same.

As part of additional training, the program unit can be part of a library module. Especially when used in a large software system, it is common to make a functional part accessible to other programs in the form of a library. The library comprises a predetermined, mostly generally applicable, selection of functions which can be used in many ways. For this purpose, the library is integrated into an executable program, the module can then use the predefined functions of the library.

Another development is that the program unit in a common programming language, e.g. the programming language C, C ++, Java, FORTRAN, BASIC or PASCAL.

Furthermore, to achieve the object, an arrangement for translating a program unit is provided, which has a processor unit, which processor unit is set up in such a way that a) the program unit can be specified in the form of a plurality of modules which reference one another; b) the program unit is translated if one of the modules is more recent than an existing translation of the program unit; c) otherwise the program unit is not re-translated.

This arrangement is particularly suitable for performing the method according to the invention or one of its developments explained above.

Embodiments of the invention are illustrated and explained below with reference to the drawing.

Show it

Fig.l is a tree diagram depicting dependencies on modules contained in a program unit;

Figure 2 is a sketch illustrating a translation process;

3 shows a sketch which represents a combination of translation (compilation) and binding (left);

Figure 4 is a sketch showing a translation of interface modules;

5 shows a section of a program code;

6 shows a processor unit.

A tree diagram is shown in FIG. 1, which shows dependencies on modules contained in a program unit 101. The program unit 101 with the file name “test.c” contains program code to be translated (also: source code or source code) in a programming language, for example in the programming language C. Three modules 102 “filel.h”, 103 “file2. h "and 104" file3.h "are referenced. The de- in the referenced modules 102 to 104 Clarified instructions are required by program unit 101.

The following example explains the difference between definition and declaration: The declaration file "filel.h" contains declarations (prototype agreements) of functions that are defined or implemented in the file "filel.c". For the translation of the program unit 101, only the declaration is necessary; the definition of the declared function is not made at the time of the translation, but at the l.d.R. later bandages taken into account. Accordingly, the implementation "filel.c" can be changed regardless of a new translation of the program unit. In this case, only the file "filel.c" has to be translated; when an executable file or a library from the program unit 101 is created, the translated file "filel.c" is linked to the translated file "test.c" ( "linked").

Module 103 refers to another module 105 "fιle4.h" and module 104 refers to modules 106 "file5.h" and 107 "fileβ.h", which in turn refers to modules 108 "fιle7.h", 109 "fileδ .h "and 110" fιle9.h "refers.

The process of translating is illustrated again in FIG. The tree from FIG. 1 with the program unit and the modules 102 to 110 is contained in a block 202. The translation (compilation) of the program unit results in an O-file "test.o" 201. This O-file contains object code and is preferably used as input for a subsequent binding process (linking). The program unit is translated as soon as a module is discovered that is newer than the file (the O file) of the previous translation.

This relationship is illustrated in Fig.3. A block 301 shows how a file "filel.c", among other things, references the file "filel.h" and how a file "filel.o" 302 is created as a result of a translation process. Analogous co ⁾ tv> NJ P> cn σ cn O (_π Lπ

Ό ^ CΛ ≤ CΛ 1 CΛ φ

P- P rf o P- rr Pf n P φ uq P- P P Φ t Hi

• g uq CP ¹ »fl o tr PJ σ (Ji § Φ P ¹ H P-

- PJ rr cn N r + u φ uq r + N φ P J> rt

P N 2 α N φ Φ pr P in φ

PP ¹ c P P- PS Φ α pi Φ

CL P P- P uq PJ ts Φ P- α P tr tr P rt CΛ Φ tr P cn io ö P P to 3 tl Φ rt Φ Φ

O Φ tr φ Hl Φ P P P P

3 Pn P ω DJ P P σ ω 3 Φ pi ≥;

TJ P * P- o So P p- PJ Φ P- Φ φ

P- P 3 o pr rr P- rt rt Hl i

P- - 'rt P uq 3 φ N o ≥! c φ r + * •• tr Φ P φ P P- P ¹ > φ tr

P P- φ P- P rt ts uq C c Φ

1 O f tr ω uq φ V) P; P o 2 φ c tr P £ φ P cn tr ω

TJ P p Φ CΛ Φ P- 3 α n Φ φ r + <! uq ω CΛ tf φ Φ pr P rt

P o _^ - onn φ tr p ⁾ P <cn N

O 3 CΛ <! P tr tr P P- Φ P p o o 3 Φ Φ pι rt r + P φ <t p Φ P- 3 cn P J rt N uq

3 PJ P rt o Φ tr c

P C PJ Φ rr ^ uq P Φ J pi tr P- ω C Φ o Φ P C uq Φ

CD PJ CΛ CΛ 3 PS cn cn p er φ Pi P PJ 3 0 »o tr α o P ^J P Φ P PJ tl α Φ Φ φ CΛ rt φ s: t P CΛ P 3 p: rr PPO -J

P- 3 o P 0- rr P pf t uq * _* P tr CΛ Φ o Φ Φ PJ Φ PJ i n- rt PJ * PP n 3 P P-

P P p P P-tr o rt

Ξ P - Φ rt φ tr <! 3 rt <V uq rt fD Φ Φ 3 PJ P Φ Φ Φ P P CΛ

P X? P P φ rr o PJ rt

P- N Φ <v r + CΛ CΛ Φ p- u 3

• n P P- o Φ P P <§: P 3 P ¹

3 Cd P o ω P- rr P φ P- DJ φ P ¹

• rt uq O n N tr P P P φ

0 ⁾ P t tr rt PJ 3 i pi

Pn tr (D φ Φ P cn • n tr 1

P 3 tf s: c TJ o φ S

P Φ 3 Φ p φ P-. P o

2 Φ o σ P uq N o φ rt P_

CΛ 0 tf tu CΛ P P • p:

P tr ω ri- Φ. φ N α P ¹ n NP rt- Φ P PJ ¹ c PJ ω pr s: PP P- rt P- ¹ u P

TJ • 1 = • CΛ φ CΛ uq C l-h o P- α s: Φ V

PJ sr - ¹ ω φ l O. o Φ P ¹ Hl P

Φ 1 tr P; cn PJ Φ P φ

1 1

c) to define namespaces for variables (keyword "project"); d) to import other agreement files (keyword "mclude").

EXAMPLE:

The modules "List.cpp", "Stack. Cpp" and "Queue. Cpp" are located in a directory "/ home / schmidt / bulk / src". The interfaces to these modules are in the directory

"/ home / schmidt / bulk / mclude". The modules are to be combined into a library "libbulk.a". There is also a module "bulktest. Cpp" in the directory "/ home / schmidt / bulk / src / test" with which the library is tested and which is to be linked with the library to form an executable program. Object code generated with the translation should be saved in a directory "/ home / schmidt / bulk / debug". Furthermore, there is a library m in the programming language C in a directory "/ home / schmιdt / lιb / lιbutιl. A", which is to be used to implement the C ++ classes. The interfaces to this C library are in a directory "/ home / schmidt / mclude".

VARIABLES AND COMMENTS

The usual comment brackets / * ... * / are used in Fig. 5 lines 10-40. The slashes used in line 80, which introduce single-line comments, are also used for commenting.

Lines 60-110 define variables. The syntax for defining variables is:

vaπableDef = identifier (value | vaiueüst) vaiueüst = "{" {value} "}" value = "<" refIdent ^,, > ^, '{{vιsιbleChar} ["<" refIdent ">"]} | vιsbleChar {{vιsιbleChar} [ "<" refIdent ">"]} refldent:: = [projectName "."] identifier projectName:: = identifier

The definitions given correspond to the Backus-Naur form (BNF), which is briefly explained below. The letters A, B and D represent syntactic expressions that can be used on both sides of the definition character ":: =". The characters x, y and z represent visible characters from the ASCII character set.

A list of values of any length can be assigned to a variable. Identifiers are structured as in the programming language C; "visibleChar" are all visible characters except the characters "<" and ">" used for variable replacement.

In line 70, the value of a variable is referenced using angle brackets. So after line 70 parsing, the definition is

objDir / home / schmidt / bulk / debug.

The "objDir" variable belongs to variables that have a certain meaning. With the value of "objDir" the compiler is set to write the generated code in the directory to which this variable points. Analogously mean:

Lines 130-230 define C ++ compilers, options and search paths. The search paths are not only used to parameterize the compiler and linker, but also to ensure that affected program files (source code) and object files can be found and their last modification time can be determined.

Furthermore mean:

TARGETS

Lines 250-470 describe the composition of the test program and the library. The general syntax for the definition of so-called targets, i.e. executable programs or libraries is:

target:: = targetKind value "{" {vaπableDef} "}" targetKind:: = "executable" | "hbrary".

Target identifiers preferably do not contain file extensions. This simplifies porting to other formats.

A target forms its own namespace for variables. The user preferably defines the following variables within a target:

The libraries (without file extensions) that are used by the target's modules are listed under the "libs" variable. This information is irrelevant for the command to create a library, but it is important for the generation of a correct link command for executable targets. If libraries depend on one another, it is important for most linkers in which order the libraries are called. If the variable "libs" is defined within a library target X, the libraries specified there need within Exe cutable targets that use X will no longer be paid, unless it is desired explicitly dynamic or stati ^¬ MOORISH binding. The following variables can be used for this:

The last two variables mentioned are useful if the module is not in the form of a library, but rather as individual object files.

The following definition, usually within a library target, indicates whether the creation of a shared library, a static library or both is desired:

hbKind static | shared | both.

The default is "static".

VISIBILITY AND SUBSTITUTION OF VARIABLES Variables can be redefined within targets. A typical application is the redefinition of global compiler options or directory variables (objDir, libDir etc.) for a specific target. In the example, the "srcDir" variable has been redefined within the "bulktest" target, which hides the global definition. A variable is substituted by its value as follows: First the variable is searched for in the namespace of the current target. If the variable is not found there, If available, the search is carried out in the namespace of the surrounding project (see project term below). If the search also fails here, the search is global. If the variable is not defined there either, a search is carried out in an operating system environment (eg using the standard function "getenv"). Immediately after reading in an identifier surrounded by angle brackets, it is replaced by its value. If the value is a list, the embedding value also becomes a list if it was not previously.

COMMANDS GENERATED FROM THE EXAMPLE

With the agreement file discussed above as input, and provided that all modules have to be recompiled due to their last modification time, with one call

aim -f bulk.aim

generates the following commands (here especially for Unix as an operating system assumed as an example):

cd / home / schmidt / bulk / src;

CC stack. cpp -I / home / schmidt / include -I / home / schmidt / bulk / include -c -g + al

-f-eh -o / home / schmidt / bulk / debug / Stack.o;

CC List. cpp -I / home / schmidt / include -I / home / schmidt / bulk / include -c - g -f-al H-eh -o / home / schmidt / bulk / debug / List.o;

CC queue. cpp -I / home / schmidt / include -I / home / schmidt / bulk / include - c -g + al + eh -o / home / schmidt / bulk / debug / Queue.o;

rm -f /home/schmidt/bulk/debug/libbulk.a; cd / home / schmidt / bulk / debug; ar ru /home/schmidt/bulk/debug/libbulk.a stack. o List.o Queue. O;

cd / home / schmidt / bulk / src / test;

CC bulktest.cpp -I / home / schmidt / bulk / include -c -g + al + eh -o / home / schmidt / bulk / debug / bulktest.o;

cd / home / schmidt / bulk / debug;

CC -g + al + eh bulktest.o -L / home / schmidt / lib - L / home / schmidt / bulk / debug -Ibulk -lutil -o / home / schmidt / lib / bulktest;

cd / home / schmidt / bulk;

The file "libbulk.a" is preferably deleted before the new translation, since a new version could contain fewer modules than the previous one. Furthermore, the search paths are automatically added to the relevant commands using the corresponding variables. Before translation and link commands, if necessary, a change is made to the directory in which the source texts or object modules are located. Finally, a change is made to the directory from which the new translation was started.

PARSING FROM # INC LUDE INSTRUCTIONS

When determining the dependencies of the modules, the

Source files "#include" statements read out. Only those files are preferred that are enclosed in double quotation marks ("...") in an "#include" statement. Angle brackets should generally only be used for headers that are not part of the ongoing software development, eg for system headers or interfaces to external (purchased) products. Conditional compilation ("#ifdef") is not taken into account when parsing the "#include" instructions. EXTENSION OF THE EXAMPLE TO THE CLIENT SERVER APPLICATION In order to demonstrate how calls to the IDL compiler are generated, the example of Fig. 5 is extended by the following target:

serverExt S.cpp clientExt C.cpp clientHeaderExt .h idIComp idl idIOptions {-s <serverExt> -c <clientExt> -h <clientHeaderExt>}

target bank

{serverSources

{BankIDL.idl AccountIDL.idl

} sources

{Account. cpp

Bank. cpp bank_main.cpp}

}

So-called server modules, which are generated by the IDL compiler from the interfaces listed in the "serverSources" variable, are compiled and linked to the program (linked).

In order to create a corresponding client module, the previous "bulktest" target is expanded as follows:

executable bulk test { ... // as in Fig. 5 clientSources

{BankIDL.idl AccountIDL.idl

}

... // as in Fig. 5

}

Client modules that are generated by the IDL compiler from the interfaces listed in the "clientSources" variable are also compiled and linked to the program.

In the overview of the above statements, the following variables are used:

The variables are evaluated to structure the calls to the IDL compiler as described using the example of the ". Cpp" compiler. Accordingly, the variables "id-lComp", "idlOptions", etc. must be defined in particular. The example shows a typical assignment of these variables when using a CORBA implementation. STRUCTURING LARGE PROJECTS

If several interdependent program systems, each with several targets, are processed at the same time, the definition of so-called namespaces for variables makes sense. The syntax of a namespace ("project") is:

project = "project" identifier "{" {definition} "}" definition = target | variableDef | include include = "include" value

Variables within a project can be preceded by the project name, followed directly by a "." in connection with the variable name can be accessed (see BNF production "refldent").

"Include" statements can be used within projects. If a description file X has already been read in, the following instructions "include X" have no effect, multiple imports of the same file extension are therefore excluded.

For the sake of completeness, the definition of BNF production for a complete description file in the above sense should be mentioned here:

aimDescription:: = {definition | project}

CALLING THE GENERATOR The generator (hereinafter referred to as "Aim generator") converts the description file and thus - at least indirectly - generates the desired results (files):

A call syntax of the is:

aim {option} [targetName [subtargetName]]. The following special features apply when calling:

- If no target is specified, all targets found in the description file are created.

- If a target is specified, only this is processed. By specifying a "subtargetName" a single

Module translated, provided that it is named in the "sources" variable in the "targetName" target.

- A reason is given for each generated update command, e.g. by listing the include relationship and outputting the modification times of Target and the source file that is younger than the target.

- Some linkers create executable programs, even if they contain unresolved symbols. However, these programs then have no execution rights.

- After the generator has been terminated and the description file has been processed, feedback on the termination is output (also when using the "-s" option), which includes the number of updates required and the number of updates actually carried out.

OPTIONS

The following extensions can be used for "option":

ENVIRONMENTAL VARIABLE OF THE GENERATOR

When the generator is called, the environment variable "aimopt" is evaluated and its content added to the command line options. With "aimopt" standard options can be defined (e.g. paths that have to be considered when searching for files).

RETURN VALUE As the return value, the generator delivers a number of actual update processes (e.g. compiler or linker calls). In the event of an error, the value "-1" is returned,

A processor unit PRZE is shown in FIG. The processor unit PRZE comprises a processor CPU, a memory SPE and an input / output interface IOS, which is used in different ways via an interface IFC: an output is visible and / or displayed on a monitor MON via a graphics interface output to a printer PRT. The input is made using a mouse MAS or a keyboard TAST. The processor unit PRZE also has a data bus BUS, which ensures the connection of a memory MEM, the processor CPU and the input / output interface IOS. In addition, additional grain components can be connected, e.g. additional memory, data storage (hard disk) or scanner.

Claims

claims

1. Method for translating a program unit, a) in which several modules are referenced by the program unit; b) in which the program unit is translated if one of the modules is more recent than an already existing translation of the program unit and c) in which the program unit is otherwise not translated again.

2. The method of claim 1, wherein the translation of the program unit is carried out as soon as a module of a more recent date than the already existing translation of the program unit is determined.

3. The method according to claim 1 or 2, in which the modules are also translated when the program unit is translated.

4. The method as claimed in one of the preceding claims, in which an interface module which is present as an additional module is translated by an interface compiler if no translated interface module exists or the at least one interface module is younger than its already existing translated interface Module is.

5. The method of claim 4, wherein the interface module is not translated if the translated interface module already exists and the interface module is not younger than the already translated interface module.

6. The method according to claim 4 or 5, wherein the program unit is re-translated as soon as the interface module has been compiled by the interface compiler.

7. The method according to any one of the preceding claims, wherein the translated program unit is used to control or to design a technical system.

8. The method according to any one of the preceding claims, wherein the program unit is an executable program or a part thereof.

9. The method according to any one of the preceding claims, wherein the translated program unit is contained in a library module.

10. The method according to any one of the preceding claims, wherein the program unit is written in a common programming language.

11. Arrangement for translating a program unit with a processor unit, which is set up in such a way that a) the program unit can be specified in the form of a plurality of modules referencing one another; b) the program unit is translated if one of the modules is more recent than an existing translation of the program unit; c) otherwise there is no renewed translation of the program unit.