DE102013208418A1 - Method for producing executable data file in computer system, involves linking compiled device codes and host codes to generate linked device code and linked host code that are used for producing executable data file - Google Patents

Abstract

The method involves compiling host codes (112,122) and device codes (114,124) that are accessed by source files. The host codes and device codes are executed by CPU and graphics processing unit respectively. The compiled device codes are linked to generate a linked device code (145). The compiled host codes are linked to produce a linked host code (165). An executable data file (160) is generated, based on the linked device code and linked host code. An independent claim is included for system for producing executable data file.

Description

FIELD OF THE INVENTION

Embodiments of the present invention generally relate to graphics processing units (GPUs) and heterogeneous environment compilers (e.g., GPU and CPU).

BACKGROUND OF THE INVENTION

Software executables are typically generated by compiling separate host objects, each host object comprising a corresponding portion of source code or host code (e.g., in a high level language such as C, C ++ written, etc.). The executable file generated by the compiler includes object code that can be executed by a central processing unit (CPU). Recently, host systems including a CPU and a graphics processing unit (GPU) have begun to take advantage of the GPU's parallel processing capability to perform tasks that would otherwise be performed by the CPU. The GPU executes device code, while the CPU executes host code. The device code is typically embedded in the host code as a single file, thus creating a heterogeneous compiler environment.

Conventional host linkers or compilers create an executable file from multiple host objects. These conventional host linkers, however, are unable to link device code embedded in multiple host objects, and therefore require that some device code be embedded in a single host object. For example, conventional host linkers may include an executable file from a first host object that includes only host code (for execution by the CPU), and a second host object, host code (for execution by the CPU), and Generate device code (for execution by the GPU). However, conventional host linkers are unable to generate an executable file from multiple host objects, each containing respective host code (for execution by the CPU) and corresponding device code (for execution by the GPU) the conventional host linkers are unable to properly link or associate the corresponding device code embedded in each of the host objects.

SUMMARY OF THE INVENTION

Accordingly, there is a need to create executables from multiple host objects that include corresponding host code and corresponding device code. Embodiments of the present invention provide a new solution that supports the separate compilation of host code and device code used in a heterogeneous programming environment. Embodiments of the present invention are operable to link device code embedded within multiple host object files using a separate device link operation. Embodiments of the present invention may extract device code from their respective host object files and then link together to form linked device code. This linked device code may then be embedded back into a host object generated by embodiments of the present invention, which may then be passed to a host linker to form a host executable file. As such, device code may be separated into multiple files and then linked together to form a final executable file using embodiments of the present invention.

In particular, in one embodiment, the present invention is implemented as a method for generating an executable file. The method includes compiling a first portion of program code and a second portion of program code accessed from a plurality of different source files, the first portion having instructions that are executed by a central processing unit (CPU), and wherein the second part of code has instructions to be executed exclusively by means of a graphics processing code (GPU). In one embodiment, the second part of code is written in a version of a compute unified device architecture programming language (CUDA). In one embodiment, the method of compiling further comprises separately compiling the first part and the second part of code.

In one embodiment, the method of compiling further comprises generating an analogous coded entity, wherein the first part of code is operable to access data from the second part of code using the analog coded entity. The method also includes merging the first part of code that is compiled to produce a linked first part of code. The method also includes concatenating the second part of code that is compiled to produce a linked second part of code. In one embodiment, the method of merging the second part of code further comprises generating a shell host object file (shell host object file) and embedding the linked second part of code within the shell host object file.

In one embodiment, the method of merging the second part of code further comprises distinguishing coded objects embedded within the second part of code that share a common name. In one embodiment, the method of distinguishing coded objects further comprises generating a unique identifier for the coded objects that share the common name. The method further comprises generating the executable file in which the executable file comprises an executable form of the linked first portion of code and the linked second portion of code.

In one embodiment, the present invention is implemented in an executable file creation system. The system includes a first compiler for compiling a first portion of code received from a plurality of different source files, the first portion having instructions to be executed by a central processing unit (CPU). The system also includes a second compiler for compiling a second portion of code received from the plurality of different source files, the second portion of code having instructions to be executed solely by means of a graphics processing unit (GPU) , In one embodiment, the second part of code is written in a version of a compute unified device architecture programming language (CUDA). In one embodiment, the first compiler and the second compiler are further operable to independently compile the first part and the second part of code. In one embodiment, the second compiler is further operable to interpret an analog coded entity, wherein the first portion of code is operable to access data from the second portion of code using the analog coded entity.

