Language and compiler for generating synchronous digital circuits that maintain the order of thread execution

Abstract

A multithreaded programming language and compiler generate synchronous digital circuits that maintain thread execution order by generating a pipeline of code paths with the same number of stages. The compiler balances dependent code paths within the pipeline by adding additional stages to code paths with fewer stages. By design, programming constructs that allow thread execution to be reordered can be placed in a reordering block construct that releases the threads in the order in which they entered the programming construct. A first-in-first-out (FIFO) queue passes local variables between pipelines. Local variables are popped from the FIFO in the order in which they were pushed, preserving thread execution order across pipelines.

Description

Background Art

[0001] A hardware description language ("HDL") is a modeling language used by hardware engineers to describe the structure and behavior of electronic circuits, most of which are typically digital logic circuits. Examples of HDLs include Very High Speed ​​Integrated Circuit ("VHSIC") HDL and VERILOG.

[0002] HDL typically requires many lines of code to simulate digital logic circuits. Creating this code is very time-consuming, even for hardware engineers who are very familiar with HDL. Furthermore, the more lines of code a design has, the more likely it is to contain errors or perform poorly.

[0003] Because HDLs typically utilize a different programming paradigm than imperative programming languages, software engineers who are not very familiar with HDLs often have difficulty utilizing these languages. As a result, electronic circuits created by software engineers that are generated from HDLs may also include errors or perform poorly.

[0004] Presented herein are responses to these and other technical challenges made by the present disclosure. Summary of the Invention

[0005] Techniques for generating languages ​​and compilers for synchronous digital circuits that maintain thread execution order are disclosed. By implementing the disclosed techniques, hardware engineers can achieve significant productivity gains by reducing the number of lines of code required to implement some types of circuit designs and by eliminating entire classes of common design errors, without sacrificing performance. For software engineers with little or no experience designing circuits using HDLs, the disclosed techniques provide familiar programming semantics that can be used to generate high-performance circuit designs.

[0006] Implementations of the disclosed technology can also generate hardware circuits that can maintain thread execution order. Maintaining thread execution order allows optimizations such as low-overhead thread synchronization. Maintaining thread execution order also allows programmers to perform sequence-specific operations. For example, in the entire program, threads with even execution orders (such as threads "2", "4", "6" ...) may be processed differently from threads with odd execution orders. In addition, special operations can be performed when a thread is the first thread or the last thread to be executed. Other technical advantages not specifically mentioned herein can also be achieved through implementation of the disclosed subject matter.

[0007] To achieve the technical advantages briefly mentioned above, the disclosed language and compiler generate pipelines with code paths that have the same number of stages. For example, all code paths for a first pipeline might have 6 stages, while all code paths for a second pipeline might have 15 stages. To maintain this property, the compiler balances the related code paths within the pipelines. For example, for a given 'if' statement, either the 'then' block or the 'else' block can be padded so as to have the same number of stages as the other block. Stages can be added by adding dummy stages that do not perform useful work, or stages can be added by increasing the pipeline depth - that is, increasing the number of stages used to implement the block. By balancing the number of stages in the 'then' and 'else' blocks, all threads execute the 'if' statement in the same number of clock cycles, so the threads leave the 'if' statement in the order they entered.

[0008] Some programming constructs allow for reordering of thread execution by design. For example, for loops, thread execution order cannot be guaranteed because different threads may execute different numbers of loops. Thus, one thread may complete a loop in 10 iterations, while another thread may complete the same loop in 500 iterations. However, the disclosed language includes a reorder block that ensures that threads leave the reorder block in the order they entered the reorder block. Programmers can wrap loops and other non-order-preserving constructs with reorder blocks to maintain thread execution order. Alternatively or in addition, the disclosed language can include loop constructs with "built-in" reorder block functionality. For example, a "reorder_for" loop operates as a "for" loop that preserves thread execution order. In some configurations, the reorder block is implemented via a reorder buffer on the SDC.

[0009] In some configurations, execution pipelines are connected via first-in, first-out queues (called 'queues' or 'FIFOs'), which store local variables for use by another pipeline. FIFOs can be used to implement function calls, control flow, and other aspects of the disclosed language. Thread order is maintained across pipelines by retrieving local variables from the FIFOs in the order they were enqueued.

[0010] As briefly discussed above, implementation of the techniques disclosed herein provides low-overhead thread synchronization. Further, it enables programmers to perform sequence-specific operations, such as treating odd and even threads differently, or performing special operations for the first or last thread. Other technical benefits not explicitly identified herein may also be realized by implementing the disclosed techniques.

[0011] It should be understood that the above subject matter can be implemented as a computer-controlled apparatus, a computer-implemented method, a computing device, or an article of manufacture such as a product of a computer-readable medium. These and various other features will be apparent by reading the following detailed description and viewing the associated drawings.

[0012] This summary is provided to introduce in simplified form a brief description of some aspects of the disclosed technology that will be further described in the following specific implementations. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended that this summary be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a computational architecture diagram illustrating aspects of a system disclosed herein for generating a synchronous digital circuit based on program source code including programming constructs mapped to the synchronous digital circuit;

[0014] Figure 2 is a hardware architecture diagram showing aspects of an illustrative example synchronous digital circuit including a plurality of hardware pipelines, each having a plurality of pipeline stages, and a computational unit that may be defined and implemented using the disclosed techniques;

[0015] Figure 3 is a hardware architecture diagram illustrating the mapping of functions written in the disclosed language to hardware circuits;

[0016] Figure 4 is a hardware architecture diagram illustrating a fill code path of a pipeline with dummy stages;

[0017] Figure 5 A hardware architecture diagram showing a reordering block construct applied to a for loop;

[0018] Figure 6 is a flow chart showing a routine illustrating maintaining a reference Figure 1-Figure 5 Aspects of the language and compiler operation that describe thread execution order;

[0019] Figure 7 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computing device that may implement aspects of the techniques presented herein; and

[0020] Figure 8 is a network diagram illustrating a distributed computing environment in which aspects of the disclosed technology may be implemented. DETAILED DESCRIPTION

