text:
|Número da publicaçăo
|Tipo de publicaçăo
|Número do pedido
|Data de publicaçăo
|7 dez. 1999
|Data de depósito
|3 nov. 1997
|Data da prioridade
|1 mar. 1994
|Status da taxa
|Também publicado como
|Número da publicaçăo
|Amitabh Srivastava
|Cessionário original
|Digital Equipment Corporation
|Exportar citaçăo
|BiBTeX, EndNote, RefMan
|Citaçőes de patente (8), Citaçőes de năo patente (5), Citada por (91), Classificaçőes (12), Eventos legais (5)
|Links externos: USPTO, Cessăo do USPTO, Espacenet
This application is a continuation of application Ser. No. 08/752,728, filed on Nov. 19, 1996, which was abandoned upon the filing hereof, which is a continuation of application Ser. No. 08/204,833, filed Mar. 1, 1994, now abandoned.
This invention relates generally to converting a computer programs written in a high level language into machine executable code, and more particularly to converting the program to produce optimized machine executable code.
Processes to be performed by computer systems are typically defined in high level source language programs. Compilers, linkers, and assemblers may be used to convert the source language programs to machine executable code. The utilization of computer resources can be minimized if the machine code is optimized for execution.
Optimizing the machine executable code has conventionally been the domain of the compiler. This is sensible; it is the compiler that generates machine compatible object code. Furthermore, the compiler begins with the original source program written in the high level language by the programmer. Therefore, the intent of the programmer is exposed to the compiler. The source code typically includes directions about the type of variables declared and the use of high level operations. The source code may also include pragma added by the programmer to streamline the conversion from source to executable code. Nonetheless, most conventional compilers include limitations which produce non-optimal machine code. Non-optimal code degrades performance of the program during execution and wastes valuable computer system resources such as instruction cycles and storage space in memory.
In most environments, a large program is written as many smaller source code modules using an editor. Smaller source modules are easier to understand and manage. The source modules are then compiled into object modules, typically, one source module at the time. This separate compilation would be difficult to eliminate, since it greatly reduces the turn-around time in the multiple edit-compile-build-run-debug cycles that are so characteristic of computer program development.
However, since the compiler only operates on one module at the time, optimization is limited to the module being compiled. Thus, the compiler cannot view the behavior of the entire program to eliminate, perhaps, duplicate procedures in different source modules. Also, the linker may acquire object or assembly code from standard libraries. Clearly, traditional compile-time optimization can not optimize the pre-compiled library modules.
In addition, the compiler can not determine the actual use, or for that matter non-use, of variables declared in one module, for use in another module. It is also difficult for the compiler to determine if memory and registers will be fully utilized during execution.
Moreover, most compilers convert source code modules in distinct phases. For example, retargetable compilers, for generating machine executable code for different computer hardware architectures, may have machine-independent phases insulated from machine-dependent phases. The optimization methods may therefore not have a complete view of the resources that will be available during execution.
In many computer environments, the compiler produces assembly code rather than true object code. The advent of reduced instruction set computing (RISC) architectures has led to environments in which the assembly code is no longer isomorphic with the object code, and optimization below the level of assembly code is not possible by the compiler.
There are some systems which attempt post-compiler or "late" code modifications. The known modifications typically are limited to patching linked code for instrumentation. Patching is the insertion of specific instructions at known locations. "Instrumentation" refers to the patching of the program for the purpose of measuring and tracing the flow of the program while executing. During instrumentations, the memory addresses of relocated instructions are carefully tracked, and references to any relocated memory locations are accordingly adjusted. However, the problems associated with late code modification have generally inhibited aggressive optimization of linked code.
There may be additional advantages in optimizing linked code. It is not until the object modules are linked together that the gross morphology of the entire program becomes visible. Although some of the high-level structure is missing from the linked object modules, link-time optimization may have other properties not available to compile-time optimization.
At link-time the entire program, including library modules is available. Thus, the entire program can be scrutinized for optimization opportunities, rather than isolated opportunities just within single and separately compiled source code modules. Also, at link time, the output of the compiler, e.g., the object code, can be examined. This may not have been done by the compiler. These link-time properties can lead to several advantages which are exploited by the invention to optimize the executable code to a level not previously achievable by compilers.
A computer system is directed to convert a program written as a plurality of source code modules into corresponding machine executable code for executing in a target computer system. Each of the source code modules, written in a high level source language, is compiled into an object code module. The object code modules are translated into a single linked code module in the form of a register translation language and logical symbol table. The register transfer language is independent of any particular computer system hardware architectures. The original high level program structures are recovered from the linked code module and the linked code module is partitioned into a plurality of procedure, and instructions of each of the procedures are grouped into basic blocks. Basic blocks are classified as normal blocks if they only manipulate data, and basic blocks are classified as control blocks if they change the flow of execution control.
In accordance with another aspect of the invention, a procedure flow graph is constructed for each of the procedures, and a program call graph is constructed for the linked code module. The procedure flow graphs to indicate the execution flow within the procedures, and the program call graph to indicate the execution flow among the procedures. The linked code module is converted into machine executable code compatible with a target computer system hardware architectures.
In the invention, the linked code module is optimized before the machine code is generated. A liveliness analysis is performed for each of the basic blocks of each of the procedures. The liveliness analysis determines a first set of variables which are live at the beginning of execution of each of the basic blocks, and a second set of variables which are live at the end of execution of each of the basic blocks. The first and second set of variables are used to locate dead-code which can be removed from the linked code module. In addition, intra-procedural and inter-procedural loop invariant code are moved across procedures boundaries to minimize the execution time of loops.
FIG. 1 is a block diagram of a computer system which can use the link-time optimizer of the present invention;
FIG. 2 is a top level flow diagram of a procedure to produce optimized machine executable code for the computer system of FIG. 1;
FIG. 3 is a flow diagram of a link-time optimizer according to a preferred embodiment of the invention;
FIG. 4 shows procedure flow graphs and a program call graph superimposed on a program to be optimized by the link-time optimizer of FIG. 3;
FIG. 5 is a flow diagram of a liveliness analysis procedure of the link-time optimizer;
FIG. 6 is block diagram of procedures including dead code to be optimized;
FIG. 7 is block diagram of procedures including invariant code to be optimized;
FIG. 8 shows a call graph for a program to be optimized; and
FIG. 9 is a flow diagram of a procedure to find a loop region of the program of FIG. 8.
FIG. 1 shows a computer system 1 including a CPU 2, a memory 3, and an I/O 4 coupled to each other by a bus 5. The computer system 1 can be a personnel computer, a work-station, a main-frame, or part of a network of computers executing process steps independently, or in parallel.
With respect to the component structures of the computer system 1, the CPU 2 may be of a variety of architectures, CICS, RISC and the like. The memory 3 can include a cache 7 to accelerate the data flow between the CPU 2 and the memory 3. The structure of the bus 5 is general, and can include dedicated high-frequency data paths, signaling in parallel, for example between the cache 7 and the CPU 2. The I/O 4 can include input and output interfaces for acquiring and distributing data.
During operation of the computer system 1, data and processing steps, in the form of machine executable machine code, are acquired by the CPU, usually from the memory 3 via the bus 5. The data and the executable code are usually permanently retained by the I/O 4, and loaded into the memory 3 as needed. While processed by the CPU 2, the data can be stored in a set of registers 8.
FIG. 2 show the general process of generating optimized machine executable code. Programmers, typically, via the I/O 4, create a program 20 written in a high-level machine-independent language using an editor 10. If the program 20 is very large, the program 20 is created as a library or collection of smaller programs, usually called source code modules 21-23. Editing smaller programs is more efficient than working on one large and very complex program.
The source code modules 21-23 are processed by a compiler 20 to create a collection of object modules 41-43. Usually, there is a one-to-one correspondence between the source modules and the object modules. Each of the object module 41-43 can be associated with corresponding relocation and symbol tables (RST) 44-46. The RSTs 44-46 typically are used to resolve memory address assignments during linking.
A linker 50 embodying the invention can combine the object modules 41-43, and resolve logical to physical address translations at link-time with the associated RST 44-46. The linker 50 may also acquire pre-compiled code modules from a library 49. The library 49 includes, for example, frequently used or standard program segments or procedures. The linker 50 produces machine dependent executable code 60 which can be loaded in the memory 3 for subsequent execution by the CPU 2 of the computer system 1 of FIG. 1.
Most know compilers attempt to optimize the object code generated. Compiler optimizing techniques are widely known, and take many forms. However, optimization by a compiler suffers. Global information which could further reduce resource requirements at execution time is general not specified in the individual object modules. The complexities of aggressively modifying linked object code have minimized the number of systems that are known for performing post-compiler object code manipulation.
FIG. 3 is a flow diagram of the optimization process of the invention performed by the optimizing linker 50 of FIG. 2. The linker 50 includes a translator 51, an organizer 54, an analyzer 55, an optimizer 56, and a code generator 57.
First as a brief introduction, object modules 41-43 and library modules 49 are processed by the optimizing linker 50 in separate phases. During an initial phase, the translator 51 transforms the collection of object modules 40 and any optional library modules 49 into a single linked code module 52.
The linked code module 52 is in the form of an intermediate register transfer language (RTL) having machine-independent instructions compatible with different computer systems. Specific architectures of target computer systems can be maintained in a CPU architectures description 9. The CPU description 9 may include instruction operand and operator field specifications, instruction timings such as fetch latencies and pile-line delays. The CPU description 9 can also describe cache, memory, and register characteristics, including addressing schemes. The CPU description 9 can also be used to translate object code to RTL and RTL to machine executable code.
The translator 51 also transforms all object code operand addresses into symbolic addresses. The relocation tables and the symbol tables 44-46 are likewise transformed into a logical symbol table (LST) 53. The linked code module 52, the LST 53, and the CPU architecture description 9 can be stored in the memory 3.
The organizer 54 partitions the linked code 52 into a collection of procedures 100. Each of the procedures 101-103 includes instructions which are related during execution. Furthermore, the instructions in each of the procedures 101-103 are organized into basic execution blocks, for example basic blocks 105. A "basic block" is a sequence of instructions which are all executed if the first instruction of the sequence is executed. Basic blocks 105 can be classified as either "normal" blocks or "control" blocks. A normal block merely manipulates data, control blocks do not manipulate data, they alter the flow of execution.
The organizer 54 builds procedure flow graphs (PFG) 200 and a program call graph (PCG) 300 in the memory 3. For each of the procedures 101-103, the PFG 200 maps the flow of control through the basic blocks 105 of the corresponding procedure during execution. The PCG 300 indicates how the procedures are called by each other. The graphs 200 and 300 are described in greater detail with reference to FIG. 4.
The analyzer 55 examines the RTL linked code 52 for optimizing opportunities with the aid of the LST 53, the PFG 200, and the PCG 300. The optimizer 56 performs the actual optimization by adding, deleting, and moving instruction, even across procedures boundaries, without concern for the target hardware architecture.
The code generator 57 generates machine-dependent code for the target hardware architecture. All symbolic addresses are resolved and recomputed because instructions may have been moved, altered, and deleted. Delays may need to be introduced into the executable code for certain architectures, for example RISC architectures executing instructions in parallel. Other code may have to be rescheduled for execution to remove the possibility of pipeline hazards and execution stalls. It should be noted that the machine executable code 60 produced by the code generator 57 may be compatible with the assembly language of the object modules 41-43, or a completely different target architecture described in the CPU description 9.
Now a more detailed description of the preferred embodiment of the optimizing linker 50 is given. During an initial phase of the linker 50, the translator 51 converts the object modules 41-43 and any selected modules of the library 49 to the linked module 52 in an intermediate language form. The intermediate representation of the program is in the form of the register transfer language and the logical symbol table 51. The RTL is machine-independent In the preferred embodiment of the invention, the RTL has been oriented for reduced instruction set computing (RISC) architectures.
The RTL includes generic instructions such as "add" and "sub" that operate on registers and constants. Only the "load" and "store" instructions access the memory. Procedure calls in the RTL are simple transfers of control instructions, for example "jump," and any parameters passed upon transfers of control are explicitly exposed. Unlike traditional machine code, the RTL assumes an infinite set of registers, with some of the registers possibly having dedicated functions, for example, floating point arithmetic and a stack-pointer (SP) and a program counter (PC).
All operand address references in the RTL linked code 52 are symbolic. For example, addresses expressed relative to the PC are converted to targets which are labels in the logical symbol table 53. Similarly, all references to memory areas are converted to symbolic memory references. Converting all addresses to symbolic form has the advantage of enabling unconstrained movement and modification of the instructions of the linked module 52 during subsequent phases of the optimizing linker 50.
During transformation, the translator 51 may recover some of the structure of the original source modules so that the link-time optimizer can have as much information as the compiler 30 did. For example, the translator 51 searches the linked code 52 for what were source-level case-statements. Typically, a case-statement is compiled into object code as an indirect "jump" through some address stored in a jump table. The off-set of the stored address in the jump table is usually indexed by the case index value. The jump table for case-statements is usually stored in a read-only area of the memory 3 with the addresses of different jump targets stored in successive memory locations. This makes it possible to recognize case-statements in the object code. The address of the jump table can be obtained by examining the case-statement object code.
By identifying all of the case-statements in a program, the jump table can be partitioned into a set of smaller jump tables of a known size. This in turn reveals all possible jump destinations. The table size may be cross-checked against the part of the case-statement object code which checks the range of the index value. Recovering case statements facilitate the construction of the graphs 200 and 300.
Certain machine executable instructions such as "load-address" and double-precision "loads" and "stores" are usually expressed in the object code as sequences of simpler instructions. Recognizing such simpler instructions allows optimization of the eventual machine code in ways not possible with conventional linkers and assemblers. The relocation and symbol tables 44-46 are helpful in reassociating the parts of a "load-address" operation since the instruction fields that are combined to make up the address must be marked for relocation.
However, double-precision "loads" and "stores" require some additional work. A double-precision access is really two single accesses to an even/odd register referencing adjacent memory addresses. Since the double-precision access occurs in an even/odd pair, the odd double-precision register of a "load" instruction is used as a starting point. A search is made for the matching object code instruction which must use the conjugate even double-precision register and must address the adjoining memory location.
The linked module 52 of the preferred embodiment does not use delayed "branch" instructions typically found in programs using parallel execution mechanisms. Instructions which occupy a delay slot in the object code are moved out of sequence. If the delay slot is filled only with instructions which normally are executed prior to the branch, they can be restored. If the instructions in the delay slot change a register used by the branch it is incorrect to restore the instructions. Instead, in the linked module 52, the branch slot is duplicated and pushed ahead to both the destination address and the fall-through address. If the instructions in the delay slot are never executed, or "dead-code" they do not need to be duplicated.
In the next phase, the organizer 54 of the linker 50, partitions the linked module 52 into the collection of procedures 100. Instructions in each of the procedures 101-103 are further grouped into basic blocks 105. The procedure flow graph 200 is built for each procedure, and the complete program call graph 300 is build for the entire program. These execution control structures are used during the subsequent analyzing and optimizing phase. For example, the optimizing linker 50 can measure the quantity of code which is not directly addressable.
The linked module 52 reveals optimization opportunities which would not have been visible to the compiler. Moreover, by having the linked code 52 in RTL form, code modification can be performed aggressively, and in a manner not possible by traditional optimizing compilers. Instructions of the RTL linked code 52 can be freely moved and deleted to minimize the use of system resources such as general purpose registers, cache memory, and execution cycles.
The optimizer 56, according to the principles of the invention, can perform optimization among procedures (inter-procedural optimization), and optimization within a procedure (intra-procedural optimization). Loop-invariant code can be moved across procedure boundaries. Dead-code can be expunged. Redundant register-to-register copies and duplicate save/stores can be reduced.
One optimizing method used by the optimizer 56 removes invariant codes from execution loops. Loops are defined as any repeated execution of instructions by either iteration or recursion. "Invariant code" are instructions which do not change the execution state of the computer system 1 during the execution loop. In other words, invariant code does not alter data. Removing the invariant code form the loop shortens the loop and lessens execution time. As an advantage of the invention, the link-time optimizer detects execution loops which span object modules. Such execution loops go undetected by traditional compilers.
Execution loops can be deduced by iteration and recursion. Invariant code is detected by examining the operator and operands of instructions. For example, instructions which load addresses are guaranteed to be invariant. To reap the benefit of code motion, the data should be stored in a register during execution of the loop.
To locate unused register inside loops, a liveliness analysis is performed by the analyzer 55. The liveliness analysis locates registers which are not used while executing in loops. The liveliness analysis, as described herein, can also be used by compilers to simplify traditional invariant code removal.
Liveliness analysis treats the entire program, as converted into the organized linked module 100, and as described in the program call graph 300, as a single executable entity. The procedure flow graphs 200 contain sufficient information to filter the execution control to and from the procedures.
With reference to FIGS. 4 and 5, the liveliness analysis of the analyzer 55 is now described. FIG. 4 shows the program call graph 300 imposed on the organized linked module 100, and the procedure flow graphs 200 imposed on the procedures 101-103. The procedures are partitioned into a group of basic blocks 151-155. Some of the basic blocks may be single instructions. The basic blocks are classified as either a call block 151, a return block 152, an entry block 153, an exit block 154, or a normal block 155.
The interface or edges between the procedures are 101-103 conjugate pairs of control blocks, for example, call blocks 151 and return blocks 152. The call block 151 is the last block executed in the procedure before execution control is transferred to another procedure. Upon return, the return block 152 is executed first. Each call block 151 has a single successor entry block 151 in the called procedure. The entry block is executed first when a procedure is called by another procedure of the program. Each return block 152 has a single predecessor exit block 154. The exit block 154 is the last block executed before execution control is transferred to the calling procedure. An entry block may have many predecessor blocks, likewise for successors of the exit blocks 154. The normal blocks 155 are not involved in the transfer of execution control, the normal blocks 155 define, use and consume variables and registers, for example, variables x, y, and z.
In the module 100, procedures 101 and 103 call procedure 102. Inter-procedural edges are present at the call blocks 151 and the entry blocks 153, the exit block 154 and the return blocks 153. Instructions which traditional compilers may have associated with the control blocks at the inter-procedural edges, for example instructions which pass arguments and manipulate the stack are explicitly exposed, and do not need to be considered part of the control blocks. Therefore, such instructions are assigned to normal blocks.
During the liveliness analysis, the two sets of variables, see FIG. 5, are constructed for each basic block (B), for example sets LIVEIN(B) 558 and LIVEOUT(B) 559. The set LIVEIN(B) 558 includes the variables which are live immediately before the block (B) is executed, and the set LIVEOUT(B) 559 includes variables which are live immediately after the block (B) is executed.
The whole program can be treated as one big flow graph with liveliness execution information flowing across procedure boundaries. At the entry block 153 of procedure 102 of FIG. 4, variables x and y are live, but variable z is not. Care must be taken to discount information which flows along paths which cannot be followed during actual execution. For example, there is an execution path from the call block 151 of procedure 101, through procedure 102, where y is live, to the use of y in procedure 103. However, it is imprecise to conclude that y is live in call block 151 of procedure 101, because it is meaningless to associate a call block with its conjugate return block, when the return is due to some other call.
As shown in FIG. 5, the analyzer 55 performs a rigorous liveliness analysis 550 in two stages. In the first stage, STAGE I, during step 551, all the return edges along the execution control path are removed. Then in steps 552 and 553 the procedure 550 determine the liveliness information for normal and control blocks. In a conservative liveliness analysis approach, variables are "live" if there is any possibility that they could be used in the block. They are "dead" only if there is no doubt they are not used.
The liveliness information can flow over normal edges and control edges, and from a return block to its conjugate call block. Because the return edges are deleted, information does not flow along the return path. Therefore, the first stage of liveliness analysis gives a precise, low-sensitive summary of the possible effects on the liveliness of variables of calling each procedure, including the effects on the liveliness of any calls that are made from the called procedure.
In the second stage of liveliness analysis, STAGE II, during step 554 the return edges are restored and the call edges are deleted. Then, in steps 555 and 556, which use the summary information collected in the first stage, it is determined if the variables which might be live before the call are in fact live. Because the information can flow from a calling procedure to a called procedure, and vise versa, the liveliness information as expressed in the sets LIVEIN(B) and LIVEOUT(B) is precise. An example variable liveliness analysis procedure 550 is presented in programmable form in Appendix A.
Any variables which are live when execution in any of the normal blocks 155 is completed are also live at commencement of execution of the successor block. Variables which are live, when execution in normal blocks 155 begins, include those variables which are live when execution in the blocks 155 is completed, but not necessarily set in the blocks 155, and any variables that are used in the block 155 before being set in the blocks 155.
In a preferred embodiment, a conjugate pair of call and return blocks only include instructions which cause the transfer of execution flow, these control blocks neither define nor use variables. Therefore the sets LIVEIN(B) 558 and LIVEOUT(B) 559 for call and return blocks are identical.
A variable is "live" at the start of a call block for either of two reasons; the variable is used by the called procedure, or the variable is used after the return from the called procedure. Therefore, in the first stage of liveliness analysis, liveliness information is allowed to flow to a call block both from the entry block of the procedure and from the call block's conjugate return block.
In the second stage of liveliness analysis, if liveliness information flows into the procedure from different return blocks, information flow along the call edge is cut-off and replaced with the entry set LIVEIN(B) 558 of the block as produced by the first stage. This step prevents imprecise liveliness information to flow from the return block to a non-conjugate call block.
The liveliness analysis also determines the liveliness of registers used by the procedures. Commonly, procedures save variables stored in registers when execution in the procedure is begun, for example, in a stack. The variables are restored after execution in the procedure is completed. This allows the instructions of the procedure to assign registers for unrelated uses at will. The saving, restoring, and unrelated use of registers are not considered true use for the purpose of liveliness analysis.
Indirect calls to procedures pose a special problem for inter-procedural liveliness analysis. Typically, the indirect call is via a procedure variable, the procedure variable, at different times, stores the address of an actual procedure. Indirect calls may be transformed into a direct call to an abstract procedure. The abstract procedure in turn calls each actual procedure that may be the value of the procedure variable. In the preferred embodiment, all indirect procedure calls are identified. This determination yields all values which can be assumed by the procedure variable. A conjugate call/return block pair are constructed for each value, and the pairs of conjugate blocks are combined to form the abstract procedure.
The basic blocks 151-155 of the procedures 101-103 of the program 20 are repeatedly examined during successive passes, each pass updating the information in the sets LIVEIN(B) 558 and LIVEOUT(B) 559. The final iteration is recognized when the examination reveals no further changes to the sets LIVEIN(B) 558 and LIVEOUT(B) 559.
The order in which the basic blocks are examined is complicated by the fact that the order is different in the first and second stages of the liveliness analysis. For this reason, the order of examining the basic blocks of the procedures is determined separately for each procedure using the procedure flow graphs 200. Similarly, the order of examining the procedures is determined from the program call graph 300.
In either the first or second stage, the basic blocks of each procedures are examined consecutively, in a reverse-depth-first order. In the first stage, the procedures are examined in reverse-depth-first order. This order tends to examine the called procedures before the calling procedure. In the second stage the order of examining the procedures is reversed, the basic blocks of the calling procedure are examined before the blocks of the called procedure.
Now again with reference to FIG. 3, the modification of the RTL linked code 52 for optimization purposes is performed during the next phase of optimizing linker 50 by the optimizer 56. Specific examples of optimization which will be described are: loop invariant code motion, and inter-procedural "dead code" elimination. Both operations require the results of the liveliness analysis.
For example, by moving invariant code, the number of instructions executed in the loop is reduced to improve performance. The precise information expressed in the sets LIVEIN(B) 558 and LIVEOUT(B) 559, the flow graphs 200 and the call graph 300 state precise variable utilization in context of the entire program 20. Therefore, opportunities for reducing the number of registers used are more numerous than would be possible with traditional optimizing compilers. Moreover, optimizing the entire program 20 enables code motion across procedural boundaries.
Inter-procedural liveliness information allows for removing dead code which may not have been recognized by the compiler 30. An instance of such dead code removal is illustrated with respect to in FIG. 6. A procedure 104 incudes basic blocks 171-177, and a procedure 105 includes basic blocks 181-185.
In procedure 104, block 171 preserves the stored value of a register R1 in a stack indexed by the stack pointer register SP. Block 172 defines and uses register R1. Block 173 calls procedure 105. In procedure 105, block 181 preserves register R1 in the stack. Block 182 defines and uses R1. Block 183 generates a result in register R2. Block 184 restores R1 from the stack, and block 185 exits to the return block 174 of procedure 104.
Continuing in procedure 104, block 175 does not use R1 or the result stored in R2, block 176 restores register R1, and block 177 is the exit block of procedure 104. The compiler may have treated register R1 as a register to be preserved while executing in procedure 105, however register R1 is subsequently not used. Therefore, register R1 as determined by the liveliness analysis of the present invention is "dead" and instructions of procedure 105 which reference register R1, for example blocks 182, and 184 can be removed.
Similarly, procedure 105 returns an extraneous result in register R2. The generation of extraneous results is a common occurrence with a procedural high-level language such as C. Therefore, register R2 is also dead, and block 183 can likewise be removed.
To discover that the blocks 181-184, and perhaps the entire procedure 105 are dead, the liveliness information of the procedure 104 need to be available when the procedure 105 is examined for dead code removal opportunities. Traditional compilers would not have revealed these opportunities, since in traditional compilers the liveliness information only flows forward. In contrast, the liveliness analyses information, according to the present invention can flow in both directions.
Loop-invariant code which does not modify variables from one iteration of a loop to the next is another optimizing opportunity. Mechanisms which detect loops and recognize loop-invariant code are well understood for single procedures optimized by compilers. However, recognizing loops which can span an entire program, crossing procedure boundaries, are not completely visible to compilers which process object code modules one at the time.
FIG. 7 shows two example of loops which can be optimized by the principles of the invention, and which would have gone undetected by known optimizing compilers. Procedures 121-124 include call blocks 191-194. The conjugate return blocks for the call blocks 191-194 are not shown. Procedure 122 is iteratively called from a loop in procedure 121 including call block 191. Procedure 121 also call procedure 123 via call block 192. Procedures 123 and 124 call each other.
Examining procedures 121 and 122 in isolation, as a compiler might do, will not disclose whether either of the procedures includes loop-invariant code which could be moved to a predecessor procedure. Similarly, code which is invariant in the recursive execution cycles of procedures 123 and 124 could also be moved to procedure 121.
Some compilers attempt to move invariant code across procedure boundaries by placing procedures in-line and executing code strictly sequentially. Unless cache behavior is considered when placing the procedures in-line, "in-lining" can have unpredictable and sometimes detrimental effects on the performance of the cache. Also, simple placing the procedures in-line can overwhelm existing compile-time optimizers, sometimes causing them to stop functioning, or confusing the optimization to the point that performance is actually degraded. Precise inter-procedural flow analysis according to the principles of the invention can avoid these problems.
For example, the present inter-procedural liveliness analysis looks across procedure boundaries and determine when registers are dead or unused for larger portions of the program. Invariant variables can be stored in these unused or dead registers. Instructions which load memory addresses are by definition invariant and obvious candidates for code motion.
The present invention solves several problems to enable loop-invariant code motion across procedural boundaries. For example, in the preferred embodiment, the full extent or span of each loop is determined. All the procedures which are included in the span of an inter-procedural loop are called the "loop-region."
Traditionally, loops are identified as a set of program components which are tightly coupled by execution control and dominated by another external program component. This approach does not make sense here. The bi-directional flow of liveliness information of the preferred embodiment, that is, along the call edges and along the return edges would result in many "false" loops that are invalid during actual execution. Control can not follow these paths. The summary information collected by the liveliness analysis can be used to filter data flow over these edges. The methods of the present invention correctly find loops which span several procedures, while excluding components of the program which are not dominated by the entry point to the loop.
The problem of finding inter-procedural loops is solved by studying the execution path of the entire program in a top-down manner. This is done by concentrating on the program call graph 300 instead of the procedure flow graph 200. First, all "heavy" or dominating procedures are identified. A heavy procedure could be any procedures that is visited, for example, more than once during execution.
The procedure and the call block which transfer execution to the heavy procedure are designated to be a loop header procedure, and loop header call block, respectively. Next, an attempt is made to move loop-invariant basic blocks from the heavy procedure, or successor procedures reachable from the heavy procedure, across the header block, and into the header procedure. Thus, loop-invariant code can migrate from procedure to procedure until it is pushed out of the loop. Of course, all procedures through which the invariant code migrates must be dominated by the header procedure to ensure that available or "free" registers are not violated by some procedure calling into the loop region extraneously.
FIG. 8 shows a program having procedures 320-329 calling each other as defined by a program call graph 300 having calling edges 330-341. The procedures of the program are indicated by the circles, and the call graph 300 is indicated by the directed arrows. FIG. 9 shows a process 400 that can be used to find loop regions of the program.
Now with reference to both FIGS. 8 and 9, in step 401, each of the edge 330-341 is weighted by an estimate of the number of times that the execution path will cross the edge. These estimated weights are derived from instruction iterations and recursions. To estimate the weight of an edge, the weight is first set to zero. For each call to a successor procedure, add ten raised to a power which is equal to the number loops which contain the calling side of the edge, e.g., the call block. Then for each recursive call to the called successor procedure multiply the weight of the edge by ten. The weight of each of the edges is independently determined. The weight do not accumulate as the edges of the call graph 200 are followed. For example, the weight of edge 334 is independently computed from the weight of the surrounding edges 330, 331, 332, 333, 335, and 336.
Using the weighted call graph 300, in step 402 determine an initial loop region. A call edge with a large weight implies the presence of some loop region because the successor procedures are called repetitively by a dominating procedure. If the program call graph 300 were to have the form of a tree, the loop region of the tree would include the called procedure 321 and all its descendants, for example the procedures 321, 322, 323, 324, 325, and 329.
However, very few real programs have call graphs in the form of a tree. Therefore, additional steps must be taken to isolate the loop region. In step 403, any procedures, directly or indirectly connected to the calling procedure are added to loop region, for example, procedures 326 and 327 shown cross-hatched.
In step 404, any procedures in the loop region which are also called by procedures outside the loop region are pruned from the loop region. The remaining procedures are determined to be the loop region. An example of the procedure 400 is detailed in Appendix B in a form suitable for programming.
The resulting loop region, generally indicated by a broken line 399 may include procedures which include call blocks to transfer execution control to procedures outside the region, for example procedure 329. Such procedures are called step procedures of the loop region 399. Step procedures should be considered part of the loop region. However, since step procedures are reachable from outside the loop region it is not safe to migrate loop-invariant code across them.
Also, if the loop header procedure 320 does not dominate the loop region 399, the region is pruned so thoroughly that it only contains the header procedure 320 itself. In this case, any remnants of the loop are contained in the header procedure, and only the basic blocks of the header procedure 320 can become candidates of code motion. If the loop arose because the successor procedure called the "header" procedure recursively, then the header procedure contains no instructions eligible for moving.
After the boundaries of the loop region have been established, the next task is to identify all instructions which are invariant within the loop region, see step 405. For example, a frequently used type of instruction which is always invariant is a load-memory address into register operation.
In step 406, each candidate invariant instruction is assigned an estimated execution count. The execution count combines the number of machine cycles required to execute the instruction by the depth of the loop within the procedure and by the weight of the edges on the call graph edges leading to the procedure.
Next, in step 407, the candidate invariant instructions are ordered according to the combined execution counts. In step 408, those instructions which will yield the highest pay-back, e.g., instructions having higher execution counts, will be allocated to available registers in rank order, until the supply of available registers for the loop region is exhausted.
In the preferred embodiment of the invention, available registers are identified as follows. An available register can not be referenced anywhere in the loop region, except possibly the temporary use of the register to save and restore variables during the execution of the header procedure 320. An unreferenced register is available if it is dead at the exit block of the header procedure, or if it is dead at the exit block of the step procedures, or if it is unreferenced in any of the step procedures or their descendants.
For each available and identified register, the next heaviest loop-invariant instruction is removed from the loop region. Each removed instruction is replaced with a register-to-register copy instruction to ensure that the variable is stored in the correct location.
The process steps of identifying a loop region, weighing loop-invariant instructions, ordering the loop-invariant instructions, and identifying available registers to hold the variables of loop-invariant instructions are performed for each of the edges 330-341 of the program call graph 300 with a weight greater than unity.
After inter-procedural code has been moved, any loop-invariant code within a procedure is relocated. Even though a traditional optimizing compiler may already have move loop-invariant code within procedures of the object modules, there are advantages to be gained if this optimizing step is redone for the linked module 100.
First, the liveliness analysis of the optimizing linker 50 is substantially more precise than any analysis which could be performed by a traditional compiler 30. The optimizing linker 50 considers the entire program 20, the compiler 30 only deals with small portions of the program 20 at any one time. The link-time optimizer 50 can identify available registers which go unnoticed by the compiler.
Furthermore, the allocation of available registers is fully integrated with the process of moving loop-invariant code. This permits the moving of very small pieces of invariant code, since the performance pay-back can only be realized if registers to store the result variables are available. The inter-procedural liveliness analysis provides these available registers.
After the inter-procedural code motion and after the intra-procedural code motion, the link-time optimizer 55 performs a clean-up process. Clean-up removes common sub-expressions, inter-procedural dead code, redundant instructions which save and restore variables, temporary register-to-register copy instructions, and any duplicate code portions of invariant code which were moved to the same area from different locations.
When the linked code module 100 is fully optimized, the procedures 101-103 are rearranged in a depth-first order. This heuristic rearrangement is intended to improve execution locality and hence cache behavior. The code generator 57, using the CPU description 9, can produce machine executable code 60 from the rearranged linked module 52. The machine code can be for any defined architecture, including the architecture presumed for the object modules 41-43.
The advantages of the claimed invention are particularly applicable to object code having loop-invariant code, and available registers. Since traditional compilers are hindered by the need to support separate compilations, and their own internal fragmentation, such occurrences are likely. The optimizing linker's ability to analysis the entire program at once, at the object code level, create optimizing opportunities to which the compiler would be blind.
The link-time optimizer according to the principles of the invention can deliver significant improvements in performance without simply cloning code and moving the cloned code in-line. Cloning code for in-lining purposes tends to greatly increase the size of programs. The link-time optimizer can perform execution flow and live variable analysis for the entire program without any input from the compiler. All high level program structure and processes knowledge is derived directly and solely from the object nodules, without any reference to the original source code.
Appendices A and B are attached which illustrate specific procedures of the inventions suitable for implementation in a computer system.
It will be apparent to those skilled in the art that various modifications can be made to the link-optimizer of the present invention without departing from the spirit and scope of the invention as set out in the appended claims.
Remove return edges and compute LIVE ("may be live") and DEAD ("must be dead") information for procedure B and with a successor procedure S.
Normal Blocks:
DEF[B]=variables defined by B before any use in B
USE[B]=variables used in B before any definition in B
LIVEOUT[B]=∪s LIVEIN[S] for all successors S of B
DEADOUT[B]=∪s DEADIN[S] for all successors S of B
Call and Return blocks.
LIVEOUT[call]=LIVEIN[entry] ∪ LIVEOUT[return]-DEADIN[entry]
LIVEOUT[retun]=∪s LIVEIN[S] for all successors S of return
DEADOUT[call]=DEADIN[entry] ∪ DEADOUT[return]-LIVEIN[entry]
DEADOUT[return]=∩s DEADIN[S] for all successors S of return
LIVEIN sets for a call or return block are identical to its LIVEOUT sets
When this converges, define, for cach procedure P:
PUSE[P]=LIVEIN[B] where B is the entry to P
PDEF[P]=DEADIN[B] where B is the entry to P
and then throw away the LIVE and DEAD sets computed in this phase.
Restore return edges and delete call edges, and compute live (may be live) information for:
Normal blocks:
DEF[B]=variables defined by B before any use in B
USE[B]=variables used in B before any definition in B
LIVEOUT[B]=∪s LIVEIN[S] for all successors S of B
Calll and Return Blocks procedure P:
LIVEOUT[call]=PUSE[P] ∪ LIVEOUT[return]-PDEF[P]
LIVEOUT [return]=∪s LIVEIN[S] for all successors S of return
LIVEIN sets for a call or return block are identical to its LIVEOUT sets.
Input: A call graph C=(P,E) where P is the set of procedures and E is the set of call edges, a depth first spanning tree D of C, and an edge e=(ph →Pe)
Output: LoopRegion(e), a subset of the procedures of C.
A Method:
First, for LoopRegion .OR right. the decendants in D of ph build initial set of nodes reachable from pe *
constant:Family={p/p is a descendant of ph in D}
LoopRegion={ph, pe }
while changes to set LoopRegion do
for each p in family-{ph }, in depth-first order, do
if p ε LoopRegion then
for each procedure q that p calls do
if q .epsilon slash. LoopRegion and q ε Family then
LoopRegion=LoopRegion ∪ {q}
Then, add callers of nodes already in region, if all callers are in the family
while changes to set LoopRegion do
for each q in Family, in reverse-depth-first order, do
if q ε LoopRegion then
for each procedure p that calls q do
if p .epsilon slash. Family then addcallers=false
if addcallers then
for each procedure p that calls q do
if p .epsilon slash. LoopRegion then
°LoopRegion=LoopRegion ∪ {p}
And, ensure that the loop region is dominated by a single entry point
while changes to set LoopRegion do
for each q in Family-{ph }, in depth-first order, do
if q ε LoopRegion then
for each procedure p that calls q do
if p .epsilon slash. LoopRegion then
|Data de depósito
|Data de publicaçăo
|10 set. 1984
|19 maio 1987
|501 Philon, Inc.
|Compilers using a universal intermediate language
|8 mar. 1989
|3 nov. 1992
|Wisconsin Alumni Research Foundation
|Interprocedural slicing of computer programs using dependence graphs
|23 ago. 1990
|29 dez. 1992
|Supercomputer Systems Limited Partnership
|Computer with integrated hierarchical representation (ihr) of program wherein ihr file is available for debugging and optimizing during target execution
|11 jun. 1990
|12 jan. 1993
|Supercomputer Systems Limited Partnership
|System and method for controlling a highly parallel multiprocessor using an anarchy based scheduler for parallel execution thread scheduling
|30 jun. 1989
|6 abr. 1993
|Digital Equipment Corporation
|Line-skip compiler for source-code development system
|1 jun. 1990
|18 maio 1993
|Hewlett-Packard Company
|Method for optimizing computer code to provide more efficient execution on computers having cache memories
|25 jun. 1990
|4 jan. 1994
|Hewlett-Packard Company
|ANDF producer using the HPcode-Plus compiler intermediate language
|20 set. 1991
|5 jul. 1994
|International Business Machines Corporation
|System and method for solving monotone information propagation problems
|Compliers Principles, Techniques and Tools, Sept. 1985.
|Moher, T., "Provide: A Process Visualization and Debugging Environment", IEEE Transactions on Software Engineering, vol. 14, No. 6, Jun. 1988.
|Moher, T., Provide: A Process Visualization and Debugging Environment , IEEE Transactions on Software Engineering, vol. 14, No. 6, Jun. 1988.
|New Optimizations for PA RISC compliers Robert C. Hansen, Jun. 1992.
|New Optimizations for PA-RISC compliers Robert C. Hansen, Jun. 1992.
|Data de depósito
|Data de publicaçăo
|9 dez. 1997
|16 jan. 2001
|International Business Machines Corporation
|Method of, system for, and computer program product for providing efficient utilization of memory hierarchy through code restructuring
|22 dez. 1998
|12 jun. 2001
|Nortel Networks Limited
|Method and apparatus for identifying and removing unused software procedures
|22 out. 1999
|19 jun. 2001
|International Business Machines Corporation
|Method and apparatus for determining most recently used methods
|16 set. 1997
|31 jul. 2001
|Microsoft Corporation
|Method and system for improving the layout of a program image using clustering
|26 jan. 1999
|18 set. 2001
|Nec Corporation
|Program complete system and its compile method for efficiently compiling a source program including an indirect call for a procedure
|24 fev. 1999
|25 jun. 2002
|Texas Instruments Incorporated
|Method and system of providing dynamic optimization information in a code interpretive runtime environment
|30 jun. 1999
|12 nov. 2002
|Microsoft Corporation
|Instrumentation and optimization tools for heterogeneous programs
|22 out. 1999
|26 ago. 2003
|Matsushita Electric Industrial Co., Ltd.
|Instruction string optimization with estimation of basic block dependence relations where the first step is to remove self-dependent branching
|14 dez. 1998
|25 nov. 2003
|International Business Machines Corporation
|Removal of unreachable methods in object-oriented applications based on program interface analysis
|4 out. 2000
|15 jun. 2004
|Sun Microsystems, Inc.
|Using value-expression graphs for data-flow optimizations
|11 abr. 2001
|9 nov. 2004
|Hewlett-Packard Development Company, L.P.
|Analysis of executable program code using compiler-generated function entry points and endpoints with other sources of function entry points and endpoints
|10 out. 2000
|4 jan. 2005
|International Business Machines Corporation
|Method of, system for, and computer program product for providing efficient utilization of memory hierarchy through code restructuring
|30 jun. 2000
|14 jun. 2005
|Intel Corporation
|Method and apparatus for inserting more than one allocation instruction within a routine
|2 maio 2001
|26 jul. 2005
|Danger, Inc.
|System and method for transforming object code
|3 jul. 2001
|26 jul. 2005
|International Business Machines Corporation
|Debugger impact reduction through breakpoint motion
|1 ago. 2001
|29 nov. 2005
|International Business Machines Corporation
|Debugger impact reduction through motion of induction variable based breakpoints
|21 set. 2001
|7 fev. 2006
|International Business Machines Corporation
|Graphical view of program structure during debugging session
|14 mar. 2002
|21 mar. 2006
|International Business Machines Corporation
|Eliminating store/restores within hot function prolog/epilogs using volatile registers
|29 dez. 2000
|27 jun. 2006
|Intel Corporation
|Quantization and compression for computation reuse
|30 maio 2001
|31 out. 2006
|International Business Machines Corporation
|Code optimization
|8 jun. 2001
|9 jan. 2007
|Nvidia Corporation
|Software emulator for optimizing application-programmable vertex processing
|29 ago. 2003
|17 abr. 2007
|Nokia Corporation
|Constructing control flows graphs of binary executable programs at post-link time
|7 maio 2001
|20 nov. 2007
|Stmicroelectronics Limited
|Relocation format for linking
|4 mar. 2004
|3 jun. 2008
|International Business Machines Corporation
|Compiler device, method, program and recording medium
|19 mar. 2009
|23 mar. 2010
|International Business Machines Corporation
|Run time reconfiguration of computer instructions
|24 jan. 2008
|12 jul. 2011
|International Business Machines Corporation
|Compiler device, method, program and recording medium
|26 set. 2007
|8 nov. 2011
|International Business Machines Corporation
|Stable transitions in the presence of conditionals for an advanced dual-representation polyhedral loop transformation framework
|26 set. 2007
|15 nov. 2011
|International Business Machines Corporation
|System and method for advanced polyhedral loop transformations of source code in a compiler
|26 set. 2007
|27 dez. 2011
|International Business Machines Corporation
|Selective code generation optimization for an advanced dual-representation polyhedral loop transformation framework
|26 set. 2007
|27 dez. 2011
|International Business Machines Corporation
|Domain stretching for an advanced dual-representation polyhedral loop transformation framework
|29 nov. 2009
|9 abr. 2013
|Sap Ag
|Using idempotent operations to improve transaction performance
|1 ago. 2006
|7 maio 2013
|Nvidia Corporation
|Method and user interface for enhanced graphical operation organization
|1 ago. 2006
|7 maio 2013
|Nvidia Corporation
|User interface and method for graphical processing analysis
|10 abr. 2008
|21 maio 2013
|Nvidia Corporation
|Clock-gated series-coupled data processing modules
|1 mar. 2006
|28 maio 2013
|Nvidia Corporation
|Method for author verification and software authorization
|18 mar. 2008
|13 ago. 2013
|Oracle America, Inc.
|Link-time redundant code elimination using functional equivalence
|1 ago. 2006
|10 dez. 2013
|Nvidia Corporation
|Method and system for debugging a graphics pipeline subunit
|10 maio 2011
|17 dez. 2013
|Tata Consultancy Services Limited
|System and method for analysis of a large code base using partitioning
|15 dez. 2005
|15 abr. 2014
|Nvidia Corporation
|Method and system for providing a generic console interface for a graphics application
|12 jun. 2008
|13 maio 2014
|Oracle America, Inc.
|Method and apparatus for enregistering memory locations
|26 mar. 2009
|17 jun. 2014
|International Business Machines Corporation
|Code instrumentation method and code instrumentation apparatus
|11 maio 2009
|2 set. 2014
|Xmos Limited
|Compiling and linking
|14 set. 2012
|30 set. 2014
|Nvidia Corporation
|Enhanced clock gating in retimed modules
|20 abr. 2011
|13 jan. 2015
|Qualcomm Incorporated
|Inline function linking
|18 dez. 2006
|24 fev. 2015
|Nvidia Corporation
|Method and apparatus for visualizing component workloads in a unified shader GPU architecture
|31 dez. 2009
|24 fev. 2015
|Nvidia Corporation
|Method for author verification and software authorization
|31 out. 2007
|24 mar. 2015
|Implicit Networks, Inc.
|Method and system for code generation
|25 jan. 2006
|19 maio 2015
|International Business Machines Corporation
|Method for partitioning programs between a general purpose core and one or more accelerators
|15 ago. 2012
|26 abr. 2016
|Nvidia Corporation
|Method and system for automatic clock-gating of a clock grid at a clock source
|15 maio 2013
|18 out. 2016
|Nvidia Corporation
|Interleaved instruction debugger
|12 ago. 2010
|21 mar. 2017
|International Business Machines Corporation
|Code partitioning for enhanced performance
|26 jun. 2015
|1 ago. 2017
|Microsoft Technology Licensing, Llc
|Bulk allocation of instruction blocks to a processor instruction window
|14 abr. 2014
|17 out. 2017
|Microsoft Technology Licensing, Llc
|Incorporating a spatial array into one or more programmable processor cores
|5 jan. 2001
|31 jan. 2002
|Evelyn Duesterwald
|Fast runtime scheme for removing dead code across linked fragments
|29 dez. 2000
|4 jul. 2002
|Hong Wang
|Quantization and compression for computation reuse
|14 mar. 2002
|26 dez. 2002
|International Business Machines Corporation
|Eliminating store/restores within hot function prolog/epilogs using volatile regosters
|3 jul. 2001
|9 jan. 2003
|International Business Machines Corporation
|Debugger impact reduction through breakpoint motion
|8 jun. 2001
|9 jan. 2003
|Glanville Robert Steven
|Software emulator for optimizing application-programmable vertex processing
|21 set. 2001
|27 mar. 2003
|International Business Machines Corporation
|Graphical view of program structure during debugging session
|30 maio 2001
|24 abr. 2003
|International Business Machines Corporation
|Code optimization
|28 set. 2001
|29 maio 2003
|Youfeng Wu
|Method, apparatus, and system to formulate regions of reusable instructions
|17 jul. 2002
|12 jun. 2003
|Kiyomi Wada
|Program tuning method
|28 jun. 2002
|1 jan. 2004
|Microsoft Corporation
|Stripping of unnecessary information from source code
|4 jan. 2002
|22 jan. 2004
|Edward Balassanian
|Method and system for dynamic delivery of beads
|2 maio 2001
|22 jan. 2004
|Brian Swetland
|System and method for transforming object code
|11 abr. 2001
|22 jan. 2004
|Robert Hundt
|Analysis of executable program code using compiler-generated function entry points and endpoints with other sources of function entry points and endpoints
|7 maio 2001
|22 jan. 2004
|Richard Shann
|Relocation format for linking
|4 mar. 2004
|25 nov. 2004
|Motohiro Kawahito
|Compiler device, method, program and recording medium
|29 ago. 2003
|17 mar. 2005
|Nokia Corporation
|Method and a system for constructing control flows graphs of binary executable programs at post-link time
|14 jun. 2006
|18 jan. 2007
|Edward Balassanian
|Method and system for dynamic delivery of beads
|25 jan. 2006
|26 jul. 2007
|O'brien John Kevin P
|Apparatus and method for partitioning programs between a general purpose core and one or more accelerators
|1 ago. 2006
|7 fev. 2008
|Raul Aguaviva
|Method and user interface for enhanced graphical operation organization
|1 ago. 2006
|7 fev. 2008
|Raul Aguaviva
|Method and system for debugging a graphics pipeline subunit
|24 jan. 2008
|31 jul. 2008
|International Business Machines Corporation
|Compiler device, method, program and recording medium
|2 nov. 2006
|28 ago. 2008
|Edward Balassanian
|Method and System for Data Metering
|31 out. 2007
|2 out. 2008
|Edward Balassanian
|Method and system for dynamic delivery of beads
|26 set. 2007
|26 mar. 2009
|Eichenberger Alexandre E
|System and Method for Selective Code Generation Optimization for an Advanced Dual-Representation Polyhedral Loop Transformation Framework
|26 set. 2007
|26 mar. 2009
|Eichenberger Alexandre E
|System and Method for Stable Transitions in the Presence of Conditionals for an Advanced Dual-Representation Polyhedral Loop Transformation Framework
|26 set. 2007
|26 mar. 2009
|Eichenberger Alexandre E
|System and Method for Advanced Polyhedral Loop Transformations of Source Code in a Compiler
|18 mar. 2008
|24 set. 2009
|Sun Microsystems, Inc.
|Link-time redundant code elimination using functional equivalence
|26 mar. 2009
|1 out. 2009
|Wu Zhou
|Code Instrumentation Method and Code Instrumentation Apparatus
|10 abr. 2008
|15 out. 2009
|Nvidia Corporation
|Clock-gated series-coupled data processing modules
|26 set. 2007
|10 dez. 2009
|Eichenberger Alexandre E
|System and Method for Domain Stretching for an Advanced Dual-Representation Polyhedral Loop Transformation Framework
|12 jun. 2008
|17 dez. 2009
|Sun Microsystems, Inc.
|Method and apparatus for enregistering memory locations
|29 nov. 2009
|25 mar. 2010
|International Business Machines Corporation
|Using Idempotent Operations to Improve Transaction Performance
|31 dez. 2009
|1 jul. 2010
|Nvidia Corporation
|Method for author verification and software authorization
|11 maio 2009
|2 jun. 2011
|Xmos Limited
|Compiling and linking
|8 dez. 2010
|9 jun. 2011
|American National Laboratories, Inc.
|Method and apparatus for globally optimizing instruction code
|23 mar. 2015
|18 fev. 2016
|Implicit, Llc
|Method and system for code generation
|21 set. 2016
|16 mar. 2017
|Implicit, Llc
|Method and system for code generation
|25 jan. 2002
|9 out. 2003
|Danger Inc
|System and method for transforming object code
|Classificaçăo nos Estados Unidos
|717/162, 717/146, 717/159
|Classificaçăo internacional
|Classificaçăo cooperativa
|Classificaçăo europeia
|9 jan. 2002
Owner name: COMPAQ INFORMATION TECHNOLOGIES GROUP, L.P., TEXAS
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DIGITAL EQUIPMENT CORPORATION;COMPAQ COMPUTER CORPORATION;REEL/FRAME:012447/0903;SIGNING DATES FROM 19991209 TO 20010620
|7 maio 2003
|Fee payment
Year of fee payment: 4
|3 nov. 2003
Owner name: HEWLETT-PACKARD DEVELOPMENT COMPANY, L.P., TEXAS
Free format text: CHANGE OF NAME;ASSIGNOR:COMPAQ INFORMANTION TECHNOLOGIES GROUP LP;REEL/FRAME:014102/0224
Effective date: 20021001
|7 jun. 2007
|Fee payment
Year of fee payment: 8
|7 jun. 2011
|Fee payment
Year of fee payment: 12