The system includes a first link module for concatenating the first part of code which is compiled to produce a linked first part of code. The system includes a second link module for concatenating the second part of code which is compiled to produce a linked second part of code. In one embodiment, the second link module is further operable to generate a shell host object file, wherein the linked second portion of code is embedded within the shell host object file. In one embodiment, the second link module is further operable to distinguish encoded objects embedded within the second portion of code that share a common name. In one embodiment, the second link module is further operable to generate a unique identifier for the encoded objects sharing the common name. The system also includes an executable file generation module for generating the executable file, the executable file having an executable form of the linked first portion of code and the linked second portion of code.

In one embodiment, the present invention is implemented as a computer-implemented method for creating an executable file. The method comprises extracting a device code portion from a non-device code portion received from a plurality of different source files, the device code portion including instructions that are exclusively through graphics processing Unit (GPU). In one embodiment, the device code portion is written in a version of a compute unified device architecture programming language (CUDA).

In one embodiment, the method of extracting further comprises compiling the device code part separately from the non-device code part. In one embodiment, the method of compiling further comprises generating an analog encoded entity, wherein the non-device code portion is operable to access data from the device code portion using the analog encoded entity. The method includes linking the device code portion separately from the non-device code portion using a separate link process to produce a linked portion of device code. In one embodiment, the method of linking further comprises creating a shell host object file and embedding the linked part of device code within the shell host object file.

In one embodiment, the method of linking further comprises discriminating encoded objects embedded within the device code portion sharing a common name. In one embodiment, the method of distinguishing coded objects further comprises generating a unique identifier for the coded objects that share the common name. The method also includes generating the executable file, the executable file having an executable form of the linked portion of device code and the non-device code portion.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute a part of this specification, and in which like reference numerals designate like elements, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure.

1A FIG. 10 is a block diagram of an example link process in accordance with embodiments of the present invention. FIG.

1B FIG. 10 is a block diagram of an example compilation process in accordance with embodiments of the present invention. FIG.

1C provides an illustration of an exemplary memory allocation table or data structure used to map host code shadow entities to their corresponding device code entities, in accordance with embodiments of the present invention present invention.

1D FIG. 10 is a block diagram of an exemplary computer system platform used to perform link and compile operations in accordance with embodiments of the present invention. FIG.

2 FIG. 12 shows a flowchart of an example compilation process in accordance with various embodiments of the present invention. FIG.

3 FIG. 12 shows a flowchart of an exemplary shadow entity generation process in accordance with various embodiments of the present invention. FIG.

4 FIG. 10 is a block diagram of another example compilation process in accordance with embodiments of the present invention. FIG.

5 provides an illustration of an exemplary table or data structure used to track device code used in previous link operation, in accordance with embodiments of the present invention.

6 FIG. 12 shows a flowchart of an example compilation process for generating multiple embedded device links in accordance with various embodiments of the present invention.

DETAILED DESCRIPTION

Reference will be made in detail to the various embodiments of the present disclosure, examples of which are illustrated in the accompanying drawings. While described in connection with this embodiment, it will be understood that they are not intended to limit the disclosure to these embodiments. On the contrary, the disclosure is intended to cover alternatives, modifications, and equivalents, which may be included within the spirit and scope of the disclosure as defined by the appended claims. Further, in the following detailed description of the present disclosure, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. It will be understood, however, that the present disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the present disclosure.

Portions of the detailed description that follows are presented and discussed in terms of a process. Although operations and a sequence thereof are disclosed herein in a figure (e.g. 2 . 3 and 6 ), which describe exemplary operations of this process, such operations and sequence are exemplary. Embodiments are well suited to perform various other operations or variations of the operations recited in the flowchart of the figure herein and in a sequence different from that described and described herein.

As used in this application, the terms control, module, system and the like are intended to refer to a computer-related entity, in particular either hardware, firmware, a combination of hardware and software, software, or software in execution. For example, a module may be, but is not limited to, a process running on a processor, an integrated circuit, an object, an executable (file), an execution thread, a program, and / or a computer. For illustration purposes, both an application running on a computing device and the computing device may be a module. One or more modules may reside within a process and / or execution thread, and a component may be located on a computer and / or distributed between two or more computers. In addition, these modules can be executed by different computer readable media, which have stored various data structures in or on it.