[0021] The following detailed description relates to languages ​​and compilers that maintain thread execution order. As briefly discussed above, maintaining thread execution order allows for optimizations such as low-overhead thread synchronization. Maintaining thread execution order also allows programmers to implement order-specific operations. For example, threads in even-numbered execution order may be treated differently than threads in odd-numbered execution order throughout a program. Furthermore, special operations may be performed when a thread is the first or last thread to be executed. Other technical advantages not specifically mentioned herein may also be realized through implementation of the disclosed subject matter.

[0022] Although the subject matter described herein is presented in the general context of languages ​​and compilers that maintain thread execution order, those skilled in the art will appreciate that other implementations may be performed in conjunction with other types of computing systems and modules. Those skilled in the art will also appreciate that the subject matter described herein may be practiced using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, computing or processing systems embedded in devices (such as wearable computing devices, automobiles, home automation, etc.), minicomputers, mainframe computers, and the like.

[0023] In the following detailed description, reference is made to the accompanying drawings which form a part hereof and which are shown by way of illustration of specific configurations or examples. Referring now to the drawings, in which like numerals represent like elements throughout the several views, aspects of a language and compiler that maintain thread execution order will be described.

[0024] Figure 1 is a computational architecture diagram showing aspects of an illustrative system 100 disclosed herein for defining and generating a synchronous digital circuit ("SDC") 112 based on program source code 102 that includes programming constructs that map to the SDC 112. The SDC can be implemented by gate arrays, field programmable gate arrays ("FPGAs"), application specific integrated circuits ("ASICs"), and other types of circuit devices. Although the disclosed subject matter is primarily described in the context of an SDC 112 implemented in an FPGA, it should be understood that the techniques disclosed herein can be utilized to define an SDC 112 implemented using other types of devices.

[0025] like Figure 1 As shown, the illustrative system 100 includes a compiler 104 that compiles program source code 102 to generate hardware description language ("HDL") code, or a low-level representation of a circuit (such as a netlist). As briefly discussed above, HDL is a modeling language used by hardware engineers to describe the structure and behavior of electronic circuits, most of which are typically digital logic circuits. Examples of HDLs include VHSIC HDL and VERILOG.

[0026] As will be described in detail below, the program source code 102 is expressed using a multi-threaded imperative programming language designed to target the SDC 112. The disclosed language provides many features of languages ​​such as C and JAVA, such as function calls, for-loops, arithmetic operators, and conditional statements. However, the disclosed language includes constructs that map directly to the underlying SDC 112 hardware implementation. This enables both hardware and software engineers to reason about performance and is efficient in optimizing their designs. As described above, this also allows software engineers to become familiar with the language and relieves hardware engineers from having to deal with various types of errors that occur when coding in HDL.

[0027] The disclosed multithreaded imperative programming language is imperative because program statements are executed sequentially, and multithreaded because multiple execution threads can be executed in parallel. As described above, a thread is a collection of local variables. A thread is executed while the hardware circuit processes the local variables.

[0028] The threads described herein are similar to, but distinct from, software threads. While software threads maintain a call stack containing local variables and execute code in memory, threads described herein are collections of local variables that are moved through hardware circuitry. While software threads have a location in the executable code determined by an instruction pointer, the disclosed threads have a physical location on the SDC at a given point in time. An SDC can execute hundreds, thousands, or even millions of threads, and SDC execution can be pipelined, meaning that different threads can execute simultaneously within different stages of the circuitry.

[0029] As will be described in more detail below, language constructs can be defined in program source code 102 that is mapped to a circuit implementation. A language construct is a syntactically permitted portion of a program that can be formed from one or more lexical tokens. The language constructs described herein are mapped to a circuit implementation that guarantees thread ordering (i.e., threads will exit the circuit implementation in the same order they entered).

[0030] As will be described in more detail below, the circuit implementation generated by the configuration disclosed herein can be implemented as an SDC in an FPGA, a gate array, an ASIC, or another type of suitable device. Another hardware component such as a NIC can be configured with an FPGA, a gate array, or an ASIC to implement the desired functionality.

[0031] like Figure 1As shown, a compiler 104 can compile program source code 102, including one or more of the language constructs disclosed herein, into a circuit description, in this example, HDL code 106. The HDL code 106 can be provided to an HDL synthesis tool 108, which in turn can generate a bitstream 110 that can be used to program an SDC 112, such as on an FPGA. When targeting an ASIC, the HDL code 106 can be provided to an ASIC manufacturer for production in a factory.

[0032] Figure 2 1 is a hardware architecture diagram showing aspects of an illustrative example SDC 112 that includes a plurality of hardware pipelines 200A-200C (or "pipelines") that can be defined and implemented using the disclosed techniques. Each hardware pipeline has a plurality of pipeline stages 206, each pipeline stage 206 having a computation unit 208. Figure 2 As shown, program source code 102 may be compiled into pipeline 200A- 200C of hardware compute unit 208 .

[0033] Pipelines 200A-200C may be connected by a first-in, first-out ("FIFO") queue (also referred to herein as "FIFOs" or "queues"). Pipelines 200A-200C implement functionality defined by program source code 102. FIFO 202 stores data values, provides input to pipelines 200, and stores output generated by pipelines 200. For example, SDC 112 includes pipeline 200A that feeds its output to FIFO 202A. Pipeline 200B, in turn, takes its input from FIFO 202A and provides its output to FIFO 202B. Pipeline 200C takes its input from FIFO 202B.

[0034] In some configurations, pipeline 200 implements policy circuitry 210 that determines when to retrieve the next value(s) from FIFO 202. For example, policy circuitry 210 may require that an input FIFO (e.g., FIFO 202A in the case of pipeline 200B) is not empty and an output FIFO (e.g., FIFO 202B) is not full before retrieving a value from the input FIFO (e.g., FIFO 202A) for processing.

[0035] like Figure 2As shown, pipeline 200 may be composed of one or more pipeline stages 206A-206B. Execution is pipelined by concurrently executing different threads in different stages 206 of pipeline 200. The results of a stage may be stored in register 204 and provided to the next stage 206 for the duration of the next clock cycle.

[0036] Each pipeline stage 206 may include one or more computational units 208B, such as an adder 208A and a lookup table ("LUT") 208B. In the illustrated example, the adder 208A may perform basic operations such as addition, subtraction, and multiplication. The computational units may also implement Boolean operators (e.g., "OR," "NOR," "XOR," etc.) or other custom logic provided by the SDC manufacturer.

