Patent Document

CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application claims priority to European Patent Application No. 02002801.5, filed Feb. 7, 2002, entitled PROVIDING TARGET PROGRAM BY PARALLEL COMPILING WITH SERIAL SCHEDULE, the disclosure which is incorporated herein by reference in its entirety. 
     BACKGROUND 
     The present invention relates to data processing by digital computer, and more particularly to parallel compiling with a serial schedule. 
     Software source code can be written in programming languages such as C, C++, Pascal, or Java®. In one common deployment scenario, a compiler converts software source code into object code, and a linker converts the object code into executable code. At run-time, a processor executes the executable code. 
     Modular techniques are common in software development, and software building is a process of compiling source code modules to object code modules and linking the object code modules to the target program. This modular process automatically follows a predefined schedule. However, for business application software, the total processing time is measured in hours. 
     There is an ongoing need to improve software development techniques with reduced processing times. 
     SUMMARY 
     The present invention provides methods and apparatus, including computer program products, for parallel compiling with a serial schedule. 
     In general, in one aspect, the invention features a method of generating an executable program including receiving serial compile commands in a pseudo-compiler to compile source code modules, scheduling the serial compiler commands in parallel compilers to compile the source code modules, compiling the source code modules in the parallel compliers to generate object code modules, sending compiler completion acknowledgements to a synchronizer, and linking the object code modules in linkers in response to linker initiation commands from the synchronizer. 
     The invention can be implemented to include one or more of the following advantageous features. The pseudo-compiler can store the serial compiler commands in a buffer. The serial compiler commands can be scheduled according a size of the source code modules, an expected compiler duration in each parallel compiler, a next available compiler, a first-in-first-out (FIFO) scheme, a last-in-first-out (LIFO) scheme, a head or stack configuration. 
     The compiler completion acknowledgements can indicate error-free compilations. Receiving serial compile commands can include storing a count of a serial compiler commands to determine a number of parallel compilers. 
     The details of one or more implementations of the invention are set forth in the accompanying drawings and the description below. Further features, aspects, and advantages of the invention will become apparent from the description, the drawings, and the claims. 
    
    
     
       DESCRIPTION OF DRAWINGS 
         FIG. 1  is a block diagram of a system including an implementation of the invention. 
         FIG. 2  is a block diagram of code modules and service components. 
         FIG. 3  is a block diagram of a first example using the code modules and service components. 
         FIG. 4  is a block diagram of a compiler trigger queue in a first-in-first-out (FIFO) configuration for a second embodiment. 
         FIG. 5  is a block diagram of a trigger buffer. 
         FIG. 6  is a block diagram of a pseudo-compiler and a synchronizer. 
         FIG. 7  is a flow chart of a process. 
     
    
    
     DETAILED DESCRIPTION 
     Shown  FIG. 1 , an exemplary system  999  includes computers  900 ,  901 ,  902 . Computers  900 ,  901 ,  902  are coupled by inter-computer network  990 . Computer  900  includes processor  910 , memory  920 , bus  930 , input device  940  and output device  950 . Input device  940  and output device  950  make up a user interface  960 . In operation, memory  920  includes a process  100 , compilers  102 , linkers  104  and pseudo-compiler  106 . Computers  901 ,  902  are sometimes referred to as remote computers. Example remote computers are servers and routers. 
     In one example, computer  900  is a personal (PC) computer. In other examples, computer  900  is a hand-held device, a multiprocessor computer, a pen computer, a microprocessor-based or programmable consumer electronics, a minicomputer, a mainframe computer, a personal mobile computing device, a mobile phone, a portable or stationary personal computer, or a palmtop computer. 
     In  FIG. 2 , an overview of code modules  120  and service components  130  is shown. Code modules  120  are classified into source code modules  211  (X.C++),  212  (Y.C++),  213  (Z.C++), object code modules  221  (X.OBJ),  222  (Y.OBJ),  223  (Z.OBJ), and target program  230 . Exemplary filenames are given in parenthesis with a module identifier (e.g., X) and a code identifier (e.g., C++). For convenience, the word “code” is sometimes omitted. 
     According to their main actions (i.e., two-digit numbers), the service components  130  are classified into the scheduler  110  (S, “maker”) for triggering 01, 06, 11, 16 (i.e. requesting), the compiler (C)  140  for reading 02, 07, 12, compiling 03, 08, 13, writing 04, 09, 14, acknowledging 05, 10, 15, and the linker (L)  150  for reading 17, 18, 19, linking 20, writing 21, acknowledging 22. 
     Double-line arrows represent actions that involve code, such as reading and writing, compiling and linking. Single-line arrows represent actions that control operations, such as triggering and acknowledging. 
     Scheduler  110  triggers compiler  140  and linker  150  according to a predefined schedule with the module identifiers (i.e. X, Y, Z). One triggering action is referred to as “trigger command” (“request”). Compiler  140  and linker  150  acknowledge completion to scheduler  110  (i.e. indicate that compiling or linking has been completed). 
     Compiler  140  reads source code from source modules  211 ,  212 ,  213  (e.g., X.C++), compiles source code to object code, and writes object code to the object modules  221 ,  222 ,  223  (e.g., X.OBJ). 
     Linker  150  reads object modules  221 ,  222 ,  223  (i.e., X.OBJ, Y.OBJ and Z.OBJ) and links them to target program  230 . 
     In one example, processor  910  executes the compiler  140  sequentially as follows.
         01 S triggers C to compile X   02 C reads source from X.C++   03 C compiles   04 C writes object to X.OBJ   05 C acknowledges   06 S triggers C to compile Y   07 C reads source from Y.C++   08 C compiles   09 C writes object to Y.OBJ   10 C acknowledges   11 S triggers C to compile Z   12 C reads source from Z.C++   13 C compiles   14 C writes object to Z.OBJ   15 C acknowledges   16 S triggers L to link X, Y and Z   17 L reads X.OBJ   18 L reads Y.OBJ   19 L reads Z.OBJ   20 L links X.OBJ, Y.OBJ and Z.OBJ   21 L writes to TARGET.exe   22 L acknowledges.       

     Scheduler  110  includes instructions in a schedule file (“make file”), for example, for action 1 (trigger C to compile X), action 5 (wait for acknowledgement), and action 6 (trigger C to compile Y). 
     Attempts to speed up the above actions can face problems. For example, linker  150  evaluates object code for some or all modules (i.e. X, Y and Z) simultaneously. Therefore, changing the schedule (e.g., compile X, compile Y, link X and Y, compile Z, link XY with Z) can be applied to modules with no interaction. Also, compiling sometimes fails (e.g., due to syntax errors in source code). 
     Disregarding compiler errors, process  100  uses a pseudo-compiler that triggers parallel compilers. In another example process  100  uses buffers for temporarily storing trigger commands. In still another example, process  100  adds error detection functionality. In another example, process  100  accommodates a variable, but initially unknown number of modules. 
     In  FIG. 3 , code modules  120  and service components  130  are shown in greater detail. Compiler  140  is replaced with pseudo-compiler  160 . Pseudo-compiler  160  triggers compiler  321 ,  322 ,  323  to operate in a substantially parallel manner. A synchronizer  335  is also included. Pseudo-compiler  160  appears to scheduler  110  like compiler  320 . Thus, it is not required to change the schedule or to change triggering or acknowledging. 
     In operation, scheduler  110  triggers 01 pseudo-compiler  160  to compile X. Pseudo-compiler  160  triggers 02 compiler  321 . Substantially simultaneously, (i) pseudo-compiler  160  acknowledges 03 to scheduler  110  and (ii) compiler  321  staffs to read 04 source module  211 , compile 05, and write 06 object module  221 . For scheduler  110 , it appears that compiling has been completed so that scheduler  110  triggers 07 pseudo-compiler  160  to compile Y. Similar, pseudo-compiler  160  triggers 08 compiler  322 . Substantially simultaneously, (i) pseudo-compiler  160  acknowledges 09 to scheduler  110  and (ii) compiler  322  starts to read 10 source module  212 , compile 11, and write 12 object module  222 . 
     Again, for scheduler  110 , it appears that compiling has been completed so that scheduler  110  triggers 13 pseudo-compiler  160  to compile Z. Similar, pseudo-compiler  160  triggers 14 compiler  323 . Substantially simultaneously, (i) pseudo-compiler  160  acknowledges 15 to scheduler  110  and (ii) compiler  323  starts to read 16 source module  213 , compile 17, and write 18 object module  223 . Pseudo-compiler  160  uses serial scheduling to operate parallel compilers. Compilers  321 ,  322 ,  323  independently compile 05, 11, 17 and acknowledge 19, 20, 21 to synchronizer  335 . 
     Synchronizer  335  enhances the interaction of the scheduler  110  and linker  150 . Synchronizer  335  enables scheduler  110  to trigger linker  150  or disables it. Synchronizer  335  either forwards trigger commands or blocks them. When compilers  321 ,  322 ,  323  have acknowledged 19, 20, 21 (events related by logical AND), scheduler  110  triggers 22/23 linker  150 . Linker  150  reads 24, 25, 26 object modules  221 ,  222 ,  223 , links 27 them and writes 28 target program  230 . 
     In another example, linker  150  and synchronizer  335  act like a pseudo-linker that appears to scheduler  110  as a linker. 
     Pseudo-compiler  160  and synchronizer  335  operate like a dispatcher that organizes parallel code processing (compiling/linking) from a serial schedule. 
     Usually, compilers  321 ,  322 ,  323  need different time intervals to complete compiling 05, 11, 17. These differences are caused, for example, by different sizes of modules  211 ,  212 ,  213  or by different compiler environments. In order to reduce idle times, process  100  uses buffers. 
     As shown in  FIG. 4  and  FIG. 5 , the pseudo-compiler  160  includes buffers  326 ,  327 . Trigger commands (from scheduler  110 ) are symbolized by letter symbols A, B, . . . T, U, V, W, X, Y, Z that identify source modules to be compiled. Buffer  326  can forward the commands (arrow symbols) as predefined, for example, according to the size of the source modules to be compiled, according to an expected compiling duration for each compiler, or to the next available compiler. Buffer  326  can forward the commands according to a first-in-first-out (FIFO) scheme, according to a last-in-first-out (LIFO) scheme, or in a head or stack configuration. 
     As shown in  FIG. 4 , buffer  326  stores trigger commands (01, 07, 13) at random and further triggers compilers (C)  321 ,  322  or  323  (shown as 32x). Pseudo-compiler  160  is symbolized by a dashed frame. 
     In  FIG. 5 , a compiler trigger buffer in a first-in-first-out (FIFO) configuration is shown. Trigger A arrives first. Waiting triggers are temporarily stored in a queue. The figure has the form of a table, in which the columns indicate consecutive time points, FIFO with triggers arriving on the left, indication of modules currently compiled by compiler  321 , and indication of modules currently compiled by compiler  322 . 
     At time point  1 , triggers for modules A and B are forwarded through the FIFO so that compilers  322  and  321  compile modules A and B, respectively. Trigger C is in the FIFO. At time point  2 , trigger D has arrives and compilers  321  and  322  are still busy. At time point  3 , compiler  321  is compiling module B, compiler  322  is compiling C, D is in the FIFO. At time point  4 , compiler  321  is compiling module B, compiler  322  is compiling D, triggers H, G, F, E are waiting in the FIFO. At the next time points, further triggers arrive, compilers  321  and  322  operate on further modules. At time point  20 , compiler  321  and  322  compile modules U and X, respectively. The last triggers Y and Z are in the FIFO. 
     In another example, error handling functionality is applied to pseudo-compilers, compilers, synchronizer and linker. Acknowledging can be delayed until compiling is completed without errors. Compiling modules that have errors can be shifted to a time when human interaction is available (e.g., in an overnight schedule to the next morning). 
     As shown in  FIG. 6 , pseudo-compiler  160  counts the total number N of triggering commands (incoming arrow) and communicates N to synchronizer  335  (outgoing arrow). This is convenient for a case with a variable number of modules. Counting makes compiling and linking more flexible. 
     As shown in  FIG. 7 , process  100  for controlling a building process of target program  230  (with compiling source code modules  211 ,  212 ,  213  into object code modules  221 ,  222 ,  223  and linking object code modules  221 ,  222 ,  223  to target program  230 ) includes triggering ( 410 ) pseudo-compiler, acknowledging ( 420 ) to scheduler, triggering ( 430 ) compilers, acknowledging ( 440 ) to synchronizer; and triggering ( 450 ) linker. Triggering ( 410 ) and acknowledging ( 420 ) are repeated for a number of modules/compilers (indicated by query  401 ,  402 ). 
     In triggering ( 410 ), scheduler  110  triggers 01, 07, 13 each module of pseudo-compiler  160 . In acknowledging ( 420 ), pseudo-compiler  160  acknowledges 03, 09, 15 receipt to scheduler  110 . In triggering ( 430 ), pseudo-compiler  160  triggers 02, 08, 14 a number of compilers  321 ,  322 ,  323  to compile 05, 11, 17 source code modules  211 ,  212 ,  213  to object code modules  221 ,  222 ,  223  substantially in parallel. In acknowledging ( 440 ), compilers  321 ,  322 ,  323  acknowledge 19, 20, 21 to synchronizer  335 . In triggering ( 450 ), scheduler  110  triggers 22/23 linker  150  when the synchronizer  335  has received acknowledgements 19, 20, 21 from compilers  321 ,  322 ,  321 . It is preferred that the total number N of triggering commands 01, 07, 13 is counted and communicated to synchronizer  335 , and pseudo-compiler  160  buffers trigger commands. 
     The invention can be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations of them. The invention can be implemented as a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable storage device or in a propagated signal, for execution by, or to control the operation of, data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. A computer program can be written in any form of programming language, including compiled or interpreted languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A computer program can be deployed to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network. 
     Method steps of the invention can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by, and apparatus of the invention can be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). 
     Processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor will receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in special purpose logic circuitry. 
     A number of embodiments of the invention have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Accordingly, other embodiments are within the scope of the following claims.

Technology Category: 3