Regarding 1A can compile host code (for example, compiled host code 112 ) may be a set of instructions written using a human-readable computer language medium (e.g., C, C ++, FORTRAN) and capable of being accessed by a micro-processor (e.g., CPU) be executed. In addition, compiled device code (eg, compiled device code 114 ) may be a set of instructions written using a human-readable computer language medium (e.g., Compute Unified Device Architecture (CUDA)) and capable of being accessed by a graphics processor unit (e.g. GPU). Both compiled host code and compiled device code may be convertible or re-locatable and may be embedded in a host object file. Also, host object files (such as host object 110 ) Container files that store redlocable machine code (eg, compiled host code 112 and compiled device code 114 from host object 110 ) generated using a compiler and capable of being input to a linker program (eg, host linker 150 and device linkers 130 ) to be used.

Device Linker 130 may be implemented as a set of instructions which receives device code as input from one or more object files and generates another host object file to contain linked device code. Host Linker 150 may be implemented as a set of instructions that receives object code as input from one or more object files and outputs a resulting executable image or shareable object file for additional linking to other host object files can be used. According to one embodiment, the host linker 150 to be able to output from the device linker 130 as input when performing link operations. According to one embodiment, device linkers 130 Link operations on device code before running host linker 150 carry out. According to one embodiment of the present invention, host linkers 150 Link operations on object files before running device linker 130 carry out.

As by means of in 1A illustrated embodiment, device linkers 130 and host linkers 150 used in combination to generate an executable file from multiple host objects, each comprising corresponding device code. For example, host object 110 compiled host code 112 and compiled device code 114 include, whereas host object 120 compiled host code 122 and compiled device code 124 may include. According to one embodiment, device linkers 130 Link operations on the same object files as host linker 150 perform (for example, host object 110 and host object 120 ). As such, device linker can 130 compiled device code 114 and compiled device code 124 left to linked device code 145 to create. In one embodiment, the linked device code 145 in host object 140 be embedded where host object 140 a "dummy" host object or "shell" can be.

Host Linker 150 can be an executable file 160 as a result of a link from host object 110 (eg including compiled host code 112 ), Host object 120 (eg including compiled host code 122 ) and host object 140 (eg including linked device code 145 ) produce. Executable file 160 can linked device code 145 and linked host code 165 include. In one embodiment, linked host code 165 by or in response to a link from host code 112 and compiled host code 122 be generated.

In one embodiment, host linkers 150 compiled device code (eg 114 . 124 , etc.) and / or linked device code (eg. 145 ) as a data section when link operations are performed. According to one embodiment, host linkers 150 compiled device code (eg 114 . 124 , etc.) and / or linked device code (eg. 145 ) while linking compiled host code (eg. 112 . 114 , etc.) or host objects (eg. 110 . 120 . 140 ignore, etc.). In one embodiment, compiled device code 114 and compiled device code 124 be redirectable device code or include redistributable device code. In addition, according to one embodiment, the linked device code 145 be executable device code or include executable device code.

Embodiments of the present invention may make use of multiple device code entry points ("kernels") from the host code portion of a program into the device code portion of a program. In certain scenarios, these entry points may share the same executable device code (eg, functions that are capable of being executed in parallel). As such, embodiments of the present invention may initialize host object files to invoke a common routine to access linked device code (eg, linked device code 145 ), which can then allow each entry point to reference this linked device code. In this way, the same set of executable device code may still be accessible to host code which requires accessing it.

Further, embodiments of the present invention may maintain visibility between host code and device code during a separate compilation such that device entities (eg, global functions, device and constant variables, textures, surfaces) which are located within the device code, may still be accessible to the host code. For each device entry present within the device code, analog or "shadow" entities within the host code may be generated to allow the host code to gain access to data from a corresponding device entity and collect data from a corresponding device entity. According to one embodiment, these shadow entities may be generated during a pre-compile phase.

With reference to in 1B embodiment shown z. Eg source files 107 and 108 each uncompiled host code (eg 112-1 respectively. 122-1 ) and uncompiled device code (eg 114-1 respectively. 124-1 ). Uncompiled device code 114-1 can device entities 114-2 and 114-3 which may be encoded as global functions or variables that are for entities outside of uncompiled device code 114-1 are accessible. Respective shadow entities can be generated in response to each of these device entities and sent to host compilers 118 to be passed.