[0037] The computation unit can also be implemented by a user-programmable lookup table 208B. The illustrated LUT 208B depicts a two-input truth table that maps two input bits to a single output bit. The LUT 208B can be configured to support different numbers of input bits. To generate more complex output values, such as characters or 8-bit integers, multiple LUTs 208B can be used, each connected to a different bit of the input variable.

[0038] A computation unit may temporarily store a result in a register 204 (or "flip-flop"). The contents of such a register may be provided to other computation units in the same or different pipelines 200. Register 204 may capture the value at its input when the connected digital clock transitions from 0 to 1, and provide that value at its output until the end of the next clock cycle (i.e., until the clock transitions from 0 to 1 again). The register may also include an enable line. If the enable line is set to false, the register will not perform the above operations, maintaining the current output value over multiple clock cycles.

[0039] It should be understood that for the purposes of this discussion, Figure 2 The pipeline architecture shown in has been simplified. The programming language constructs described herein can be utilized to implement more complex SDC 112 having more than Figure 2 More components shown.

[0040] Figure 330 is a hardware architecture diagram illustrating the mapping of functions written in the disclosed language to hardware circuitry according to one implementation example. Program source code 302 includes a function 'f()' 304 written in the disclosed language. The disclosed language is imperative in that program statements are executed sequentially, and multithreaded in that multiple threads of execution can execute in parallel and / or concurrently. Function 'f()' 304 takes two parameters: 'x' 306 and 'y' 308 and returns an integer. Function 'f()' has two expressions: expression 310 performs an addition and stores the result in a local variable 'z', while expression 312 returns the result of a multiplication.

[0041] Function 'f()' 304 is mapped to hardware circuit 314, which includes computation units 316 and 318, registers 320 and 322. Hardware circuit 314 has two stages—a first stage 324 that performs the addition described in expression 310 and a second stage 326 that performs the multiplication described in expression 312. Each stage is executed in a single clock cycle, and the result of each stage is stored in one or more registers.

[0042] Continuing with this example, stage 324 performs a "+1" operation on parameter 'x' 306, storing the result ('z') in register 322. During stage 324, parameter 'y' 308 is provided directly to register 320. During stage 326, computation unit 318 multiplies the values ​​of 'y' and 'z'. The result is stored in register 328.

[0043] Hardware circuit 314 may be executed by threads 330, of which only some are depicted. An SDC may execute hundreds, thousands, or millions of threads. A thread refers to a collection of local variables. A thread is executed when a local variable is processed by a hardware circuit. For example, thread 330A has a value 332 (x=1 and y=2), and thread 330A executes function 'f()' 304 when value 332 is processed by hardware circuit 314. The value returned by the function may be added to the local variable set, and at any time, if it is known that a particular variable will no longer be used by the hardware circuit, the variable may be removed from the local variable set.

[0044] The disclosed thread is similar to, but distinct from, a software thread. While a software thread maintains a call stack containing local variables and executes code in memory, a disclosed thread is a collection of local variables that moves through hardware circuitry. While a software thread has a location in the executable code determined by an instruction pointer, a disclosed thread has a physical location on the SDC at a given point in time.

[0045] SDC execution can be pipelined—that is, different threads can execute simultaneously within different stages of the circuit. Table 334 depicts variables from different threads at different stages as pipelined execution of hardware circuit 314 occurs. Column 336 shows the values ​​stored between (i.e., before and after) stages: 336A contains the values ​​of x and y provided by threads 330A, 330B, and 330C, while column 336B contains the values ​​after stage 324 has been executed, and column 336C contains the values ​​after stage 326 has been executed. Rows 338A-C show the values ​​stored after successive clock cycles.

[0046] For example, row 338A indicates that thread 330A is about to enter hardware circuit 314 with value 332A (x=1 and y=2). Between rows 338A and 338B, a clock cycle occurs, and the result of executing thread 330A in stage 324 is depicted in 332B (y=2, the hold from 332A, and z=2, the result of the "+1" operation). Simultaneously, value 340A (x=3 and y=5) from thread 330B is about to enter hardware circuit 314. Between rows 338B and 338C, another clock cycle occurs, and the result of thread 330A executing stage 326 is depicted in 332C ("4"). Simultaneously, the result of thread 330B executing stage 324 is depicted in 340B (y=5 and z=4), and value 342 from thread 330C is about to enter hardware circuit 314 (x=7 and y=1). Pipelined Execution Pipelined execution enables higher throughput by increasing SDC utilization—that is, more SDCs are performing useful work at a given point in time than if only one thread could execute hardware circuit 305 at a time.

[0047] Figure 4 4 is a hardware architecture diagram 400 showing a padded code path of a pipeline with dummy stages so that all paths of the pipeline have the same number of stages. Having the same number of stages ensures that thread execution order is maintained through the pipeline. In some configurations, code listing 402 includes a function 'f()' 404 that accepts two parameters, int 'x' 406 and int 'y' 408. Line 410 adds '1' to 'x' and assigns a value to 'z'. Line 410 adds '1' to 'x' and assigns a value to 'z', which is described in circuit description 418 as computation unit 420 adding '1' to 'x' and storing the result in register 422.

[0048] Line 411 introduces an 'if' statement under the condition 'z>2'. In some configurations, branching statements like 'if' statements are implemented by executing both branches in parallel and selecting the result to process based on the condition. The corresponding component in circuit illustration 418 is multiplexer 424, which causes the thread to continue processing the value produced by code path 427 if 'z' is greater than '2', and otherwise causes the thread to continue processing the value produced by code path 435 (N).

[0049] Code block 412 (the 'then' block) includes two statements. "y = y + 3" corresponds to calculation unit 428, which adds '3' to the value of 'y' 408. The result is stored in register 430, which the compiler understands contains the correct value for 'y', replacing the value passed in as a parameter. The next statement, "y = y * 2," is implemented by calculation unit 432, which multiplies the value of 'y' stored in register 430 by '2' and provides the result to multiplexer 424. If the value of 'z' is greater than '2', the value provided by calculation unit 432 is provided to register 434.