text: Transition in effortless style with this pleated maternity dress. Its dark hues with summer breezy material are the perfect combination to bring you into the warmer months. Whether you are heading to the beach or going to a casual dinner, this comfortable and stylish dress is just what you're looking for.

subset: commoncrawl


text:
Ayurvedic Pain Relief Medicines
Clients can rely on us for meticulous packaging of the products. And, for attaining this objective, we have hired a team of professionals who make use of premium material and modern packaging tools for doing the same. The offered array of products is examined on the basis of quality of raw material and other inputs used for the manufacturing. Rest assured us for the raw material used, as we have most updated technolo
Shree Baidyanath Ayurved Bhawan Pvt. Ltd.
20, Great Nag Road, Maharashtra - 440009, India
Ayurvedic Pain Relief Medicines
We follow strict payment procedures for the transactions that ensure that no third party is involved in this. You can rely on us and we will offer you to make payments online or offline. An emerging name in the market, our organization is involved in offering Ayurvedic Pain Relief Medicines within the most lucrative deals.
Maharashtra Medical & General Store
16, Eden Rose Shopping Center, Beverly Park, Kanakia Mira Road (e), Maharashtra - 401107, India
Our experts ensure that payments are made on time and for that, we have online payment processing system to evade security issues. We have well maintained payment logs available for the convenience of our customers. Operation from Mumbai(India), we make available the broad product range to the customers in minimum time.
Generic Medicine
Office No 302, Swami Samarth Apartment, Ayodhya Nagar, Nagpur, Maharashtra - 440024, India
With the dedicated efforts of our efficient procurement team, we have emerged as the noteworthy Supplier, Trader and Exporter of the Pain Relief Medicines across India and abroad. We proffer the Pain Relief Medicines made of only best quality substances, to ensure high effectiveness and safe consumption. Buyers can lay their hands on the Cobix Tablets, Reactin Tablets and other Pain Relief Medicines offered by us at
Mediglobal Suppliers
Office No. 1, Gurudatta Society, 425/3, Narayan Peth, Maharashtra - 411030, India
We are well-reputed as one of the reliable Pain Relief Medicines Manufacturers in India. The Muscle Pain Relief Medicines offered by us are formulated using high-grade ingredients that ensure fast & effective relief in pain in various body parts. Moreover, customers are advised to use the Arthritis Pain Killer for external applications only.
Flagship Biotech International
111, Udyog Kshetra, Mulund Goregaon Link Road, Off. Lbs Marg., Maharashtra - 400080, India
Oxycodone 80 mg , oxycontin 80 mg , hydrocodone 10/325 mg , codine 40 mg and many more good products avaliable
Jmj Pharmacy
Vatika Business Centre, Level - 5, Tech Park One, Airport Road, Yerwada, Maharashtra - 411006, India
We are well known for supplying of wide variety of Pain Relief Medicines.
M.k. Medical Services
C-2 / 16 Jai Mata Di Compound, Kasheli, Maharashtra , India
Exponential Exports is a major Pain Relief Medicine Exporter and Supplier from Maharashtra, India. We are associated with number of reputed pharmaceutical companies for quick and easy procurement of Branded Pain Relief Medicine. These Pain Relief Medicines are well-tested and approved on diverse quality parameters. The range of Pain Relief Medicine, offered by us, is inclusive of Carisoprodol Tablets, Celecoxib Capsu
Exponential Exports
Fa/48, First Floor, Lake City Mall, Kapurbawadi, Maharashtra - 400607, India
Post your Buy Requirement
Backed by a team of highly experienced professionals, we are able to offer wide assortment of Pain Relief Medicines. These tablets are precisely processed under the surveillance of trained professionals who make use of optimum grade active ingredients with the help of advanced processing in adherence to set medical industry norms. Our offered tablets are made available in gradation of safe packaging options to
Rg Traders
Kamptee Road, Maharashtra - 440004, India
Backed by a team of highly experienced professionals, we are able to offer wide assortment of Pain Relief Medicines. These tablets are precisely processed under the surveillance of trained professionals who make use of optimum grade active ingredients with the help of advanced processing in adherence to set medical industry norms. Our offered tablets are made available in gradation of safe packaging options to more... less...
Bs Exports
Nandanvan Road, Plot No. 456, Bhande Plot, Ayurvedic Layout, Sakkardara, Maharashtra - 440009, India
Another variety that we bring forth to our nationwide patrons is Pain Killer Medicines ! We are supported by a team of pharmacists who hold expertise in this domain. As a result, our Pain Killer Medicines come with the guarantee of purity and quality. We are renowned Manufacturer and Supplier of Pain Killer Medicines in Maharashtra, India. One can get our Pain Management Medicines at feasible prices, from us.
Novo Nexus Pharmaceuticals
Novo Nexus Pharmaceuticals Dombivli (east), Thane, Maharashtra - 421201, India
We are leading traders of pain killer medicines. We specialize in providing a variety of pain killer medicines of different compositions and forms. details composition form packing type size glucosamine sulphate 500 mgtabblister10x10 diacerine 50 mg tabalu-alu5x30 aceclofenac100 mg + paracetamol 500 mgtabblister10x10 aceclofenac 100 mg + paracetamol 500 mg +serratiopeptidase 10 mg tabblister10x10 rabeprazole 20 mg +
Asmita Uphar Part 1poonamsagar Complex Miraroad E Thane, Maharashtra - 401107, India
We are large scale manufactureres and suppliers of pharmaceuticall powder and other research chemicalss, high growth hormones, pain killers etc with purity at least 99.9% purity with simplest ordering procedure. We can also supply much at very attractive prices, good discount rates, fast and secure delivery with lots of customer care worldwide shipping of good.we are assuring our customer of 100% delivery gauranteed. more... less...
Amazone Pharmacy Ltd
2nd Floor, Millennium Plaza, Near Bank Of India 442301, Maharashtra - 442301, India
DOMINANT PHARMACEUTICAL (P.) LTD. is specialized in the supply and export of a wide range of Ayurvedic Medicines in the international market. The Herbal Ayurvedic Medicines that we make available are processed from the pure and organic herbal materials available in the country. No harmful chemical or preservatives are used in their manufacturing thereby ensuring that hygienic content. These herbal medicines have no s
Dominant Pharmaceuticals Pvt. Ltd.
535, Shaniwar Peth, Appa Balawant Chowk., Maharashtra - 411031, India
The company is the best destination to avail 100% pure Ayurvedic Medicines . We are a prominent Exporter and Supplier of Ayurvedic Medicine, based in Thane, Maharashtra. Made from organic herbs, our Ayurvedic Medicine has no side effects and shows long lasting effects. Moreover, our Ayurvedic Medicine is precisely formulated under the supervision of experts. Attributes : Effective results Accurate composition Reasona
Astute Management Consultancy Pvt. Ltd.
A-203, Raj Darshan Chsl, Dada Patil Wadi, Naupada, Maharashtra - 400602, India
We offer Ayurvedic Medicine. Unique calrich improves energy, liver efficiency, helps maintain bone strength, improves vision, memory, digestion and in fighting cancel cells. Best innovative natural bone tonic dosage: 1 capsule 2 times in day with glass of water or milk indications: fractures, oesteopenia, oesteomalacia, osteoporosis, osteoarthritis, cervical spondylosis, lumbar spondylosis, rickets, pregnant mother, more... less...
The Bombayite International
G - 1, Mangal Savera, Talmiki Road, Meera Baug, Santacruz West, Maharashtra - 400054, India
We are a giant manufacturer, supplier, and exporter of a wide range of ayurvedic medicines in india.
Lasky Herbal
1-d/10, Vijay Vihar Chs, S-t Road, Chembur, Maharashtra - 400071, India
Post your Buy Requirement
witarex granules 250 gm pack take with warm water rich source of vitamin d3 calcium proteins Vishwachaitanya Ayurvediya Rasa-Shala is one of the leading Manufacturers and Suppliers of Ayurvedic Medicines.VISHWACHAITANAYA G.M.P.(Good manufacturing practices) by FDA And an ISO:9001-2015 certified company. We cater to the requirements of the customers across India by serving them with 100% certified medicines that are f more... less...
Vishwachaitanya Ayurvediya Rasa-shala
Sector No.- 108, Near Piaggio Vespa Plant , Opp. Airport Circle, Katphal Midc, Baramati, Maharashtra - 413133, India
We are offering Ayurvedic Medicines.
Sharp Health Care
E3 Ojas, Pashan, Maharashtra - 411021, India
The combined use of proper probiotics and ayurveda is termed proyurveda™. The probiotics (beneficial micro-organisms) survive long time when blended with herbs because herbs are antioxidants. Such proyurveda™ preparations exhibit enhanced activity and effectiveness without any side effects. Probiotics are stimulated with the aid of ayurvedic herbs and the ayurvedic herbal activity is also enhanced due to probioti
Maximaa Proyurveda
Mumbai, India, Maharashtra - 400067, India
Wide range of ayurvedic formulations. Oil, tooth paste , syrups , tablets , capsules and more formulations
Innovative Pharmaceuticals
The Primus, Near Axis Bank, Amrawati Road, Wadi, Nagpur-440023 (maharashtra) India, Maharashtra , India
We are offering ayurvedic medicines.
Indu Pharma
803, Kumar Surabhi,pune Satara Rd, Maharashtra - 411009, India
Ayurvedic medicines for general health & common diseases, very effective medicines like:- 1) liv 333 syrup & capsule (for liver problems) 2) well heart syrup (for heart) 3) k+ compound syrup (for renal disease) 4) immunoboost syrup (for immunity & general health) 5) artho kare capsule (for joints pain) 6) ayulex capsule (for gas, constipation) 7) arbonil capsule (for bone) 8) giganto capsule (for muscles & mass growt more... less...
118,ravikiran,new Link Road,andheri Westmumbai-400053, Maharashtra - 400053, India
We are offering ayurvedic medicines & raw material. Herbal medicines & their products.
Agrosurg Irradiators (india) Pvt Ltd
S.no. 86 & 96, N.h.8, Near Kaman Bridge,vill.juchandra, Tal. Vasai. Dist. Palghar 401208, Maharashtra - 401208, India
We are offering ayurvedic medicine. Nanal ayurved clinic deal in various types of ayurvedic medicine that are available at market leading prices.
Nanal Ayurvedic Clinic
Pt. Satavlekar Marg (old Mogal Lane), Maharashtra - 400016, India
Gausia Exports - We take pleasure in introducing ourselves as a renowned suppliers of ayurvedic medicines in India.
Gausia Exports Enterprise
503/504, Gurukrupa 5th Floor 133 Kazi Sayed Street, Maharashtra - 400003, India
One of the best leading supplier of ayurvedic medicines
G.s. Exports
Plot No. C-167, M.i.d.c., Ttc Industrial Area, Pawne, Maharashtra - 400 70, India
Flexicart tablets : anti-arthritic flexicart is clinically proven, natural medicine for anti-arthritis. It suppresses the inflammatory mediators which play major role in the progression of joint disorders. It gives potent analgesic effect. Ingredients - contains only herbal components. action: how does it act ?? reduce the joint stiffness and allow free movements of joint. Possess the immunomodulator activity decreas more... less...
Tulip Lab Pvt Ltd
4024, A-wing, Oberoi Garden Estate, Next To Chandivali Studio, Andheri(east), Mumbai, Maharashtra - 400072, India
We offer Ayurvedic Medicines. Purandare Group is sole distributor of various Ayurvedic medicines form Kerala. Our Mission is to Provide the most genuine and authentic Ayurveda medicines using traditional methodologies, extend over all health care at affordable rates, to spread the miraculous healing power of Ayurveda for the overall well being of society, to provide quality products and services for the cause of Ayur
Reliance Trading Corporation And Durga Lime Industries
37 Devashree Bungalow, Vidyanagar Lane No 1, Vishrambag, Maharashtra - 416416, India
We have hired experienced personnel to handle and supervise the task of packaging in a systematic order. Thus, there are minimal chances of damage from our end as our experts check the entire lot before dispatch. We have a strong distribution network, owing to which we efficiently transport the goods to the desired place. Piles medicine is used for cure piles even blooding
Chaitanya Herbal
Nagar Palika Society No-2, Near Dr. Vishwas Koli Hospital, Tal. Shirol, Dist. Kolhapur, Maharashtra - 416101, India
We are offering ayurvedic diabetes medicine.a result oriented ayurvedic product for diabetes it controls sugar and give relief from burning of palms as well as weakeness.
Aadhar Herbal Medicine
Waris Height In Front Of Hotel Ellora Palace Balagi Nagar Pune, Maharashtra , India
Located in Panvel(India), we ensure safe and secure deliveries, throughout the country, within the agreed time frame. Our company stands tall among the victorious Suppliers of Ayurvedic Herbal Medicines and offers the most lucrative deals to the customers.
Dave Pharmaceuticals
2,aditya Apts,plot No 107,mcch Society, Panvel-new Mumbai, Maharashtra - 410206, India
Ayurvedic Medicine - Cap Vipul
We are offering cap vipul. Cap vipul is ayurvedic medicine which may be useful in dyslipidemia & obesity. vipul is derived from herbs only & does not contain any metal or metal compound. Its long term use has been very safe. it contains curcuma longa (haldi) terminalia chebula (haritaki), trigonella foenumgraecum (methi) & terminalia arjuna (arjun). These ingredients have been selected on the basis of ayurvedic refer more... less...
Chanakya Pharma
10, Shubhanand, Thane, Maharashtra - 400604, India
Our products are the preferred choice of many, as they are grade assured and as per international quality management systems. With our years of experience and expertise, we strive to make available high quality ayurvedic herbal medicine at competitively low prices.
Sheetal Medi-care Products Pvt. Ltd.
A-1/1 Veena Nagar, Lbs Marg Mulund (w), Maharashtra - 400080, India


text:
Clinique fans! 👄
Now through October 17th, Macy's is offering up a FREE 7-Piece Gift ($70 value!) with ANY $27 Clinique Purchase – automatically added at checkout. Plus, all beauty items qualify for FREE shipping! Check out this deal you can score…
Clinique Deal Idea:
Buy 1 Clinique Candy Store Lipstick Set $25 ($80 value)
Buy 1 Clinique Lip and Eye Pencil Sharpener $4.50
Final cost only $29.50 shipped + score a FREE 7-Piece Gift!
That's a $154.50 value for just $29.50 shipped!
(Thanks, Savings Done Simply!)


text:
Reconstructive Facial Plastic Surgery: A Problem-Solving Manual
Hilko Weerda - Reconstructive Facial Plastic Surgery: A Problem-Solving Manual
Published: 2001-11-15 | ISBN: 1588900762, 3131296410 | PDF | 148 pages | 79 MB
This practical step-by-step surgical guide to plastic and reconstructive surgery of the face was written by Professor Hilko Weerda, well-known worldwide for his auricular reconstruction techniques, and for his extensive experience in facial plastic reconstructive surgery and teaching. With more than 600 two-color drawings, the information in this book is easily accessible with a clear and compact text, and very instructive step-by-step illustrations of the various techniques. The first part of the book comprises general information, including the anatomy of the skin and skin flaps, basics of facial surgery, wound healing, instrumentation, suture material, Z-plasty, scar revisions, and defect closing techniques with standard rotation, transposition and advancement flaps. The second, more specific part deals with defect closure techniques in various regions: forehead, nasal, lips, chin, cheek, eyelids, and aurical. The most extensive chapters are devoted to the nasal and aurical regions. There is also a chapter on the harvesting of rib cartilage and specific carving techniques for aurical reconstruction, as well as three short chapters covering myocutaneous island flaps.
Buy Premium Account To Get Resumable Support & Max Speed
Links are Interchangeable - No Password
Mirror Links
Reconstructive Facial Plastic Surgery: A Problem-Solving Manual Download via Hotfile Rapidshare Fileserve Megaupload & FileSonic, Reconstructive Facial Plastic Surgery: A Problem-Solving Manual free torrent downloads included crack, serial, keygen.
Author: luixo2014


text:
General Electric J805 Tube Console Radio GE Antique
Sold for:
Start Free Trial
or Sign In to see what it's worth.
- Sold Date:
- Source: eBay
General Electric GE J805 Tube Console Radio. Radio is 40 1/2" tall 29 1/4" wide and 14 1/2" deep. Exclusive GE Dual Beam - A - Scope.The power cord is very bad, condition. It is frayed everyw and is not safe to plug in so I don't know if this radio works. The cord will have to be replace. Check out the supersize picture, you should be able to see the scratches and other damages to the radio. Pickup Only. Radio is too big to ship.


text:
Alex J. Cavanaugh that provides authors with an avenue to share their doubts and concerns (without fear of appearing foolish or weak), and to offer one another assistance and guidance. It's a safe haven for insecure writers of all kinds!
Every first Wednesday of the month we gather to connect with one another and share our insecurities.
I've been working on a story lately, one that I originally wrote as a novella, later revamped as a magazine-length short story, and am now revisiting as a novella once again. Over the course of my obsessive edits I've shifted the POV, added/removed characters, and even changed the identity of a primary character. It's an interesting exercise, and thought I'd share the opening scene from each, just to see if you, as readers, have a preference.
Three, maybe four, floors later, the elevator shudders and rocks. It groans, as if fighting against something in its way.
Kate instinctively moves away from the fat bastard to her left. She slips a tissue from inside her blouse and uses it to grab a hold of the rail. It never crosses her mind that they might get stuck, or injured in a fall. She simply doesn't want to stumble into the mountain of lard, the grubby little secretary, or the geek with the cheese stains. The guy working the door – Steve, she thought he'd said – might be worth a tumble, but she would let him come to her.
The lights flicker.
Something squeals. Mechanical at first, it gave way to an ear-piercing scream, matched by an all-too-human wail as the new guy throws himself at the doors. "No! Don't like this! Want to get—"
The lights dim. Something outside the elevator howls in protest.
Her hands are beginning to sweat. Dinner is churning uncomfortably in the greasy pit of her stomach. She seriously considers using both hands to hold on, just in case.
Bare hands, even, if need be.
The elevator comes to a sudden, jarring halt. Feet leave the floor. Bodies tumble every which way. Flesh bounces off flesh, into the walls, and off flesh again.
Fortunately, with her scant hundred and seven pounds stretched across a six-foot frame, she doesn't present much of a target. In the blind eternity of the moment, she feels somebody's arm sideswipe her breast. A stray foot glances across her polished, Italian leather pump. A metal zipper scratches the back of her hand as somebody's crotch slams into it, pinning her arm against the rail.
She loses her purse in the confusion and immediately lunges for the floor.
That is probably all that saves her from the rolling tide of flesh that washes past her head instead into it. It swamps one of the other passengers. Judging from the muffled, wordless howls coming from beneath, it is likely the nerdy little freak.
A few seconds later, and it's all over.
Kate pushes herself up off the floor. She's broken a nail – there was fifty bucks wasted – and her hair must be an absolute mess. In the dim, flickering light, she can see a streak of orange across the cuff of her jacket, and another on the back of her hand. Somebody was going to pay for this mess, and it sure as hell wasn't going to be her. The rough framework of a lawsuit is already sketching itself in the back of her mind by the time she regains her feet.
"Are you okay?" Steve looks a little worse for wear, but seems to be managing fine. There is a trickle of blood on the knuckles of his right hand, but at least he had kept his bodily fluids to himself.
"Yes. Thank you."
The girl kneeling beside her giggles. "I think we'd better help him." She actually giggled. "He may not survive for long down there."
"Ugh." Simply impossible. Kate steps back from the jumble of bodies and watches as Steve and the other girl work to free the skinny little nerd. Utterly disgusting. She doesn't have anything against physical exertion itself – she does a thousand calories on the cross-trainer every morning – but there is a time and place for everything. Sweat belonged at the fitness club. Either that, or in the sheets of a lover's bed. In either case, it certainly has no place beneath a silk blouse or a finely tailored Farczagoni suit jacket.
The lights cease their flickering, but they are certainly dimmer than before.
The elevator shuddered and rocked. It groaned, as if fighting against something in its descent. I stared at the shadowy, distorted reflections doing their best not to stare back at me from the polished steel doors. From what I could see, nobody else had noticed the irregularities of our descent.
Stephen was deliberately avoiding me. He was standing as far away as the cramped space would allow, staring at the ceiling. That was okay. He'd be forced to acknowledge me soon enough.
I had no idea who the fat bastard with the cheese-doodle stained hands was, but I figured the centre of the elevator was the best place for him, at least in terms of balance. He was muttering something to himself and chewing on his bottom lip. Oh . . . and, for some reason, he kept his back to the doors. I half expected him to pull a knife on me.
So far, he hadn't even made eye contact.
Kate, the skinny bitch in the opposite corner, I knew very well. She, as much as Stephen, was the reason I was here. The reason everything that was set to happen, had to happen. Oh, she could pretend as if she didn't have a care in the world, play the game of ignoring me, as if we hadn't met a dozen times before. She knew damn well why we were here.
We passed the nineteenth floor. I stepped casually away from them all – or as much as the cramped confines of the elevator would allow. I slipped a tissue from inside my blouse and used it to grab a hold of the rail. Between the methadone clinic, the legal aid office, and two call centers in the building, far too many unsavory people had ridden the elevator today.
The lights flickered.
Something banged.
The sound was mechanical at first. It gave way to an ear-piercing squeal, matched seconds later by an all-too-human wail.
The fat bastard was moving.
He'd noticed.
Bad timing.
He threw himself at the doors. "No! Don't like this! Want to get—"
The lights dimmed. Something outside the elevator howled in protest.
My hands were beginning to sweat. I seriously considered using both hands to hold on, just in case. Bare hands, even, if need be.
The floor fell out from under my feet. The elevator came to a sudden, jarring halt. Bodies tumbled all over. Flesh bounced off flesh, into the walls, and off flesh again. Fortunately, with my hundred and twenty-eight pounds stretched across a six foot frame, I didn't present much of a target. In the blind eternity of the moment, I felt somebody's arm sideswipe my breast. A stray foot glanced across my polished, black leather pumps. A metal zipper scratched the back of my hand as somebody's crotch slammed into it, pinning my wrist awkwardly against the rail.
I lost my purse in the confusion and immediately lunged for the floor.
That was probably all that saved me from the rolling tide of flesh that rolled over my head. Instead of dragging me under, it swamped one of the other passengers. Judging from the muffled, wordless howls coming from beneath, it was likely Kate.
I really hoped it was Kate.
A few seconds later, and it was over.
"Damn." I pushed myself up off the floor. I'd broken a nail – there was fifty bucks wasted. My hair must have been an absolute mess. In the dim, flickering light, I could see a streak of powdered cheese across the cuff of my jacket, and another on the back of my hand.
"Are you okay?" Stephen looked a little worse for wear, but seemed to be managing fine. There was a trickle of blood on the knuckles of his right hand, but at least he'd kept his bodily fluids to himself. He still was doing his best not to look at me, though.
"Yes." I spat the words out. "No thanks to you."
The lights ceased their flickering, but they were certainly dimmer than before.


text:
After 18 years, an all-new Dragon Ball TV anime series was announced. Titled "Dragon Ball Super" this series takes place a few years after the end of the Majin Buu Saga. Aside that the series takes place years after the end of the Majin Buu Saga, ...
- The Fandom PostToei Animation Begins Production on 'Dragon Ball Super' TV Anime Series
- Kotaku EastDragon Ball Is Getting Its First New TV Anime in 18 Years
- CrunchyrollToei Animation Begins Production on "Dragon Ball Super" TV Anime
- Anime News NetworkDragon Ball Gets 1st New TV Anime in 18 Years in July
- moetron"Dragon Ball Super" - New Dragonball TV Series Announced for July


text: Section: Parts Title: 100/S4/200 Wiper stalk switch Price: 0.00 Location: Rochester, MN Date: December 09, 2005 Contact: Brad Larson Email: bradlarz at hotmail.com Phone: (507) 398-5980 Description: NO PICTURES. Looking for a wiper stalk switch for a project. It needs to be from a '92 S4 or 100 with the trip computer. The one I'm looking for has a +/- and a reset button. Thanks URL: http://www.audifans.com/marketplace/show.php?table=pm_audifans_Parts&id=2506 -- [ This is an automated message ] [ You are receiving this message ] [ because you signed up for the ] [ Marketplace email notification. ]


text:
Results 1 to 1 of 1
Vibhuti Thakur in Colors Code RedFollow us on Social Media
Follow @iamdesirulez
Tweet #iamdesirulez
Actress Vibhuti Thakur will join the Colors Code Red team with an interesting episodic story to tell.. Vibhuti who was recently seen essaying Samrats bhabhi in Doli Armaanon Ki will be part of Code Red Awaazs message provoking tale on eunuchs.
She will play the role of a mother to a seven year old kid. The story will be very unique in which every woman will feel the pain of the mother. The story will be produced by Sunshine Rise Productions.
When contacted, Vibhuti told us, I will not be able to divulge the story line. All I can say is that this will be an emotional tale of a mother. I am sure audience will cry seeing my performance.
The episode featuring Vibhuti will air very soon.


text:
These balance body alignment basics could be exactly what I have actually felt over the last few years the principles crafted in such a way that both body/mind as well as technological wholesomeness that must be within my balanced body movement framework.
Our balance body alignment muscle mass play essentially various "Floating Bones" roles. by meticulously noting ourselves as well as nature, it is possible to realize a different metaphor: drifting compression. There is a radiance to our bodies that is mostly unexplored body/mind self-controls are a systemic ways of discovering the world of floating compression that in some way, oddly, we have actually failed to remember the pattern of movement that purposefully changes the tension in our physical bodies is a body/mind discipline. a skeletal system is made use of to represent our musculoskeletal framework, however does not have any sort of tensile aspects.
We understand we can educate at the health club for toughness or aerobic capability; we could also train for flexibleness. All 3 kinds of training are corresponding. In particular, springiness training will provide you resiliency to injury, much less pain, and also help with recuperation from all your training. Several kinds of "spring training" could be done anywhere.
Much exercise highlights the superficial levels; body/mind generally utilizes all levels. As a whole, more recognition of your body enables you to engage much deeper balance body alignment layers all the time and so to loosen up the superficials. When we know a truth, we understand it in our bones. In the medical professional's office, the version of our framework is the bones. There are none of the soft tissues– muscular tissues, tendons, and ligaments– in those doctor's versions. Why don't we ever before recognize it in our tendons?
Floating Bones is an etymological little bit of floating-based images. Seeing drifting compression designs adds a dimension to the understanding. Touching as well as having fun with them builds one more. Conversing with the version includes an additional level of richness to the drifting designs. That's why I suggest obtaining a version. We are constantly utilizing some sort of imagery to regulate our physical bodies; that imagery is either compression-based or floating-based.
Flexibility is our best strength, yet it's additionally our biggest weak point. We equate our adaptations to the truth– specifically for adaptations that took place a very long time ago or that we practice frequently. I use the word oddly due to the fact that most of us understood how you can relocate with spring and so resiliency when we were kids. The tensions that hold our misalignments in position are invisible to us. If we knew that the stress existed, we 'd most likely release them on our own. This speaks to the value of visiting classes or functioning individually with body/mind specialists.
You might also want to view a different cut on this from the presentation that I provided at Ignite Phoenix. To see that discussion, click that link, then click on "Drifting Bones" in the ideal pillar. These are well-crafted I keep discovering new points when I examine balance body alignment…


text:
Time To Change That Wallpaper: 2015 Geneva Motor Show EditionInsights
Now that the dust has settled at the 2015 Geneva Motor Show, we take a look back at some of the most exciting and exotic machinery that have made their debuts and will be put into production. Each one of these pieces of machinery has a certain appeal about them be it their unique and attractive looks or impressive engineering details and we feel they should be put on display.
And the best way to have them on display? By placing them right on your very desktop PC or laptop of course! So we've picked out a few wallpapers to adorn your screens with and here they are in no particular order (click to expand):
*All wallpapers are at 1920x1080 resolution
Koenigsegg Agera RS
Lamborghini Aventador LP750-4 Superveloce
Honda NSX
Related Tags


text:
French unions have lost many of their traditional allies in parliament after Sunday's parliamentary election result, but President
The size of his majority — already assured according to official figures and set to be over 350 seats in the 577 seat lower house according to projections — means Macron and his year-old centrist party can now count on lawmakers to give his government powers to wave the reform through without lengthy negotiations in parliament.
He has routed the left, yet he needs to handle France's muscular unions with care.
At stake is not only the injection of flexibility into the labor market he has promised. The way he handles his labor reforms will also set the tone for more reforms in the coming years, including a revamp of jobless benefits and retirement systems.
Though uneasy about Macron's program and fearful that it is being rushed, most unions are relieved his government has so far been careful to consult closely with them, and that it has promised to come up with detailed proposals in the coming weeks.
The question now is whether he will keep taking their input on board, said Jean-Claude Mailly, head of France's third biggest union, Force Ouvriere (FO).
"Is he going to say, 'you don't agree, well, I'm going to push (the reform) through by force'?," Mailly asked in an interview with Reuters.
"If so, one thing's for sure, his presidency is going to get off to a bad start on labour relations and there will be tensions," he added.
Even France's most reform-friendly and biggest private-sector union, the CFDT, refuses to rule out protests if its counter-proposals are ignored.
"We reserve the possibility like everyone to give our point of view democratically. If we have to hold protests, we will. If we have to mobilize in companies, we'll do it," CFDT head Laurent Berger told Reuters in an interview.


text:
• Three-time all-district pitcher at Central High School; led the Wildcats to the 2017 state championship
• 2017 Baton Rouge Metro Player of the Year
• 2017 first-team all-state and all-metro selection
• Participated in the 2017 Louisiana High School Athletic Association All-Star game
Paul Mainieri on Ma'Khail Hilliard:
"We have watched Ma'Khail for a few years as he is a local guy and he capped off his high school career by leading Central High School to the state championship this past May. The things that stood out to me when I first saw him pitch were his loose arm action with a very good 12-to-6 curveball that displayed a lot of bite to it. He also has a good downhill angle with his fastball because of his overhand delivery. He sits in the upper 80s, touches the low 90s, and we expect those numbers to get higher as his athletic body develops."


text:
Describe the significance of a "physical journey" in The Kite Runner.
- print Print
- list Cite
The need for Amir to "become good again" is rooted in the idea of a physical journey in which he is able to reclaim his redemption as a human being. The physical journey is one in which psychology is heavily impacted by physicality. Amir had settled in America and, to an extent, severed the bonds that connected him to Afghanistan. However, as evident in the very first chapter, the keys to his own spiritual redemption resided in Afghanistan. In this, the physical journey becomes the means by which individuals are able to embrace their own senses of self and identity. The physical journey is one filled with challenges and a sense of danger, evidenced in the confrontation with Assef as well as the troubles with adopting Sohrab. These difficulties are necessary for Amir to "be good again." In doing so, the physical journey becomes the means by which Amir's spiritual redemption is possible. Without it, there is little in which Amir can do to address his own transgressions of the past. This makes the physical journey a portal to the past as well as the present, and thus, the future conception of the individual.