According to one embodiment, shadow entities 112-2 and 112-3 within uncompiled host code 112-1 be generated to provide a logical link to device entities 114-2 and 114-3 (each) of uncompiled device code 114-1 uphold before going into host compiler 118 to be fed. Additionally, shadow entities can 112-2 and 112-3 the same link type as the device identity, which corresponds to each. If z. B. Device Entities 114-2 and 114-3 may be designated as a "static" type, may also have shadow entities 112-2 and 112-3 be given a "static" type. In a similar way, shadow entities can 122-2 and 122-3 from uncompiled host code 122-1 in correspondence with device entities 124-2 and 124-3 (each) of uncompiled device code 124-1 can be generated in a way that is discussed above before going into host compiler 118 be guided or fed. Furthermore, device code compiler 116 progress, uncompiled device code 114-1 and 124-1 to compile including the aforementioned device entities.

In addition to receiving uncompiled host code 112-1 and 122-1 can be host code compiler 118 Additionally, the resulting output is received by the device code compiler 116 is generated to host objects 110 and 120 to create. As such, compiled host code 112 Shadow entities 112-2 and 112-3 whereas compiled host code 122 Shadow entities 122-2 and 122-3 can receive. Accordingly, upon initialization and execution, compiled host code may be used 112 on data from device entities 114-2 and 114-3 access which in compiled device code 114 while compiled host code 122 on data from device entities 124-2 and 124-3 which can be accessed in compiled device code 124 be saved.

Further, with reference to FIGS 1C shown embodiment table 300 a table stored in memory which is used to map each generated shadow entity to an address in memory during a code execution. According to one embodiment, upon execution of the host object file, a registration code stored in the host object file is executed, which maps the address of the shadow entity to the name of the device entity.

Embodiments of the present invention may also resolve name conflicts involving device entities of separate files sharing the same name during the shadow entity mapping. For example, according to one embodiment, two different device entities sharing the same name from different modules, each with a "static" link type, with a unique prefix can be appended to each instance of the "static" link device entity name to thereby uniquely identify the device entity in a final linked device image (eg, linked device code 145 from 1A ) to make identifiable.

Computer system environment

1D shows a computer system 100 in accordance with an embodiment of the present invention. Computer System 100 Figure 12 shows the components of a basic computer system in accordance with embodiments of the present invention, providing the execution platform for certain hardware-based and software-based functionality. In general, computer system points 100 at least one CPU 101 , a system memory 115 and at least one graphics processor unit (GPU) 110 on.

The CPU 101 can to the system memory 115 may be coupled via a bridge component / memory controller (not shown) or may be directly connected to the system memory 115 via a memory controller (not shown) which is integral to the CPU 101 is, be coupled. The GPU 110 can be sent to an ad 112 be coupled. One or more additional GPUs may be optional to system 100 coupled to continue to increase its computing power. The GPU (s) 110 is to the CPU 101 and the system memory 115 coupled. The GPU 110 can be used as a discrete component, a discrete graphics card, which is designed to the computer system 100 via a connector (eg AGP slot, PCI Express slot, etc.) to couple a discrete integrated circuit die (eg, mounted directly on a mother board), or as an integrated GPU which is included within the integrated circuit die of a computer system chip set component (not shown). In addition, a logical graphics memory 114 for the GPU 110 includes for high-bandwidth graphics data storage.

The CPU 101 and the GPU 110 can also be integrated into a single integrated circuit die, and the CPU and GPU can share or share various resources, such as instruction logic, buffers, functional units, etc., or separate resources for graphics and video Be provided general purpose operations. The GPU may also be integrated into a core logic component.

system 100 can z. B. be implemented as a desktop computer system or a server-computer system, which is a powerful general-purpose CPU 101 which has a dedicated graphics rendering GPU 110 is coupled. In such an embodiment, components may be included that add peripheral buses, specialized audio / video components, IO devices, and the like. It is estimated that the parallel architecture of GPU 110 significant performance advantages over CPU 101 may have.

2 FIG. 10 presents a flowchart providing an exemplary computer-implemented compilation process in accordance with various embodiments of the present invention.

At step 206 For example, two or more host object files, each containing device code objects capable of being read and executed by a GPU, are fed into a device code linker program.

At step 207 The device code linker program operates on the device code objects contained within each host object file which is inserted into the device linker program at step 206 are fed to produce linked device code. When operating on the host object file, the device code linker ignores objects that do not contain device code.