[0050] Code block 414 (the 'else' block) includes a single statement, "y=y-1." This statement is implemented by calculation unit 436, which subtracts '1' from 'y' 408 and stores the result in register 438. However, in the next clock cycle, virtual calculation unit 440 forwards the value stored in register 438 to multiplexer 424, which provides the value stored in register 438 to register 434 if the value of 'z' is less than or equal to '2.' This virtual calculation unit 400 is added to balance the number of stages in code path 427. In some configurations, register 438 is added to maintain the value of 'y' for virtual calculation unit 440.

[0051] In some configurations, the number of virtual computation units added to a given code path is equal to the number of stages in the longest code path minus the number of stages in the given code path. In this case, the maximum number of stages is two—computation units 428 and 432—and code path 435 has one stage 436. Therefore, only one computation unit 435 is added, resulting in the creation of a new pipeline stage.

[0052] In some implementations, instead of inserting computational units that perform no useful work (besides balancing branches), values ​​are simply stored in registers at the end of each clock cycle. In some implementations, instead of adding dummy stages, the compiler generates a deeper pipeline, i.e., a code path with more stages than would normally be created. This may reduce the average execution time of a stage because the computation is spread across more stages.

[0053] Line 416 includes a single statement "return z*y" which multiplies the value of 'y' by the value of 'z' before returning. This corresponds to calculation unit 444 which multiplies the value of 'y' stored in register 434 by the value of 'z'.

[0054] Figure 5 5 is a hardware architecture diagram 500 showing a reordered block construction around a "do-while" loop. Code listing 502 includes a function 'f()' that takes parameters 'x' 506 and 'y' 508. Line 512 initializes int 'z' to 'x+1' and corresponds to a portion of execution pipeline 522. Specifically, execution pipeline 522 includes a "+1" calculation unit 534 that adds '1' to the value of 'x' 506 and stores it to register 535 as 'z'. Line 513 initializes the loop counter variable 'i' to '1'. Pipeline 522 ends by pushing the values ​​'i', 'y', and 'z' into FIFO 524.

[0055] The reordered block of function 504 wraps a “do-while” loop 518 . Figure 5 A "do-while" loop 518 is used as an example of a language construct that, by design, does not preserve thread execution order. However, other language constructs that do not preserve thread execution order are similarly contemplated. Reorder block 516 is implemented in part by pipeline 522 and pipeline 526. Pipeline 522 includes a start reorder block 536 that registers threads in the order they enter.

[0056] In some configurations, threads are associated with indexes or thread IDs. The index / ID of the first thread to enter the start reorder block 536 will be stored in the first position of the reorder block, such as element '0' of an array. Subsequent threads will have their indexes / IDs stored in the elements corresponding to the order in which they entered. In this way, a record of the order in which the threads executed is created. The discussion of the reorder block 516 continues after the discussion of the "do-while" loop 518.

[0057] The "do-while" loop 518 loops 'z' times, adding '2' to 'y' each time. The "do-while" loop is implemented by pipeline 526, some aspects of which have been omitted for clarity. The "do-while" loop initially receives the value of 'z' placed in FIFO 524 by pipeline 522. The "do-while" loop 518 can then compare the value of 'i' to 'z' in block 538. If 'i' is less than or equal to 'z', the loop continues and the calculation unit 540 adds '2' to 'y'. The updated value of 'y', the value of 'z' and the current value of 'i' can then be stored in FIFO 528. However, if 'i' is greater than 'z', the loop ends and execution passes to reorder block 542, described below.

[0058] After the initial execution, the "do-while" loop 518 continues to iterate another 'z-1' times. At each iteration, the current values ​​of 'y' and 'i' are retrieved from FIFO 528 along with the value of 'z'. It should be understood that at this point 'x' is not maintained because it is not used in the remainder of the function. A comparison 538 is performed, and if 'i' is still less than 'z', execution continues to calculation unit 540 as described above. However, if 'i' is greater than 'z', the "do-while" loop 518 ends.

[0059] When the thread exits the "do-while" "do-while" loop 518, it passes through the end reorder block 542. Although the start reorder block 536 and the end reorder block 542 are described separately, they can be implemented by a single functional unit on the SDC. The end reorder block 542 blocks the thread until all threads with lower execution orders (i.e., threads registered in lower numbered elements in the array of thread indices / IDs) have been released. When the thread with the lowest execution order is encountered, it is immediately released to continue execution. In this way, the threads are freed to begin other computations in the order in which they entered the reorder block 516. The pipeline 526 ends by storing the values ​​of 'z' and 'y' in the FIFO 530.

[0060] Line 520 is executed after the "do-while" loop 518 and the reorder block 516 has completed, returning the value of "z*y". Line 520 is partially implemented by pipeline 532, which reads the values ​​of 'y' and 'z' from FIFIO 530 and applies computation unit 543 to multiply 'y' and 'z'.

[0061] Figure 5Depicts how the thread order is changed by executing a "do-while" loop and then restored to the original order by a thread reordering block. Threads 546A-D enter a loop, such as a "do-while" "do-while" loop 518, in order 548. Each thread has a different value for 'z' 544, and therefore each thread executes a different number of iterations of the "do-while" loop 518. Specifically, the first thread 546A to enter will iterate six times, the second thread 546B to enter will iterate eight times, the third thread 546C to enter will iterate two times, and the fourth thread 546D to enter will iterate four times. Threads 546 pass through the start reordering block 536 to register their thread index / ID in the order they entered. Graph 550 indicates how long each thread executes in clock cycles. Threads 546 exit the "do-while" loop 518 in different orders—thread 546A exits third, thread 546B exits fourth, thread 546B exits first, and thread 546A exits second.

