Title: Using Function Calls as Compiler Directives

Description

The invention refers to methods for compiling high level language code to assembly and/or object code. In detail it shows an efficient method to pass compiler directives e.g. target machine dependent hints to any transformation and/or optimization and/or emitting stage inside the compiler.

The invention is for example applicable for compilers for traditional processor architectures such as CISC, RISC, VLIW, massive parallel computers, reconfigurable processors or coprocessors such as FPGAs, PACT XPP processors, and any combination of those architectures or machines.

The invention is for example appropriate to modern languages such as C, C++, and especially JAVA, but also traditional languages such as FORTRAN, PASCAL.

Reconfigurable architectures are for example devices (VPU) which a plurality of elements being configurable in function and connection at runtime. Such elements can be and/or comprise for example Arithmetic Logic Units (ALUs) , FPGA elements such as CLBs, Input/Output cells, memories, analog units and so on.

The Invention is applicable in particular with FPGAs such as e.g. . XILINX Virtex, ALTERA, and/or (re) configurable proces-

- i -

sors such as e.g. PACT XPP, AMBRIC, MATHSTAR, STRETCH and/or processors e.g. STRETCHPROCESSOR, CRADLE, CLEARSPEED, INTEL, AMD, ARM. The (re) configurable processors can be coarse granular and/or mixed coarse and fine granular data process- ing cells in e.g. a two- or higher dimensional array that also may have a plurality of different cells, e,g, storage cells. Each cell or a plurality of the cells can be configurable and/or reconfigurable at run time and may be adressable for configuration and/or reconfiguration. It is preferred if a configration /reconfiguration can be effected without adversely impairing other cells.

It should be noted that major aspects of the VPU technology, to which the invention is inter alia applicable are described in the following patents and patent applications of the applicant, though none of the features disclosed therein is to restrict the present invention to only devices or parts thereof or methods having features as described thereinn:

P 44 16 881.0-53, DE 197 81 412.3, DE 197 81 483.2,

DE 196 54 846.2-53, DE 196 54 593.5-53, DE 197 04 044.6-53, DE 198 80 129.7, DE 198 61 088.2-53, DE 199 80 312.9, PCT/DE 00/01869, DE 100 36 627.9-33, DE 100 28 397.7, DE 101 10 530.4, DE 101 11 014.6, PCT/EP 00/10516, EP 01 102 674.7, DE 102 06 856.9, 60/317,876,

DE 102 02 044.2, DE 101 29 237.6-53, DE 101 39 170.6, PCT/EP 03/09957, PCT/EP 2004/006547, EP 03 015 015.5, PCT/EP 2004/009640, PCT/EP 2004/003603, EP 04 013 557.6, EP 05 020 772.9, EP 05 003 174.9, EP 05 017 798.9, EP 05 017 844.1,EP 05 027 333.3, , DE 10 2006 003 275.6, DE 10 2006 004 151.8, EP 06 400 003.7, EP 06 001 043.6. DE 10 2007 056 505.6, DE 10 2007 056 806.3,

DE 10 2007 057 642 . 2 .

All listed documents are included in this patent applications for disclosure in particular regarding details of a target architecture. The object of this patent application is to provide new technologies for commercial exploitation.

Parts of this kind are known for example from the applicants XPP processor technology. It comprises at least a one or multi -dimensional e.g. 2 -dimensional arrangement of so called PAEs (processing array elements) . PAEs are for example arithmetic and/or logic and/or analog elements, memory units, network or connectivity, and/or units for external communication (10) . PAEs are connected together via one or multiple bus systems which can be implemented hierarchically segmented and/or operated at clock frequencies different from clock frequencies of PAEs . PAEs of any kind can be arranged in any combination or hierarchy, which arrangement is called PAE- Array or PA.

In addition to XPPs or VPUs the invention is applicable to other technologies, such as systolic Arrays, neuronal nets, multi processor systems, processors comprising multiple proc- essing units and/or cores, logic units, network devices, crossbar switches and FPGAs, DPGAs and the like e.g. those mentioned above.

When compiling source code, for example C code, for a spe- cific hardware, for example reconfigurable processors, it is often necessary to provide additional information to the compiler that is not part of the standard programming language.

Examples include annotations for partitioning, for certain optimizations as loop unrolling or for accessing special hardware blocks like streaming IO ports.

Traditional ways of providing such information include:

• Using language extensions specific for one or several compilers. The disadvantage is that the resulting source code can no longer be compiled with other compilers for the same language. • Use comments with specific contents. The disadvantage is that comments are removed at an early stage of the compilation and are no longer available for latter compiler stages.

• Where available, use compiler specific hints and/or di- rectives as defined by the programming language standard, for example #pragma in the C programming language. Those hints can be ignored by compilers not implementing and/or understanding them. The disadvantage is again that those hints may not be available to latter stages of the compiler and/or cannot be uniquely associated with a certain part of the source code.