At step 208 becomes the resulting linked device code, which during the step 207 is embedded back into a host object file created by the device code linker program which serves as a "dummy" host object or "shell". The host object file may be in a state for use as input to the host linker program.

At step 209 The host linker program operates on the host object files which are in the device linker program at step 206 were fed or fed, as well as on the host object file, which during the step 208 is generated. The host linker program generates a file containing an executable form of linked device code capable of being executed by the GPU of a computer system, as well as an executable form of linked host code, which in is able to be executed by means of the CPU of a computer system.

3 FIG. 10 presents a flowchart providing an exemplary computer-implemented shadow entity generation process in accordance with various embodiments of the present invention.

At step 306 Device entities that are accessible in host code are read from a source file that includes both the device code that includes the device entities and host code during a pre-compile phase.

At step 307 is for each device entity, which at step 306 is determined, a corresponding analog or "shadow" entity is generated and passed to the host code compiler. These corresponding shadow entities may hold a logical link to their corresponding device entities (upright) and may be given the same link type as the device entity, which corresponds to each one.

At step 308 The device code compiler receives and compiles the device code of the source file, which is input as step 306 is used. The resulting output is then fed to the host code compiler.

At step 309 the host code compiler operates on the host code of the source file, which is input as step 306 including the shadow entities leading to the host compiler at step 307 happened, as well as the resulting output generated by the device compiler at step 308 is generated.

At step 310 The host code compiler generates a host object file, which is a compiled form of both the device code, including the device entities, which are at step 306 are determined, as well as the host code, including each corresponding shadow entity device entity, which at step 307 is generated encapsulates.

Exemplary method of embedding multiple device links into a host-executable construct

Embodiments of the present invention may support natural independent groupings of device code in a manner that allows these groups ("file sets") to be linked separately. For example, in a large project set up, there may be a set of files that include device code for handling a first task (eg, image handling) while another set of files may handle a second task that is independent from the first task is (eg parallel calculation). Device code from different groups does not need to interact directly, and therefore does not need to interfere with each other during a compilation or link process. As such, embodiments of the present invention allow the first group of files to be linked together to form an executable form of linked device code, while the second group of files are separately linked together into another executable form of linked device code can. These executable forms can then be placed and packaged within the same executable file, where a CPU and GPU can access their respective files and perform their respective tasks.

As in the embodiment which is in 4 is illustrated, a device linker (eg device linker 130-1 and 130-2 ) and a host linker (eg host linker 150 ) are used in combination to create an executable, including multiple pieces of linked device code or "device links". Multiple device links can increase analytical precision during the performance of link operations, which can result in optimal code generation. Further, embedding multiple device links in the manner described by embodiments of the present invention facilitates linking vendor libraries by allowing a device link to be independent of any user knowledge of other device links, which were created by an external seller, occurs or takes place.

Regarding 4 can file set 600 Include code that is logically related to each other and which is functionally distinct from the file set 700 , For example, host objects 110 and 120 from file set 600 Include code for use in image handling processes, whereas host objects 130 and 150 from file set 700 May include instructions for use in parallel calculations. As such, need file set 600 and file set 700 not interacting directly with each other and therefore do not need to touch or influence each other during compilation or linking.

Device Linker 130-1 can compile device code 114 and compiled device code 124 left to linked device code 145 (eg as discussed above). Additionally, device linker 130-2 compiled device code 134 and compiled device code 154 left to linked device code 245 (similar to the generation of linked device code, for example) 145 as discussed above). According to one embodiment, device linkers 130-1 and device linkers 130-2 be the same linker, which is called at separate times. Any part of linked device code (eg. 145 and 245 ) may be embedded in or part of a corresponding host object (eg. 140 respectively. 240 ), which by means of device linker 130-1 respectively. 130-2 is generated.

Host Linker 150 can then executable file 160 as a result of a link from host object 110 (eg including compiled host code 112 ), Host object 120 (eg including compiled host code 122 ), Host object 130 (eg including compiled host code 132 ), Host object 150 (eg including compiled host code 152 ), Host object 140 (eg including linked device code 145 ) and host object 240 (eg including linked device code 245 ) produce. Executable file 160 can be at least part of linked device code (eg. 145 . 245 , etc.) and linked host code (eg. 160 ). In one embodiment, linked host code 165 generated by or in response to a link of host codes 112 . 122 . 132 and 152 , Accordingly, an executable file (e.g. 160 ), which linked host code (e.g. 165 ) and several pieces of linked device code (eg 145 . 245 , etc.).