[0062] Although thread 546C is the first to exit "do-while" loop 518, end reordering block 542 delays further execution until threads 546A and 546B have completed "do-while" loop 518 and resumed execution. Next, thread 546D completes "do-while" loop 518 and is also blocked until threads 546A-C complete. Next, thread 546A completes "do-while" loop 518, but because 546A is the first thread registered with start reordering block 536, it is allowed to resume. Simultaneously, end reordering block 542 checks whether any subsequent threads are allowed to continue now that thread 546A has resumed. In this case, no subsequent threads are allowed to continue because thread 546B has not yet completed. However, once thread 546B completes "do-while" loop 518, end reordering block 542 notices that all threads with a lower initial execution order (i.e., thread 546A) have resumed execution, and therefore thread 546B is allowed to resume execution. Next, the threads that enter the start reorder block 536 after thread 546B are checked to determine whether they are allowed to restart. In this example, threads 546C and 546D are both blocked, so they are both allowed to restart (in that order) because all threads that arrived before them have already been allowed to restart. In this way, threads 546 exit the end reorder block 542 in the order 554, that is, in the same order in which they entered the start reorder block 536. Figure 4 and Figure 5and corresponding discussions depict non-limiting examples. Other types of loops, pipelining, expressions, branches, and sequencing are similarly contemplated.

[0063] Figure 6 is a flow chart of a routine 600 according to an implementation example disclosed herein, which illustrates Figure 1-Figure 5 It should be understood that the language and compiler aspects described herein regarding maintaining thread execution order are not Figure 6 The logical operations of the and other figures may be implemented (1) as a sequence of computer-implemented acts or program modules running on a computing device and / or (2) as interconnected machine logic circuits or circuit modules within a computing device.

[0064] The specific implementation of the technology disclosed herein is a matter of choice depending on the performance and other requirements of the computing device. Therefore, the logical operations described herein are variously referred to as states, operations, structural devices, actions, or modules. These states, operations, structural devices, actions, and modules can be implemented with hardware, software, firmware, dedicated digital logic, and any combination thereof. It should be understood that more or less operations than those shown in the figures and described herein can be performed. These operations can also be performed in an order different from those described herein.

[0065] Routine 600 begins at operation 602, where source code 102 is received by compiler 104. The source code may be expressed in a multi-threaded programming language. In some configurations, source code 102 is expressed in an imperative programming language. The source code may include branch statements 411, such as 'if', 'switch', 'case', or 'while' statements, which cause a thread to execute along one of a plurality of code paths (also referred to as "source code paths" to distinguish them from code paths described in circuits). In some configurations, the source code includes a reordering block 516 that encloses code that does not maintain thread execution order, such as a "do-while" loop 518.

[0066] From operation 602, the routine proceeds to operation 604, where the compiler 104 compiles the source code 102 into the circuit description 106. In some configurations, the circuit description 106 includes multiple code paths 427 and 435 associated with multiple source code paths, and the compiler 104 adds dummy pipeline stages 400 to some or all of the multiple code paths such that some or all of the multiple code paths have the same number of pipeline stages 324.

[0067] In some configurations, the circuit description includes a first execution pipeline 200A and a second execution pipeline 200B, and the first execution pipeline 200A switches execution to the second execution pipeline 200B by pushing the local variable sets into the FIFO 202A. The second execution pipeline can then retrieve the local variable sets from the FIFO 202A in the order in which the local variable sets were pushed into the FIFO 202A, thereby maintaining thread execution order.

[0068] In some configurations, the circuit description 521 includes reorder buffers 536, 542 that wrap circuit descriptions of constructs 518 that do not maintain thread execution order. In these configurations, the reorder buffers 536, 542 register the thread order 548 before the construct is executed and return the threads to the original execution order 548 upon leaving the construct. In some configurations, the reorder buffers 536, 542 prevent thread execution until all threads with a lower execution order (i.e., closer to the first thread to be executed) have resumed execution.

[0069] From operation 604, the routine proceeds to operation 606, where the circuit description (eg, HDL code) is used to generate SDL 112, which includes the circuit implementation defined by the circuit description 106. The routine 600 then proceeds from operation 606 to operation 608, where it ends.

[0070] Figure 7 is a computer architecture diagram showing an illustrative computer hardware and software architecture for a computing device that can implement aspects of the technology presented herein. In particular, Figure 7 The architecture illustrated in the can be used to implement a server computer, a mobile phone, an e-reader, a smartphone, a desktop computer, an AR / VR device, a tablet computer, a laptop computer, or another type of computing device.

[0071] Figure 7 The illustrated computer 700 includes a central processing unit 702 ("CPU"), system memory 704 including random access memory 706 ("RAM") and read-only memory 708 ("ROM"), and a system bus 710 that couples memory 704 to CPU 702. A basic input / output system ("BIOS" or "firmware"), containing the basic routines that help to transfer information between components within the computer 900, such as during startup, may be stored in ROM 708. The computer 700 also includes a mass storage device 712 for storing an operating system 722, application programs, and other types of programs. The mass storage device 712 may also be configured to store other types of programs and data.

[0072] The mass storage device 712 is connected to the CPU 702 through a mass storage controller (not shown) connected to the bus 710. The mass storage device 712 and its associated computer-readable media provide non-volatile memory for the computer 700. Although the descriptions of computer-readable media contained herein refer to mass storage devices, such as a hard disk, a CD-ROM drive, a DVD-ROM drive, or a USB memory key, those skilled in the art will understand that computer-readable media can be any available computer storage media or communication media that can be accessed by the computer 700.

[0073] Communication media includes computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any delivery medium. The term "modulated data signal" refers to a signal that has one or more of its characteristics changed or set in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct wired connection, and wireless media such as acoustic, radio frequency, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.

[0074] By way of example, and not limitation, computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. For example, computer storage media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, digital versatile disks ("DVD"), HD-DVD, Blu-ray or other optical storage, cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computer 700. For purposes of the claims, the term "computer storage media," and its corresponding variations, does not include waves or signals themselves or communications media.

[0075] According to various configurations, the computer 700 can operate in a networked environment using a logical connection to a remote computer via a network such as a network 720. The computer 700 can be connected to the network 720 via a network interface unit 716 connected to the bus 710. It should be understood that the network interface unit 716 can also be utilized to connect to other types of networks and remote computer systems. The computer 700 can also include an input / output controller 718 for receiving and processing input from a variety of other devices, including a keyboard, a mouse, a touch input, an electronic stylus ( Figure 7Similarly, the input / output controller 718 can send data to a display screen or other type of output device (also not shown). Figure 7 ) provides output.