This invention shows a new approach that avoids all disadvantages described above. Hints and/or directives are embedded into the source code as standard function calls with specific names. The resulting source code can still be compiled with any compiler, just by giving an empty function definition. The function calls are visible at all stages of the compiling process. And their location allows to uniquely identify the parts of the source code they apply to, again in all compilation stages.

These advantages will be further detailed in the following sections .

The Structure of a Compiler As a basis for a more in-depth discussion, the general structure of a compiler is described:

A compiler works in several stages, each working on the results computed by the previous stages.

The first stage is called Preprocessing. This stage is optional, but implemented by most compilers. It removes and/or expands certain constructs used by the programmer for convenience. Examples are including other source files and expanding macros. Comments are usually removed at this stage.

The second stage is the Compiler Frontend. It parses the source code and creates a compiler internal representation of the program, for example as dataflow and control graphs. This frontend can contain language extensions that add hardware specific information to the internal representation.

The third stage, called Optimization, works on the internal representation generated by the frontend. It includes various transformations for modifying, compacting or extending the program. During this stage, the structure (for example as dataflow and control graphs) can be changed significantly from the original code. For that reason, uniquely identifying certain lines in the source code with certain parts in the internal representation becomes difficult, if not impossible.

The last stage is the Compiler Backend. This is the part that generates (emits) the code for a specific hardware, based on the optimized internal representation of the program.

The reason for this multi-stage approach is to make the compiler modular. Compilers typically contain various frontends for different programming languages, for example C, C++, Java, Fortran, and several backends generating code for different hardware architectures, for example various RISC, VXiIW and reconfigurable processors. The compiler must be able to combine any frontend with any backend, so that all supported input languages can be compiled for any supported hardware platform. That means, the compiler frontends are language specific, but should not contain any hardware specific parts. The other way around, compiler backends are hardware specific, but should not contain any language specific parts.

Requirements for Compiler Hints and Directives

From above descriptions we arrive at the following require- ments to be met by any compiler-specific hints and directives that are not part of the standard input language:

• The source code containing the hints and directives should still properly compile with any other compiler for the same programming language, resulting in a work- ing binary.

• All frontends, that means all input languages, must be able to handle the hints and/or directives used during optimization and in the backends.

• All backends must work properly with all hints and/or directives, even if not all backends implement all of them.

• The hints and/or directives must be available in all stages of the compilation process, especially in the backends that optimize for a particular hardware.

• If a hint or directive is associated with a certain part of the program, this association must be intact in all stages of the compilation process. That means, the part of the compiler internal representation, to which the hint or directive applies, must be uniquely identifiable.

State of the Art

The following methods to pass directives to the compiler are known by the state of the art .

• Language extensions, if implemented carefully, can ful- fill all requirements, but according software code needs to compile on other compilers and/or target platforms too. Source code containing hints and/or directives for a certain compiler can no longer be compiled on other compilers, that do not implement the same language ex- tensions.

• Compiler hints and/or directives conforming to the input language, as for example the C #pragma directives, can be ignored by other compilers, but they are usually not preserved well over the compiler stages. Even if they are still available in the backend, it is impossible to exactly identify the part of the internal representation they refer to after optimization. Moreover, not all input languages, that means not all frontends, provide this kind of standard construct for compiler specific hints and directives.

• Comments are usually removed in an early compilation stage. Even if comments are preserved in the internal representation of the program, they suffer the problem that it is impossible to exactly identify the part of the internal representation they refer to after optimization.

Function Calls for passing compiler directives

This invention is using standard function calls for compiler hints and/or directives, with the following properties:

• All functions used as hints and/or directives start with a specific prefix to easily distinguish them from other real function calls. This distinction is necessary for both the programmer and the compiler. • The source code contains proper function declarations and empty definitions of these functions.

The requirements for this new approach for implementing com- piler hints and/or directives are discussed below:

• To other compilers a hint or directive looks just like an empty function call that can be optimized away. The source code can be properly compiled to a working binary. • Function calls are part of all programming languages, so the same hints and/or directives can be supported by any existing or future compiler frontend. Moreover, new hints and/or directives can be added, without any modification to the frontend.

• A backend not implementing a certain hint or directive sees it as an empty function call that can be optimized away.

• Function calls are an integral part of the internal rep- resentation of a program and hence are properly preserved over all stages of the compilation process.

• Function calls are linked to the semantics of the programming language. These semantics must be preserved in the internal representation over all compilation stages. This makes it possible to uniquely identify the part of the internal representation, a hint or directive formulated as a function call refers to.

Thus, what has been suggested is a method for passing compiler directives into a compiler wherein empty function calls are defined, which call no function, but define compiler directives by its name. Thus, by allowing empty functions calls and by handling them automatically, in particular in the automated way suggested, significant improvements over the prior art can be obtained.