Further For example, embodiments of the present invention can uniquely identify each device code object that is linked by the use of unique identifiers. By using unique identifiers, embodiments of the present invention may provide better security that a device code object will not be linked into two different linked device codes within the same executable file. In this manner, embodiments of the present invention may provide a backup precaution which ensures that device code embedded within host objects can be uniquely identified and linked in accordance with the protocols of conventional programming languages (eg C ++).

5 presents an exemplary representation of how device code objects can be uniquely identified in accordance with embodiments of the present invention. Device Linker table 400 may be a table stored in memory which uniquely identifies each device code, which by means of device linker 130 during the performance of link operations, along or along with the host objects with which those entities are associated ("host object predecessors"). Device Linker 130 can generate a unique identifier for each device object (eg, "module_id" column), participating in the device link process.

According to one embodiment, device linkers may 130 on device linker table 400 to determine which device objects have already participated in the link process. Those device objects which have been identified as previous participants can participate in host link operations by host linkers 150 be excluded. As such, attempts to create an executable file that includes previous past participles may be discouraged from succeeding. For example, with reference to device linker table 400 , given that host object 110 (which compiled device code 114 includes) and host object 120 (which compiled device code 124 includes) linked together to a linked device code 145 can generate both host objects 110 and 120 be prevented from participating in a subsequent device link operation. If host object 110 and another host object file containing its own compiled device code (not shown) as input, via device linker 130 Can be linked, run, device linker 130 on device linker table 400 refer and determine that host object 110 already a participant in a previous link operation (eg linked device code 145 ) was. Accordingly, device linker 130 the host object 110 ignore and only link those objects that contain code that was not previously linked.

6 FIG. 10 presents a flowchart providing an exemplary computer-implemented device code compilation process in accordance with various embodiments of the present invention.

At step 406 For example, each host object file associated with a file set is fed into a device code linker program among a plurality of host object file sets used as input.

At step 407 the device code linker program looks for a unique identification code (eg, modul_ID) assigned to each host object file which is at step 406 to determine if the host object files have participated in a previous device code link process.

At step 408 a determination is made as to whether the host object files received by the device code linker have participated in a previous device code link process. If the host object files did not participate in a previous device code link operation, then the device code linker program operates on the device code embedded within the host object files stored in the device linker program at step 406 are fed, as in step 410 was detailed. If any of the host object files have participated in a previous device code link operation, then that host object file is excluded from participating in the current device link operation, as in step 409 is detailed.

At step 409 is a host object file, which is at step 406 has been determined to have participated in a previous device code link operation, and is therefore excluded from participation in the current device link operation.

At step 410 For example, the host object files have been determined not to have participated in a previous device code link operation, and therefore the device code linker program operates on the device code, which is within the host object files which are fed into the device code linker program and generates linked device code. The device code linker program embeds the resulting linked device code within a host object file generated by the device code linker program.

At step 411 will each host object file, which is during step 410 is assigned a unique identification code (eg, module_id) which provides information regarding the current link operation tracked by the device code linker program using a table stored in memory.

At step 412 For example, the host linker program generates an executable form of the host code embedded within the same host object files which are sent to the device code linker program at step 406 and the linked device code which is embedded within the host object file, which at step 410 is generated.

At step 413 The host linker program generates an executable file which encapsulates each of the executables that are executed at step 412 are generated.

While the foregoing disclosure embodies various embodiments using specific block diagrams, flowcharts, and examples, each block diagram component, flowchart step, operation, and / or component described and / or illustrated herein may be implemented individually and / or collectively, using a wide range of hardware, software or firmware (or any combination thereof) configurations. In addition, any disclosure of components included within other components should be considered as examples, since many other architectures can be implemented to achieve the same functionality.

The process parameters and sequence of steps described and / or illustrated herein are given by way of example only. While the steps illustrated and / or described herein may be shown or discussed in a particular order, these steps need not necessarily be performed in the illustrated or discussed order. The various example methods described and / or illustrated herein may also omit one or more of the steps described or illustrated herein, or include additional steps in addition to those disclosed.