[0076] It should be understood that the software components described herein, when loaded into the CPU 702 and executed, can transform the CPU 702 and the entire computer 700 from a general-purpose computing device into a special-purpose computing device that is customized to facilitate the functionality presented herein. The CPU 702 can be composed of any number of transistors or other discrete circuit elements, which can individually or collectively adopt any number of states. More specifically, in response to the executable instructions contained in the software modules disclosed herein, the CPU 702 can operate as a finite state machine. These computer-executable instructions can transform the CPU 702 by specifying how the CPU 702 transitions between states, thereby transforming the transistors or other discrete hardware elements that make up the CPU 702.

[0077] Encoding the software modules presented herein may also transform the physical structure of the computer-readable medium presented herein. In different implementations of this specification, the specific transformation of the physical structure depends on various factors. Examples of these factors include, but are not limited to, the technology used to implement the computer-readable medium, whether the computer-readable medium is characterized as primary memory or secondary memory, etc. For example, if the computer-readable medium is implemented as a semiconductor-based memory, the software disclosed herein can be encoded on the computer-readable medium by transforming the physical state of the semiconductor memory. For example, the software can transform the state of transistors, capacitors, or other discrete circuit elements that make up the semiconductor memory. The software can also transform the physical state of these components in order to store data thereon.

[0078] As another example, the computer-readable medium disclosed herein can be implemented using magnetic or optical technology. In such an implementation, when software is encoded in a magnetic or optical medium, the software presented herein can transform the physical state of the magnetic or optical medium. These transformations can include changing the magnetic properties of specific locations within a given magnetic medium. These transformations can also include changing the physical features or characteristics of specific locations within a given optical medium to change the optical properties of these locations. Other transformations of physical media are possible without departing from the scope and spirit of this specification, and the aforementioned examples are provided only for the convenience of this discussion.

[0079] In view of the above, it should be understood that many types of physical transformations occur in the computer 700 in order to store and execute the software components presented herein. It should also be understood that Figure 7The architecture of the computer 700 shown, or similar architectures, may be utilized to implement other types of computing devices, including handheld computers, video gaming devices, embedded computer systems, mobile devices such as smartphones, tablet computers, and AR / VR devices, as well as other types of computing devices known to those skilled in the art. It is also contemplated that the computer 700 may not include Figure 7 All components shown may include Figure 7 Other components not explicitly shown in the drawings may be utilized in conjunction with Figure 7 Completely different architecture as shown.

[0080] Figure 8 8 is a network diagram illustrating a distributed network computing environment 800 in which aspects of the disclosed technology may be implemented according to various implementation examples presented herein. Figure 8 As shown, one or more server computers 800A can be interconnected with multiple client computing devices via a communication network 720 (which can be any one or combination of a fixed-line or wireless LAN, WAN, intranet, extranet, peer-to-peer network, virtual private network, the Internet, a Bluetooth communication network, a dedicated low-voltage communication network, or other communication networks), such as, but not limited to, a tablet computer 800B, a game controller 800C, a smart watch 800D, a phone 800E such as a smart phone, a personal computer 800F, and an AR / VR device 800G.

[0081] In a network environment where the communication network 720 is the Internet, for example, the server computer 800A can be a dedicated server computer that is operable to process and transmit data to and from the client computing devices 800B-800G via any one of a number of known protocols, such as the Hypertext Transfer Protocol ("HTTP"), the File Transfer Protocol ("FTP"), or the Simple Object Access Protocol ("SOAP"). In addition, the networked computing environment 1000 can utilize various data security protocols, such as Secure Sockets Layer ("SSL") or Pretty Good Privacy Protocol ("PGP"). Each of the client computing devices 800B-800G can be equipped with an operating system that is operable to support one or more computing applications or terminal sessions, such as a web browser ( Figure 8 Not shown), or other graphical user interfaces ( Figure 8 Not shown), or a mobile desktop environment ( Figure 8 ), to gain access to the server computer 800A.

[0082] The server computer 800A can be communicatively coupled to other computing environments ( Figure 8) and receives data about participating user interactions / resource networks. In illustrative operation, a user ( Figure 8 ) can interact with computing applications running on client computing devices 800B-800G to obtain required data and / or execute other computing applications.

[0083] Data and / or computing applications may be stored on one or more servers 800A and communicated to collaborating users via client computing devices 800B-800G over the example communication network 720. Participating Users ( Figure 8 Client computing devices 800B-800G and server computer 800A may be transferred between the client computing devices 800B-800G and the server computer 800A for processing and storage.

[0084] Server 800A can host computing applications, processes, and applets for data and application generation, authentication, encryption, communication, and can be used with other server computing environments ( Figure 8 Not shown), third-party service providers ( Figure 8 (not shown), network attached storage ("NAS"), and storage area network ("SAN") work together to enable application / data processing.

[0085] It should be understood that Figure 7 The computing architecture shown in Figure 8 The distributed network computing environment shown has been simplified for ease of discussion. It should be understood that the computing architecture and distributed network computing environment may include and utilize many more components, devices, software programs, network devices, and other components not specifically described herein.

[0086] The disclosure presented herein also includes the subject matter set forth in the following clauses:

[0087] Clause 1: A computer-implemented method comprising: receiving source code expressed in a multithreaded programming language, wherein the source code includes a branch statement that directs execution to one of a plurality of source code paths; compiling the source code into a circuit description comprising a pipeline, wherein the pipeline includes a plurality of code paths associated with the plurality of source code paths, and wherein one or more pipeline stages are added to one or more of the plurality of code paths such that the plurality of code paths have the same number of pipeline stages; and generating a synchronous digital circuit based on the circuit description, the synchronous digital circuit comprising a circuit implementation.

[0088] Clause 2: The computer-implemented method of Clause 1, wherein the plurality of threads enter the pipeline in a first order, and wherein the plurality of threads exit the pipeline in a first order.

[0089] Clause 3: A computer-implemented method according to any one of clauses 1 to 2, wherein adding pipeline stages to one or more code paths of a plurality of code paths includes determining the number of pipeline stages in the longest code path, and the number of pipeline stages added to each code path is equal to the number of pipeline stages in the longest code path minus the number of pipeline stages in the code path.

[0090] Clause 4: A computer-implemented method according to any of clauses 1 to 3, wherein the pipeline comprises a first pipeline, wherein the circuit description comprises a second pipeline, wherein threads executing the first pipeline pass execution to the second pipeline by pushing local variables into a first-in-first-out queue, and wherein the second pipeline maintains thread execution order across the pipelines by reading local variables from the first-in-first-out queue in the order in which the local variables were pushed.

[0091] Clause 5: A computer-implemented method according to any of clauses 1 to 4, wherein the source code includes a reorder block construct, the reorder block wrapping a programming construct that does not maintain thread execution order, and wherein the reorder block construct is mapped to a circuit implementation, the circuit implementation: records the incoming thread execution order; allows the thread to execute the construct that does not maintain thread execution order; and, prevents the thread from restarting until all lower-ordered threads have been restarted.

[0092] Clause 6: The computer-implemented method of any of Clauses 1 to 5, wherein the thread comprises providing a set of local variables to the pipeline for execution.

[0093] Clause 7: The computer-implemented method of any of Clauses 1 to 6, wherein the pipeline comprises stages that execute in sequence, and wherein the plurality of threads maintain execution order by flowing through the stages in sequence.

[0094] Item 8: A computing device: one or more processors; and at least one computer storage medium having computer-executable instructions stored thereon, which, when executed by the one or more processors, cause the computing device to: receive source code expressed in a multithreaded programming language; compile the source code into a circuit description comprising a first pipeline, a second pipeline, and a first-in-first-out (FIFO) queue, the FIFO queue storing sets of local thread variables passed from the first pipeline to the second pipeline, wherein the first pipeline stores the sets of local thread variables in the FIFO queue in thread execution order, and wherein the second pipeline maintains thread execution order by retrieving the sets of local thread variables from the FIFO queue in thread execution order; and generate a synchronous digital circuit based on the circuit description, the synchronous digital circuit comprising a circuit implementation.

[0095] Clause 9: A computing device according to clause 8, wherein the source code includes a branch statement that directs execution to one of a plurality of source code paths; wherein the first pipeline includes a plurality of code paths associated with the plurality of source code paths, and wherein one or more pipeline stages are added to one or more of the plurality of code paths such that the plurality of code paths have the same number of pipeline stages.

[0096] Clause 10: A computing device according to any of clauses 8 to 9, wherein adding pipeline stages to one or more code paths of the plurality of code paths includes determining the number of pipeline stages in the longest code path, and the number of pipeline stages added to each code path is equal to the number of pipeline stages in the longest code path minus the number of pipeline stages in the code path.

[0097] Clause 11: A computing device according to any of clauses 8 to 10, wherein the source code includes a reorder block construct that wraps a programming construct that does not maintain thread execution order, and wherein the reorder block construct is mapped to a circuit implementation that: records an incoming thread execution order; allows a thread to execute a construct that does not maintain thread execution order; and prevents a thread from being restarted until all lower-ordered threads have been restarted.

[0098] Clause 12: The computing device of any one of clauses 8 to 11, wherein the threads leave the reordering block in the order in which they entered the reordering block

[0099] Clause 13: The computing device of any of clauses 8 to 12, wherein the thread comprises a set of local thread variables provided to the first pipeline for execution.

[0100] Clause 14: The computing device of any of clauses 8 to 13, wherein the first pipeline comprises stages that execute in sequence, and wherein the plurality of threads maintain execution order by flowing through the stages in sequence.

[0101] Item 15: At least one computer storage medium having computer-executable instructions stored thereon, which, when executed by one or more processors, cause a computing device to: receive source code expressed in a multithreaded programming language, the source code comprising constructs that map to a circuit implementation, the constructs comprising a reordering block and a construct that does not maintain thread execution order, wherein the circuit implementation comprises: a reordering buffer that registers thread identifiers in the order in which a plurality of threads are received; circuitry that executes an unknown number of clock cycles for each of the plurality of threads; wherein the reordering buffer prevents the threads from being restarted until all threads with a lower execution order are restarted; compile the constructs into a circuit description; and based on the circuit description, generate a synchronous digital circuit, the synchronous digital circuit comprising the circuit implementation.

[0102] Clause 16: At least one computer storage medium according to clause 15, wherein the source code includes a branch statement that directs execution to one of a plurality of source code paths; wherein the circuit description includes a pipeline that includes a plurality of code paths, and one or more pipeline stages are added to one or more of the plurality of code paths such that the plurality of code paths have the same number of pipeline stages.

[0103] Clause 17: At least one computer storage medium according to any one of clauses 15 to 16, wherein adding pipeline stages to one or more code paths of a plurality of code paths comprises determining a number of pipeline stages in a longest code path, and adding a number of pipeline stages to each code path is equal to the number of pipeline stages in the longest code path minus the number of pipeline stages in the code path.

[0104] Clause 18: At least one computer storage medium of any of Clauses 15 to 17, wherein the thread comprises a set of local thread variables provided to the first pipeline for execution.

[0105] Clause 19: The at least one computer storage medium of any of clauses 15 to 17, wherein the first pipeline comprises stages that execute in sequence, and wherein the plurality of threads maintain execution order by flowing through the stages in sequence.

[0106] Clause 20: At least one computer storage medium according to any one of clauses 15 to 19, wherein the pipeline comprises a first pipeline, wherein the circuit description comprises a second pipeline, wherein threads executing the first pipeline pass execution to the second pipeline by pushing local variables into a first-in-first-out queue, and wherein the second pipeline maintains thread execution order across the pipelines by reading local variables from the first-in-first-out queue in the order in which the local variables were pushed.

[0107] Based on the foregoing, it should be understood that languages ​​and compilers for maintaining thread execution order have been disclosed herein. Although the subject matter presented herein is described in the specialized language of computer structural features, methods and transformation actions, specific computing machines, and computer-readable media, it should be understood that the subject matter set forth in the appended claims is not necessarily limited to the specific features, actions, or media described herein. Rather, these specific features, actions, and media are disclosed as example forms of implementing the claimed subject matter.

[0108] The above subject matter is provided by way of illustration only and should not be construed as limiting. Various modifications and changes may be made to the subject matter of the invention described herein without following the illustrated and described example configurations and applications, and without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A computer-implemented method comprising: receiving source code expressed in a multithreaded programming language, wherein the source code includes a branch statement that directs execution to one of a plurality of source code paths; Compiling the source code into a circuit description comprising a pipeline, wherein the pipeline comprises a plurality of code paths associated with the plurality of source code paths, wherein the compiling comprises: determining the number of pipeline stages in a code path having a greatest number of pipeline stages in the plurality of code paths, and adding pipeline stages to at least one of the plurality of code paths until each of the plurality of code paths has the number of pipeline stages; as well as A synchronous digital circuit is generated based on the circuit description, the synchronous digital circuit including a circuit implementation. 2 . The computer-implemented method of claim 1 , wherein a plurality of threads enter the pipeline in a first order, and wherein the plurality of threads exit the pipeline in the first order.

3. The computer-implemented method of claim 1 , wherein adding pipeline stages to one or more of the plurality of code paths comprises determining a number of pipeline stages in a longest code path and adding to each code path a number of pipeline stages equal to the number of pipeline stages in the longest code path minus the number of pipeline stages in the code path.

4. The computer-implemented method of claim 1 , wherein the pipeline comprises a first pipeline, wherein the circuit description comprises a second pipeline, wherein threads executing the first pipeline pass execution to the second pipeline by pushing local variables into a first-in-first-out queue, and wherein the second pipeline maintains thread execution order across pipelines by reading local variables from the first-in-first-out queue in the order in which the local variables were pushed.

5. The computer-implemented method of claim 1 , wherein the source code includes a reorder block construct that wraps a programming construct that does not maintain thread execution order, and wherein the reorder block construct maps to a circuit implementation that: Record the execution order of the incoming threads, allowing threads to execute said constructs without maintaining thread execution order, and Blocks a thread from restarting until all lower-ordered threads have been restarted.

6. The computer-implemented method of claim 1, wherein at least one of the added pipeline stages comprises a computation unit and is configured to store a result generated by the computation unit in a register.

7. The computer-implemented method of claim 1, wherein the pipeline comprises stages that are executed in a sequence, and wherein a plurality of threads maintain execution order by flowing through the stages in the sequence.

8. A computing device comprising: one or more processors; as well as at least one computer storage medium having computer executable instructions stored thereon, which when executed by the one or more processors cause the computing device to: receiving source code expressed in a multithreaded programming language; compiling the source code into a circuit description comprising a first pipeline, a second pipeline, and a first-in-first-out (FIFO) queue, the FIFO queue storing a set of local thread variables passed from the first pipeline to the second pipeline, wherein the first pipeline stores the set of local thread variables in the FIFO queue in a thread execution order, wherein the second pipeline maintains the thread execution order by retrieving the set of local thread variables from the FIFO queue in the thread execution order, and wherein the source code comprises a branch statement directing execution to one of a plurality of source code paths; wherein the first pipeline comprises a plurality of code paths associated with the plurality of source code paths, wherein one or more pipeline stages are added to one or more of the plurality of code paths such that the plurality of code paths have the same number of pipeline stages, and wherein at least one of the added pipeline stages comprises a computation unit and is configured to store a result generated by the computation unit in a register; and A synchronous digital circuit is generated based on the circuit description, the synchronous digital circuit including a circuit implementation.

9. A computing device according to claim 8, wherein adding pipeline stages to one or more code paths of the plurality of code paths comprises determining the number of pipeline stages in the longest code path and adding to each code path a number of pipeline stages equal to the number of pipeline stages in the longest code path minus the number of pipeline stages in the code path.

10. The computing device of claim 8, wherein the source code includes a reorder block construct that wraps a programming construct that does not maintain thread execution order, and wherein the reorder block construct maps to a circuit implementation that: Record the execution order of the incoming threads, allowing threads to execute said constructs without maintaining thread execution order, and Blocks a thread from restarting until all lower-ordered threads have been restarted. The computing device of claim 10 , wherein threads exit the reorder block in the order in which they enter the reorder block.

12. The computing device of claim 8, wherein the thread comprises: A set of local thread variables provided to the pipeline for execution.

13. The computing device of claim 8, wherein the first pipeline comprises stages that execute in a sequence, and wherein a plurality of threads maintain an order of execution by flowing through the stages in the sequence.

14. At least one computer storage medium having stored thereon computer executable instructions which, when executed by one or more processors, cause a computing device to: receiving source code expressed in a multithreaded programming language, the source code comprising constructs that map to a circuit implementation, the constructs comprising a reordering block and a construct that does not maintain thread execution order, wherein the circuit implementation comprises: a reorder buffer that registers thread identifiers in the order in which the plurality of threads are received; circuitry that executes an unknown number of clock cycles for each of a plurality of threads; wherein the reorder buffer prevents threads from being restarted until all threads with a lower execution order are restarted; compiling the construction into a circuit description; and Based on the circuit description, a synchronous digital circuit is generated, the synchronous digital circuit including the circuit implementation.

15. The at least one computer storage medium of claim 14, wherein the source code includes a branch statement that directs execution to one of a plurality of source code paths; wherein the circuit description includes a pipeline, the pipeline including a plurality of code paths, and wherein one or more pipeline stages are added to one or more of the plurality of code paths such that the plurality of code paths have the same number of pipeline stages.

16. At least one computer storage medium of claim 15, wherein adding pipeline stages to one or more of the plurality of code paths comprises determining a number of pipeline stages in a longest code path and adding to each code path a number of pipeline stages equal to the number of pipeline stages in the longest code path minus the number of pipeline stages in the code path.

17. The at least one computer storage medium of claim 15, wherein the thread comprises: A set of local thread variables provided to the pipeline for execution.

18. The at least one computer storage medium of claim 15, wherein the first pipeline comprises stages that execute in a sequence, and wherein a plurality of threads maintain execution order by flowing through the stages in the sequence.

19. The at least one computer storage medium of claim 15, wherein the pipeline comprises a first pipeline, wherein the circuit description comprises a second pipeline, wherein threads executing the first pipeline pass execution to the second pipeline by pushing local variables into a first-in-first-out queue, and wherein the second pipeline maintains thread execution order across pipelines by reading local variables from the first-in-first-out queue in the order in which the local variables were pushed.

Images