While various embodiments have been described and / or illustrated herein in the context of fully functional computer systems, one or more of these example embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer-readable media, which are used to actually execute the distribution. The embodiments disclosed herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. These software modules may configure a computer system to perform one or more of the example embodiments disclosed herein. One or more of the software modules disclosed herein may be implemented in a cloud computing environment. Cloud computing environments can provide various services and applications over the Internet. These cloud-based services (eg, software as a service, platform as a service, infrastructure as a service) may be accessible through a web browser or other remote interface. Various functions described herein may be provided by a remote desktop environment or any other cloud-based computing environment.

For the purpose of explanation, the foregoing description has been described with reference to specific embodiments. The above illustrative discussions, however, are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations are possible in light of the above disclosure. The embodiments have been chosen and described to best explain the principles of the invention and to explain its practical applications, thereby enabling those skilled in the art to embody the invention and various embodiments with various modifications as may be intended are considered suitable for use.

Embodiments according to the invention are thus described. While the present disclosure has been described in particular embodiments, it should be appreciated that the invention should not be construed to be limited by such embodiments, but instead should be construed according to the claims below.

Claims (20)

A method of generating an executable file, the method comprising: compiling a first portion of program code and a second portion of program code accessed from a plurality of different source files, the first portion having instructions using a central processing unit (CPU), and wherein the second part of code having instructions to be executed exclusively by means of a graphics processing unit (GPU); Co-linking the first part of code, compiled to produce a linked first part of code; Co-linking the second part of code, compiled to produce a linked second part of code; and generating the executable file, the executable file having an executable form of the linked first portion of code and the linked second portion of code. The method of claim 1, wherein the compiling further comprises separately compiling the first part and the second part of code. The method of claim 2, wherein compiling further comprises generating an analog coded entity, wherein the first portion of code is operable to access data from the second portion of code using the analog coded entity. The method of claim 1, wherein the second part of code is written in a version of compute-unified-device-architecture-programming-langvage (CUDA). The method of claim 1, wherein concatenating the second portion of code further comprises creating a shell host object file and embedding the linked second portion of code within the shell host object file. The method of claim 1, wherein the merging of the second part of code further comprises distinguishing coded objects embedded within the second part of code which share a common name. The method of claim 6, wherein distinguishing coded objects further comprises generating a unique identifier for the coded objects sharing a common name. A system for building an executable file, the system comprising: a first compiler for compiling a first portion of code received from a plurality of different source files, the first portion having instructions provided by a central processing unit (CPU) are to be executed; a second compiler for compiling a second portion of code received from the plurality of different source files, the second portion of code having instructions to be executed solely by means of a graphics processing unit (GPU); a first link module for linking together the first part of code, compiled to produce a linked first part of code; a second link module for linking the second part of code together to compose a linked second part of code; and an executable file creation module for generating the executable file, the executable file having an executable form of the linked first portion of code and the linked second portion of code. The system of claim 8, wherein the first compiler and the second compiler are further operable to independently compile the first part and the second part of code. The system of claim 9, wherein the second compiler is further operable to interpret an analog coded entity, wherein the first portion of code is operable to access data from the second portion of code using the analog coded entity. The system of claim 8, wherein the second part of code is written in a version of a compute unified device architecture programming language (CUDA). The system of claim 8, wherein the second link module is further operable to generate a shell host object file, wherein the linked second portion of code is embedded within the shell host object file. The system of claim 8, wherein the second link module is further operable to distinguish encoded objects embedded within the second portion of code sharing a common name. The system of claim 8, wherein the second link module is further operable to generate a unique identifier for the encoded objects that share the common name. A computer-implemented method of generating an executable file, the method comprising: extracting a device code portion from a non-device code portion received from a plurality of different source files, the device code portion comprising: Part instructions to be executed only by means of a graphics processing unit (GPU); Linking the device code part separately from the non-device code part using a separate link process to generate a linked part of device code; and generating the executable file, the executable file having an executable form of the linked portion of the device code and the non-device code portion. The method of claim 15, wherein extracting further comprises compiling the device code portion separately from the non-device code portion. The method of claim 16, wherein compiling further comprises generating an analog coded entity, wherein the non-device code portion is operable to access data from the device code portion using the analog coded entity. The method of claim 15, wherein the device code portion is written in a version of a Compute Unified Device Architecture Programming Language (CUDA). The method of claim 15, wherein the linking further comprises generating a shell host object file and embedding the linked portion of device code within the shell host object file. The method of claim 15, wherein the linking further comprises distinguishing coded objects embedded within the device code portion sharing a common name.

Images