KR20230159596A - Parallel processing architecture using speculative encoding - Google Patents

Abstract

A technique for program execution in a parallel processing architecture using speculative encoding is disclosed. A two-dimensional array of computational elements is accessed, and each computational element in the array of computational elements is known to the compiler and is coupled to neighboring computational elements in the array of computational elements. Control over the array of computational elements is provided on a cycle-by-cycle basis. Control is enabled by a stream of wide, variable-length, control words generated by the compiler. Two or more operations are merged into a control word, which includes a branch decision and operations associated with the branch decision. The merged control word contains speculatively encoded operations for at least two possible branch paths. At least two possible branching paths produce independent side effects. Operations associated with a branch decision that are not indicated by the branch decision are suppressed.

Description

Parallel processing architecture using speculative encoding

Related applications

This application claims priority to U.S. Provisional Patent Application No. 63/166,298, “Parallel Processing Architecture Using Speculative Encoding,” filed March 26, 2021.

The foregoing application is hereby incorporated by reference in its entirety for jurisdictions where permissible.

technology field

This application relates generally to program execution, and more specifically to parallel processing architectures using speculative encoding.

The amount of data being collected, stored as data sets, analyzed, processed, and used for a variety of purposes ranging from surveillance to marketing is exploding. Whether data is stored and accessed as the pages of a handbook, a laboratory journal, or a table in a report collection in a file cabinet, the advent of digital data formats and the decreasing cost of digital storage technologies have greatly increased the convenience with which data can be stored and accessed. Data formats allow storage of various types of data, including numbers, sounds, pictures, and videos. Storage technology allows data to be stored locally, remotely and securely on small, portable devices. Storage technologies are based on electro-mechanical systems that include “hard” disk drives that store data magnetically on rotating disks. Other storage technologies are based on “solid state” techniques, which have no moving parts, and data is stored using electronic devices such as transistors. Data can also be stored on optical disks and magnetic tapes. The choice of which storage technologies are used is based on the amount of data to be stored, the speed at which the data is accessed, the frequency with which the data is accessed, and of course cost. This means that storage requirements for constantly accessed data are more stringent and more expensive than those for rarely accessed data.

The collected data is stored as a set or dataset, which can be very large. Processing of massive data sets is frequently performed by organizations for commercial, government, medical, educational, research, or retail purposes, among many others. These organizations expend enormous resources on data processing because the success or failure of any given organization is directly dependent on its ability to process data for financial and competitive benefit to the organization. Organizations thrive when data processing successfully meets organizational goals. Otherwise, if data processing is not successful, the organization is left stranded. Many and varied data collection techniques are used to collect data from a wide and diverse range of individuals. Individuals include customers, citizens, patients, purchasers, students, test subjects, and volunteers. Sometimes individuals participate willingly, but other times they become unwitting targets of data collection. Common data collection techniques include “opt-in” techniques, where an individual signs up, registers, creates an account, or otherwise willingly consents to participate in data collection. Other techniques are enacted into law, such as governments requiring citizens to obtain registration numbers and use those numbers while interacting with government agencies, law enforcement, emergency services, etc. Additional data collection techniques, such as tracking purchase history, website visits, button clicks, and menu selections, may be more sophisticated or completely hidden. Regardless of the technology used to collect data, the data collected is extremely valuable to the organization. It is very important to process this data quickly.

Organizations perform many mission-critical data processing tasks. Whether running payroll, analyzing research data, or training neural networks for machine learning, processing a task consists of many complex tasks. Tasks may include loading and storing various datasets, accessing processing components and systems, etc. The tasks themselves are typically based on subtasks, where the subtasks include loading or reading data from storage, performing calculations on the data, storing or writing data back to storage, It can be used to handle specific tasks, such as handling communication between subtasks such as data and control. The data sets being accessed are often large and can easily be swapped for processing architectures that are unsuitable for the processing task or are less flexible in design. To significantly improve task processing efficiency and throughput, two-dimensional (2D) arrays of elements can be used for task and subtask processing. 2D arrays include compute elements, multiplier elements, caches, queues, controllers, decompressors, arithmetic logic units (ALUs), storage elements, and other components that can communicate among themselves. includes them. Arrays of these elements are constructed and operated by providing control to the array on a cycle-by-cycle basis. Control of the 2D array is achieved by providing control words generated by the compiler. Control includes a stream of control words, where the control words may include wide, variable length, microcode control words generated by a compiler. Control words are used to configure the array and control the processing of tasks and subtasks. Additionally, arrays can be configured with a topology most suitable for task processing. Topologies in which arrays may be configured include systolic, vector, cyclic, spatial, streaming, or Very Long Instruction Word (VLIW) topologies, among others. Topologies may include topologies that enable machine learning functions.

Task processing is based on a parallel processing architecture using speculative encoding. 1. A processor-implemented method for processing a task, comprising: accessing a two-dimensional (2D) array of compute elements, wherein each compute element in the array of compute elements is known to a compiler and its neighbors in the array of compute elements. Combined with calculation elements -; providing control over the array of computational elements on a cycle-by-cycle basis, the control being enabled by a stream of wide, variable length, control words generated by the compiler; and coalescing two or more operations into a control word, wherein the control word includes a branch decision and operations associated with the branch decision. . The merged control word contains speculatively encoded operations for at least two possible branch paths. In embodiments, branch decisions support subroutine execution. Branch decisions can further support programming loops. A programming loop can include merge operations from both the end of the loop and the beginning of the loop.

Embodiments include promoting data for downstream operations. Downstream operations are arithmetic, vector, matrix, or tensor operations; May include Boolean operations, etc. Downstream operations may include operations within a Directed Acyclic Graph (DAG). Promoting data generated by a fetched branch path may be based on scheduling by the compiler to perform a commit write outside the branch indecision window. Additional embodiments include suppressing one or more operations associated with a branch decision that are not indicated by the branch decision. Suppression is performed dynamically. Suppression may include idle computation elements that would have been used to process operations if the operations had not been suppressed. Suppression enables power reduction in the 2D array of computational elements. Inhibited operations do not process data, do not generate data, and do not generate control signals. In embodiments, suppression prevents data from being committed. Additional embodiments include removing results from a side of a branch not indicated by the branch decision. Removing results can be performed to eliminate race conditions and avoid data ambiguity. The decision to promote branch path data taken is based on the branch decision. Therefore, data generated from either branch path cannot be considered valid until a branch decision is performed. In embodiments, if a side of a branch that was not taken attempts to execute a commit record after the branch decision, operation of the array is halted.

Various features, aspects, and advantages of various embodiments will become more apparent from the further description that follows.

The following detailed description of specific embodiments may be understood with reference to the following drawings.
1 is a flow diagram for a parallel processing architecture using speculative encoding.
Figure 2 is a flow chart for motion suppression.
Figure 3A illustrates a system block diagram for a highly parallel architecture with a shallow pipeline.
Figure 3b illustrates computational element array details.
Figure 4 illustrates branches in the code.
Figure 5A shows code blocks merged by the compiler.
Figure 5b shows the programming loop merged by the compiler.
Figure 6 illustrates a compiler view of a code image.
Figure 7 shows suppressed operations for the expected branch path.
Figure 8 illustrates a compressed code word fetch and decompress pipeline.
9 shows a code word encoding and naive request-driving fetch pipeline overlay ( shows a demand-driven fetch pipeline overlay.
Figure 10 illustrates compiler coarse branch prefetch hints.
Figure 11 shows a system block diagram for compiler interactions.
Figure 12 is a system diagram for a parallel processing architecture using speculative encoding.

A technique for program execution based on a parallel processing architecture using speculative encoding is disclosed. The executed program can have a wide range of applications based on data manipulation, such as image or audio processing applications, AI applications, business applications, etc. Programs may contain operations, where operations may be based on tasks, and the tasks themselves may be based on subtasks. The executed task may perform various operations including arithmetic operations, shift operations, logic operations including Boolean operations, vector or matrix operations, tensor operations, etc. Subtasks may be executed based on priority, priority, coding order, amount of parallelism, data flow, data availability, computational element availability, communication channel availability, etc. Data manipulations are performed on a two-dimensional (2D) array of computational elements. Computation elements within the 2D array may be implemented as a central processing unit (CPU), graphics processing unit (GPU), application specific integrated circuit (ASIC), field programmable gate array (FPGA), processing core, or other processing component or combination of processing components. You can. Compute elements may include heterogeneous processors, homogeneous processors, processor cores, etc. within an integrated circuit or chip. Computation elements may be coupled to local storage, which may include local memory elements, register files, cache storage, etc. Caches, which may include hierarchical caches such as L1, L2, L3 caches, store data such as intermediate results, compressed control words, coalesced control words, uncompressed control words, relevant portions of control words, etc. Can be used to store . A cache may store data generated by a branch path taken, where the branch path taken is determined by a branch decision. A control word is used to control one or more computational elements within an array of computational elements. Both compressed and uncompressed control words can be used to control the array of elements. Multiple layers of a two-dimensional (2D) array of computational elements can be “stacked” to comprise a three-dimensional array of computational elements.

Tasks, subtasks, etc. related to operations are created by the compiler. Compilers may include general-purpose compilers, hardware technology-based compilers, compilers written or “tuned” for an array of computational elements, constraint-based compilers, satisfiability-based compilers (SAT solvers), etc. Control is provided to the hardware in the form of control words, where control words are provided in cycles. One or more control words are generated by the compiler. Control words may include wide, variable length, microcode control words. The length of a microcode control word can be adjusted by compressing the control word, recognizing when a computational element is unnecessary by the task so that control bits within the control word are not required for that computational element, etc. Control words may be used to route data, set up operations to be performed by computational elements, idle rows and/or columns of computational elements or individual computational elements, etc. Compiled microcode control words associated with a computational element are distributed to the computational element. Computation elements are controlled by a control unit that operates based on decompressed control words. Control words enable processing by computational elements. Task processing is enabled by executing one or more control words.

Two or more operations may be merged into a control word to accelerate execution of tasks, reduce or eliminate stalling on an array of computational elements, etc. The compiler can perform the merging at compile time, before the control words are loaded into the array of computational elements. The merged control word includes the branch decision and operations associated with the branch decision. A merged control word may enable partial or complete execution of two or more potential branch decisions or aspects. A merged control word can enable partial or complete execution of a single branch decision resulting in two branch paths or aspects. In a use case, the merged control word includes a branch and operations associated with aspects of the branch. Because the outcome of a branch is unlikely to be known a priori to the execution of the branch, execution of the control words associated with all possible aspects of the branch is initiated using the available parallel resources in the array, or is "pre-executed." (pre-executed)". Once a branch decision is made, actions associated with the indicated aspect of the branch may proceed. Actions associated with aspects of unmarked branches may be suppressed or ignored. Suppressing operations may include idling computational elements that will be used to execute operations associated with aspects of the branch that are not indicated. Inhibiting operations and, by extension, idling computational elements reduces power consumption within the 2D array. Ignoring behavior increases operational simplicity. Suppressing an operation or overriding an operation can be enabled on a compute element basis. A combination of suppressing operations and ignoring operations can be enabled on a per-computation element basis.

A parallel architecture using speculative encoding enables program execution. A two-dimensional (2D) array of computational elements is accessed. Computational elements may include computational elements, processors, or cores within an integrated circuit; Processors or cores within an application-specific integrated circuit (ASIC); may include programmed cores within a programmable device, such as a field programmable gate array (FPGA), etc. Computation elements may include homogeneous or heterogeneous processors. Each computational element in the 2D array of computational elements is known to the compiler. A compiler, which may include a general-purpose compiler, a hardware-oriented compiler, or a compiler specific to computational elements, may compile code for each of the computational elements. Each computational element is coupled to neighboring computational elements in an array of computational elements. Combining computational elements enables data communication between computational elements. Accordingly, the compiler can control data flow to and from computational elements as well as data commitment to memory outside the array. Control is provided to the hardware through one or more control words generated by the compiler. Control may be provided on a cycle-by-cycle basis. Cycles may include clock cycles, data cycles, processing cycles, physical cycles, architecture cycles, etc.

This control is enabled by a stream of wide, variable-length, control words generated by the compiler. Control words may include microcode control words, instruction equivalents, building blocks for high-level languages, etc. In embodiments, each operation from the operations represents an equivalent instruction. In embodiments, instruction equivalents include building blocks for a high-level language. Control words, such as microcode control word length, can vary based on the type of control, compression, simplification, such as identifying computational elements that are unnecessary. The control words, which may include compressed control words, merged control words, etc., may be decoded and provided to a control unit that controls the array of computational elements. The merged control word may include a branch instruction and one or more operations. The control word may be decompressed to a level of fine control granularity, where each compute element (integer compute element, floating point compute element, address generation compute element, write buffer element, read buffer element, etc. ) are controlled individually and uniquely. Each compressed control word is decompressed to allow control on an element-by-element basis. Segments of control words applied to individual computational elements may be referred to as a bunch. Decoding determines whether a given computational element is needed to process a task or subtask; It may depend on whether the computational element has a specific control word associated with it or whether the computational element receives repeated control words (e.g., control words used for more than one computational element). A program is executed on an array of computational elements based on a set of instructions. Execution may be achieved by executing a plurality of subtasks associated with the compiled task. Executing the plurality of subtasks may include performing operations on one or more computational elements in an array of computational elements.

1 is a flow diagram for a parallel processing architecture using speculative encoding. Groupings of computational elements (CEs), such as CEs assembled within a 2D array of computational elements (CEs), may be configured to execute various operations associated with programs. Operations may be based on tasks and subtasks associated with the tasks. The 2D array may further interface with other elements such as controllers, storage elements, ALUs, multiplier elements, etc. Operations may achieve various processing objectives such as application processing, data manipulation, etc. Operations operate on integer, real, and character data types; vectors and matrices; It can operate on a variety of data types, including tensors, etc. Control is provided to an array of computational elements on a cycle-by-cycle basis, where control is based on control words generated by the compiler. Control words, which may include microcode control words, enable or idle various computational elements; provide data; routing results between and among CEs, caches, and storage; etc. Controls enable computational element operation, memory access priorities, etc. Compute element operation and memory access priorities allow the hardware to properly sequence compute element results. The control enables execution of the compiled program on the array of computational elements. Additionally, both aspects of the branch are encoded speculatively and merged into control that includes the branch decision and the actions associated with the branch decision. When a branch decision is made, operations associated with the “taken” aspect of the branch may continue to execute, operate on data, etc. Actions associated with the "not taken" aspect of a branch may be suppressed or ignored. Suppressing operations on aspects of a branch that was not taken can reduce or prevent execution delays, enable power reduction, prevent data from being committed, etc. This can result in overriding actions when unwanted data commits are not in progress.

Flow 100 includes accessing a two-dimensional (2D) array 110 of computational elements, each computational element in the array of computational elements being known to the compiler, and coupling to neighboring computational elements in the array of computational elements. do. Computational elements may be based on various types of processors. Computational elements or CEs include central processing units (CPUs), graphics processing units (GPUs), processors or processing cores in application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) It may include processing cores programmed within, etc. In embodiments, computational elements within an array of computational elements have the same functionality. Computational elements may include heterogeneous computing resources, where the heterogeneous computing resources may or may not be collocated within a single integrated circuit or chip. Computational elements may be organized into topologies, where the topology may be built into an array, programmed or configured within an array, etc. In an embodiment, an array of computational elements is configured by a control word to implement one or more of a systolic, vector, cyclic, spatial, streaming, or Very Long Instruction Word (VLIW) topology.

Computation elements may further include a topology suitable for machine learning computation. Computation elements may be coupled to other elements within the array of CEs. In embodiments, combinations of computational elements may enable one or more topologies. Other elements that CEs can be combined with include one or more levels of cache storage; multiplier units; address generator units for generating load (LD) and store (ST) addresses; May include storage elements such as queues, etc. Compilers for which each computational element is known may include C, C++, or Python compilers. A compiler for which each computational element is known may include a compiler written specifically for the array of computational elements. Coupling each CE to neighboring CEs may include sharing elements such as cache elements, multiplier elements, ALU elements, or control elements; It enables communication between neighboring CEs or among CEs.

Flow 100 includes providing control 120 over an array of computational elements on a cycle-by-cycle basis. Control over the array includes configuration of elements, such as computational elements within the array, that load and store data; It may include routing data to, from, and between computational elements, etc. In flow 100, control is enabled by a stream of wide, variable length control words (122). Control words can configure computational elements and other elements within the array; enable or disable individual computational elements, rows and/or columns of computational elements; load and save data; route data to, from, and between computational elements; etc. can be done. One or more control words are generated by the compiler (124). The compiler that generates the control words may be a general-purpose compiler, such as a C, C++, or Python compiler; A hardware description language compiler, such as a VHDL or Verilog compiler; It may include a written compiler for arrays of computational elements, etc. A compiler can be used to map functions to an array of computational elements. In embodiments, a compiler may map machine learning functions to an array of computational elements. Machine learning can be based on machine learning (ML) networks, deep learning (DL) networks, support vector machines (SVM), etc. In embodiments, machine learning functionality may include a neural network (NL) implementation. Control words generated by the compiler may be used to configure one or more CEs, allow data to flow to and from the CEs, configure the CEs to perform operations, etc. Depending on the type and size of the task being compiled to control the array of computational elements, one or more of the CEs may be controlled, while other CEs are unnecessary by the particular task. Unnecessary CEs can be marked in the control word as unnecessary. Unnecessary CE requires no data and no control words are required for CE. In embodiments, unnecessary computational elements may be controlled by a single bit. In other embodiments, a single bit can control an entire row of CEs by instructing the hardware to generate idle signals for each CE within the row. A single bit may be set to “unneeded,” reset to “needed,” or similar uses of the bit to indicate when a particular CE is unneeded by the task.

Control words generated by the compiler may contain conditionality. In an embodiment, control includes branching. The code, which may include code associated with an application such as image processing, audio processing, etc., may include conditions that may cause the execution of a sequence of code to be passed on to a different sequence of code. Conditional constraints can be based on evaluating an expression, such as a Boolean or arithmetic expression. In embodiments, conditional constraints may determine code jumps. Code jumps can include conditional jumps, as described previously, or non-conditional jumps, such as jumps to stop, quit, or exit instructions. Conditional constraints may be determined within an array of elements. In embodiments, conditional restrictions may be established by the control unit. To establish conditional limits by the control unit, the control unit may act based on a control word provided to the control unit. In embodiments, the control unit may operate based on uncompressed control words. Control words can be decompressed by a decompressor logic block that decompresses words from the compressed control word cache on their way to the array. In embodiments, a set of directions may include spatial allocation of subtasks on one or more computational elements within an array of computational elements. In other embodiments, a set of instructions may enable multiple programming loop instances to cycle within an array of computational elements. Multiple programming loop instances may include multiple instances of the same programming loop, multiple programming loops, etc.

Relevant portions of the control word may be stored in a cache, register file, or other storage associated with the array of computational elements. Control words stored in the decompressed control word (DCW) cache may include compressed control words, decompressed control words, etc. In embodiments, an access queue may be associated with a cache, where the access queue may be used to queue requests to access the cache, storage, etc. for storing data and loading data. The data cache may include multilevel caches such as level 1 (L1) cache, level 2 (L2) cache, etc. L1 caches can be used to store blocks of data to be processed. The L1 cache may contain small, fast memory that can be quickly accessed by computational elements and other components. The L2 cache can contain larger and slower storage compared to the L1 cache. The L2 cache can store "next up" data, results such as intermediate results, etc. In embodiments, the L1 and L2 caches may be further combined into a level 3 (L3) cache. The L3 cache can be larger than the L2 and L1 caches and contain slower storage. Accessing data from the L3 cache is still faster than accessing main storage. In embodiments, L1, L2, and L3 caches may include 4-way set associative caches. In embodiments, the cache may include a double read, single write (2R1W) data cache. As the name suggests, the 2R1W data cache can support up to two read operations and one write operation simultaneously without causing read/write conflicts, race conditions, or data corruption. In embodiments, the 2R1W data cache may support concurrent fetch data for potential branch paths to the compiler. Recall that the branch condition can be selected from two or more branch paths, that is, both the branch path taken and the other branch path not taken are determined by the branch decision.

Flow 100 includes coalescing two or more operations 130 into a control word. Merging may involve identifying operations that can be executed independently of each other. Note that a program that can be executed on a 2D array of processors may be represented by a tree, where branches of the tree may represent sequences of operations or commands to be executed. The decision associated with which branch or branches of the program tree are executed may be based on the branch decision. Branch decisions can be based on values such as the value of a variable, conditions, expressions such as Boolean expressions, etc. In flow 100, the control word includes a branch decision and operations 132 associated with the branch decision. Operations may be associated with one or more aspects of a branch decision. Branching decisions may be based on predicted outcomes, predicted outcomes, etc. In embodiments, the merged control word may include speculatively encoded operations for at least two possible branch paths (or threads). In order for actions to be merged, they must be independent of each other. Operations may share data, such as input data, tasks performed, or output data generated by an operation associated with a thread. However, this does not affect tasks performed or output data generated by operations associated with other threads. In embodiments, at least two possible branching paths may produce independent side effects. Independent side effects may include control signals generated, output data for routing to other operations, data to be written to storage, etc. In other embodiments, at least two possible branch paths may produce compute element actions that must be committed. Computational element actions that must be committed may include write operations to storage outside the 2D array of computational elements. In further embodiments, at least two possible branch paths may be performed in parallel by a 2D array of computational elements.

Operations that can be incorporated into a control word can configure computational elements within a 2D array, enable or disable computational elements, etc. In embodiments, two or more operations control data flow within a 2D array of computational elements. Data flow may include providing or routing data to, from, between, or among computational elements, etc. Data flow can be controlled by one or more bits within the control word. Flow 100 further includes suppressing one or more operations associated with the branch decision that are not indicated by the branch decision (140). Inhibition may include halting execution of operations associated with an unmarked branch decision, aborting operations, etc. In embodiments, suppression may be achieved dynamically. In one use case, suppression may occur after determining a branch decision. Thus, inhibition can occur “on the fly” based on branch decisions. Suppression can be achieved with other processing or delay reduction techniques. In embodiments, suppression may prevent speculative branch execution delays. In other embodiments, suppression may enable power reduction in a 2D array of computational elements. Suppression of operations can now be achieved by idling computational elements to which the suppressed operations are assigned. Idling compute elements reduces the amount of power consumed by the compute elements, and further reduces the amount of power consumed by the 2D array. In further embodiments, suppression may prevent data from being committed. Data being committed can be transferred out of the 2D array of computational elements and stored in storage external to the 2D array. Data generated by suppressed operations can be ignored, so there is no need to commit the data.

Flow 100 further includes ignoring one or more operations 142 associated with the branch decision that are not indicated by the branch decision. Ignoring operations may include ignoring data produced by the operations such that the control word(s) of the branch path taken do not use the results produced by the “speculative” execution of the initial portion of the path. and it turns out that it cannot be taken. In flow 100, ignoring is accomplished atomically (144). An atomic operation is an operation that can be isolated from other operations that can be executed in parallel to the isolated operation. Atomic operations can be considered "indivisible" in the sense that the operation can be executed independently of other operations. In flow 100, overriding is accomplished by setting idle bit 146 in the control word. The idle bit may be used to enable or idle an individual computational element, enable or idle a row or column of a computational element, and send a control word to an individual computational element. Ignoring may include setting an idle bit such that the control word(s) of the branch path taken no longer uses that particular control element.

In some embodiments, certain operations are performed on the array for two or more aspects of a branch instruction. The results of branch paths or paths not taken may be ignored, and all side effects of branch paths or paths not taken may be canceled or ignored. However, minimizing the number of operations performed speculatively can both minimize side effects that will be canceled or ignored, and reduce power consumption in the array. To achieve this, a compiler can implement speculative encoding, where control words can be encoded speculatively so that the encoding is, for both taken and not taken branch paths, the operations before the branch, the branch It may include the decision operation itself, and post-branch operations on multiple aspects of the branch. Because an array of computational elements can provide large resource capabilities, a compressed control word (CCW) can speculatively encode a large number of parallel operations, which may include multiple branching paths.

The various steps of the flow 100 may be sequentially changed, repeated, omitted, etc. without departing from the disclosed concepts. Various embodiments of flow 100 may be included in a computer program product embodied in a computer-readable medium containing code executable by one or more processors.

Figure 2 is a flow chart for operation suppression. As discussed throughout, various types of programs can be executed on an array of computational elements. Programs include tasks, subtasks, etc. that can be processed on computational elements. Tasks include general operations such as arithmetic, vector, array, or matrix operations; Boolean operations such as NAND, NOR, XOR, or NOT operations; Operations based applications such as neural networks or deep learning operations; It may include etc. In order for tasks to be processed accurately, control words are provided on a cycle-by-cycle basis to an array of computational elements. Control words configure the array to execute a task. Control words may be provided by the compiler to an array of computational elements. The control words may include merged control words, where the merged control words include a branch decision and operations associated with the branch decision. Providing control words that control placement, scheduling, data transfers, etc. within the array can maximize task processing throughput. This maximization ensures that tasks that generate data required by the second task are processed before processing of the second task, etc. Branch decisions are based on the task containing the branch operation. Branching operations may be based on conditionality, where the conditionality may be established by a program that controls the operation of the control unit. A branch may include multiple “ways,” “paths,” or “sides” that can be taken based on conditional constraints. Conditional constraints may include evaluating an expression such as an arithmetic or Boolean expression, transferring from a sequence of instructions to a second sequence of instructions, etc. In embodiments, conditional constraints may determine code jumps. Because the branch path to be taken is not known a priori for evaluating conditional constraints, operations associated with aspects of the branch can be executed on a heuristic basis. When conditional constraints are determined and branch decisions are made, actions associated with the taken aspect may proceed, while actions associated with the unmarked aspect may be ignored. Additionally, it is possible to suppress actions associated with the untaken aspect of a branch. Suppression of operations may be accomplished by idling computational elements configured for operations associated with the untaken aspect of the branch. This is not done "dynamically" by the control unit, which does not direct control word fetches to the taken path, but rather the control words on the taken side of the branch idle the speculatively encoded operations on the other side of the branch. Please note that it will be made with . This is encoded into a control word at compile time.

The merged control word can be determined by speculative encoding. Merging control words enables a parallel processing architecture using speculative encoding. A two-dimensional (2D) array of computational elements is accessed, where each computational element in the array of computational elements is known to the compiler and is coupled to neighboring computational elements in the array of computational elements. Control over the array of computational elements is provided on a cycle-by-cycle basis, where control is enabled by a stream of wide, variable-length, control words generated by the compiler. Two or more operations are merged into a control word, where the control word includes a branch decision and operations associated with the branch decision.

Flow 200 includes suppressing or ignoring one or more operations 210 associated with a branch decision that are not indicated by the branch decision. Suppressing may include terminating execution of operations, overwriting or deleting operations, etc. Ignoring may include allowing operations on computational elements to complete as long as the state of the system known by the compiler is not corrupted. In flow 200, suppression is achieved dynamically, in the sense that the branch decision is dynamic (212); “Suppression” is encoded in the control word(s) of the branch path already taken. Suppression may be based on a branch decision, where the branch decision may include an unmarked side of the branch, a not taken side of the branch, etc. Random results, such as data generated by operations associated with aspects of an unmarked branch, are unnecessary for further execution of the program, processing of tasks, subtasks, etc. Rather than having to expend clock cycles, architecture cycles, etc. associated with an array of computational elements to flush, overwrite, delete, etc. unnecessary data, no cycles are wasted ignoring data. Subsequent control words "actively" refer to the results still in the array generated by the first few control word(s) of the path that were not taken, not only for the control word containing the decision, but also for generally several subsequent control words. “Actively” is ignored. This means that undesirable results are produced during a short "branch shadow" after a decision is made in the array. This is the few cycles following a decision within the array, which are spent driving the decision from the array to the control unit, and the control unit acting on that decision and potentially rerouting the fetched control word(s). . Registers, cache, or other storage associated with unnecessary data may be made available for further processing. Additional embodiments may include removing results from a side of a branch not indicated by the branch decision. If leaving data associated with an aspect of the indicated branch may cause race conditions, data ambiguity, or some other possible processing conflict, unneeded data may be removed from storage, registers, cache, etc.

In flow 200, suppression prevents speculative branch execution delays 220 because it allows speculative execution of paths that would not be taken. As discussed throughout, speculative branch execution may be based on executing control words, such as speculatively encoded merged control words. The speculatively encoded control word may be based on merging a branch instruction and operations associated with two or more aspects of the branch instruction. One of the aspects may be taken more often during program execution, may be more likely to be taken, or may otherwise be predicted to be the aspect of the branch to be taken. Speculative encoding may include one or more actions from the side of the branch that are less likely to be taken. If a branch decision indicates one of the aspects of the branch that is less likely to be taken, some of the operations associated with the control words for the branch side decided are either available for execution or have already been performed in parallel with the operations associated with other branches. It was executed. Additional control words may be fetched, decoded, and provided to a 2D array of computational elements. Accordingly, execution delays can be prevented. In flow 200, suppression enables power reduction 222 in the 2D array of computational elements. Power reduction can be achieved by idling computational elements that can be assigned to operations that are inhibited once a branch decision is made. Idle computational elements enable power reduction within the 2D array. In flow 200, suppression prevents data from being committed (224). An operation can access data for processing and produce output data. Output data from processed operations is typically stored within storage associated with a 2D array, such as a cache, register file, memory, etc.; or stored in storage beyond or external to the 2D array. By suppressing operations on the side of an unmarked branch, any data resulting from executing the currently suppressed operation can be ignored, deleted, overwritten, or flushed. Therefore, data is not committed by suppressed operations.

Figure 3A shows a system block diagram for a highly parallel architecture with a shallow pipeline. A highly parallel architecture may include components including computational elements, processing elements, buffers, one or more levels of cache storage, system management, arithmetic logic units, etc. Various components can be used to accomplish task processing, where task processing is associated with program execution. In highly parallel processing architectures, tasks can be processed using speculative encoding. A two-dimensional (2D) array of computational elements is accessed, where each computational element in the array of computational elements is known to the compiler and is coupled to neighboring computational elements in the array of computational elements. Control over the array of computational elements is provided on a cycle-by-cycle basis, where control is enabled by a stream of wide, variable length control words generated by the compiler. Two or more operations are merged into a control word, where the control word includes a branch decision and operations associated with the branch decision.

A system block diagram 300 is shown for a highly parallel architecture with a shallow pipeline. The system block diagram may include an array of computational elements 310 . Computational element array 310 may be based on computational elements, where the computational elements may include a processor, a central processing unit (CPU), a graphics processing unit (GPU), a coprocessor, etc. Computational elements may be based on processing cores configured within chips such as application specific integrated circuits (ASICs), processing cores programmed into programmable chips such as field programmable gate arrays (FPGAs), etc. Computational elements may include a homogeneous array of computational elements. System block diagram 300 may include translation and look-aside buffers, such as translation lookaside buffers 312 and 338. Translation lookup buffers can supplement the memory cache, which can be used to reduce storage access times. The system block diagram may include logic for load and access ordering and selection. Logic for load and access ordering and selection may include logic 314 and logic 340. Logic 314 and 340 may achieve load and access ordering and selection for bottom data blocks 316, 318, and 320 and top data blocks 342, 344, and 346, respectively. These layout techniques can provide dual access to bandwidth, reduce interconnection complexity, etc. Logic 340 may be coupled to compute element array 310 via queues, address generators, and multiplier units 347 components. In the same way, logic 314 may be coupled to compute element array 310 via queues, address generators, and multiplier units 317 components.

The system block diagram may include access queues. The access queue may include access queues 316 and 342. Access queues can be used to queue requests to access caches, storage, etc. to store data and load data. The system block diagram may include level 1 (L1) data caches, such as L1 caches 318 and 344. L1 caches can be used to store blocks of data, such as data to be processed together, data to be processed sequentially, etc. The L1 cache may contain small, fast memory that can be quickly accessed by computational elements and other components. The system block diagram may include level 2 (L2) data caches. The L2 cache may include L2 caches 320 and 346. The L2 cache can contain larger and slower storage compared to the L1 cache. The L2 cache can store "next" data, results such as intermediate results, etc. The L1 and L2 caches can be further combined into a level 4 (L3) cache. The L3 cache may include L3 caches 322 and 348. The L3 cache can be larger than the L2 and L1 caches and contain slower storage. Accessing data from the L3 cache is still faster than accessing main storage. In embodiments, L1, L2, and L3 caches may include 4-way set associative caches.

Block diagram 300 may include a system management buffer 324. The system management buffer may be used to store system management code or control words that may be used to control the array 310 of computational elements. A system management buffer can be used to hold opcodes, codes, routines, functions, etc. that can be used for exception or error handling, management of a parallel architecture for processing tasks, etc. A system management buffer may be coupled to a decompressor 326. A decompressor may be used to decompress system management compression control words (CCWs) from system management compression control word buffer 328 and store the decompressed system management control words in system management buffer 324. Compressed system management control words may require less storage than uncompressed control words. System management CCW component 328 may also include a spill buffer. The spill buffer may include large static random access memory (SRAM) that can be used to support multiple nested levels of exceptions.

Computational elements within the array of computational elements may be controlled by a control unit, such as control unit 330. While the compiler controls individual elements via control words, the control unit may pause the array to ensure that new control words are not driven into the array. The control unit may receive the decompressed control word from decompressor 332. A decompressor is used to enable or idle rows or columns of computational elements; to enable or idle individual computational elements; to transmit control words to individual computational elements; The control word (discussed below) can be decompressed for, etc. The decompressor may be coupled to a compression control word store, such as Compression Control Word Cache 1 (CCWC1) 334. CCWC1 may include a cache, such as an L1 cache, containing one or more compressed control words. CCWC1 may be coupled to an additional compressed control word store, such as Compressed Control Word Cache 2 (CCWC2) 336. CCWC2 can be used as an L2 cache for compressed control words. CCWC2 can be larger and slower than CCWC1. In an embodiment, CCWC1 and CCWC2 may contain 4-way set associativity. In embodiments, the CCWC1 cache may contain uncompressed control words, in which case it may be designated as DCWC1. In that case, decompressor 332 may be coupled between CCWC1 334 (now DCWC1) and CCWC2 336.

Figure 3B shows computational element array details 302. Arrays of computational elements can be coupled to components that enable the computational elements to process one or more tasks. Components can access data, present data, and perform certain high-speed operations. The computational element array and associated components enable a parallel processing architecture using speculative encoding. Computation element array 350 may perform various processing tasks, where processing tasks may include operations such as arithmetic, vector or matrix operations, and the like. Computation elements may be coupled to multiplier units, such as bottom multiplier units 352 and top multiplier units 354. Multiplier units may be used to perform fast multiplications associated with general processing tasks, multiplications associated with neural networks such as deep learning networks, multiplications associated with vector operations, etc. Computation elements may be coupled to load queues, such as load queues 356 and load queues 358. The load queue can be coupled to the L1 data cache as previously described. Load queues can be used to load storage access requests from compute elements. Load queues can track expected load latencies and notify the control unit when load latency exceeds a threshold. Notification from the control unit may be used to signal that the load may not arrive within the expected time frame. Load queues can also be used to pause an array of computational elements. Load queues can send a pause request to a control unit that will pause the entire array, while individual elements can be idled under the control of a control word. When an element is not explicitly controlled, it can be placed in an idle (or low-power) state. Although no operation is performed, the ring bus can continue to operate in "pass thru" mode to ensure proper operation of the rest of the array. A compute element is also considered active if it is only used to route unmodified data through the ALU, i.e. if the compute element acts as a routing element.

While the array is paused, background loading of the array from memories (data and control words) can be performed. The memory system can run freely and continue operating while the array is paused. There may be multi-cycle latency due to control signal transmission, which introduces additional dead time so that the memory system "reaches into" the array and properly scratches the load data while the array is paused. It may be advantageous to allow passing to scratchpad memory. This mechanism can operate to make the array state known as far as the compiler is concerned. When array operation resumes after a pause, new load data that the compiler needs to maintain the statically scheduled model arrives at the scratchpad.

Figure 4 illustrates branches in the code. Code, programs, applications, apps, etc. can contain one or more branches. Branches are conditional branches that may be based on the value of a variable, flag, signal, etc.; and unconditional branches that can transfer control and perform a certain number of operations. One or more operations may be associated with each branch. In embodiments, two or more operations may be merged into a control word, where the control word may include a branch decision and operations associated with the branch decision. The merged control word can use speculative encoding to control the parallel processing architecture. Figure 400 illustrates seven segments within an execution tree. The seven segments include segment A (410), segment B (412), segment C (414), segment D (416), segment E (418), segment F (420), and segment G (422). Each of the seven segments may include operations such as the four operations shown for each segment. The determination of which of the seven segments will be executed can be based on the three branch points shown, such as branch point 424, branch point 426, and branch point 428. Based on the branching decision made at the branch point, there are four potential paths to take along the seven branches of the tree. Paths may include ABD, ABE, ACF, and ACG. In the figure, the path ACG taken along the branches of the tree is indicated as path 430. Execution of operations associated with segments of tree 400 may be based on processing cycles. In example 400, the operations shown may be executed in 13 cycles.

Figure 5A shows code blocks merged by compiler 500. As discussed throughout, program execution may be based on branching operations, and branching operations may include conditional branches or unconditional branches. Conditional branches can be based on values, flags, signals, etc., and can be described using various techniques such as if-then-else techniques, case or switch techniques, etc. Unconditional branches can include "always taken" branches that can transfer control, sequence of actions, etc. Merging may be based on speculative encoding, where merged operations may be executed in a parallel processing architecture. In embodiments, the merged control word may include speculatively encoded operations for at least two possible branch paths. A merged control word may contain two or more operations. The merged control word may further include speculatively encoded operations for at least two possible branch paths. In order for two or more operations associated with a branch path to be merged into a control word, various conditions may apply. In embodiments, at least two possible branching paths may produce independent side effects. Side effects may include program execution stall, increased functional density of compressed control words, etc. Interruptions in program execution may occur while waiting for requested data, while compressed control words are fetched and decompressed, etc.

In other embodiments, at least two possible branch paths may produce compute element actions that must be committed. Computational element actions that must be committed may include writing to storage, where the storage may be external to the array of computational elements. For the purposes of this example, a commit write may include writing data that may be used by downstream operations and provided to other computational elements within the array of computational elements, etc. The commit record may include indicators such as ready, data valid, data complete, etc. Because which side of the branch will be taken is not known a priori, writing data before determining which side of the branch direction is taken can present race conditions, provide invalid data, etc. A commit record can store data in one or more registers, register files, caches, storage, etc. In embodiments, the commit history may include commit history for data storage. Data storage may be accessible by the array, coupled to the array, and located within the array of elements through a network, such as a computer network. In embodiments, data storage resides external to the computational element associated with the branch. Examples of code blocks that can be merged by the compiler are shown. Merged blocks may include block 510, block 512, block 514, block 516, block 518, block 520, etc. A merged control block may include one or more operations. In embodiments, the merged control word may be a single control word. Operations within a control block can be executed sequentially. In further embodiments, operations associated with at least two possible branch paths may be performed in parallel by a 2D array of computational elements.

Coalescing also involves subsequent control words that control one or more branch decisions as well as subsequent actions that may or may not be executed (or have the results ignored), depending on which branch path is selected. It may include a number of control words. For example, block 516 may include control word 8 including branch decision paths D, E, F, and G, and control word 9 including subsequent operations for each of the possible branch decision paths. and these operations may be referred to as branch shadows. Accordingly, merging may include branch decisions and speculative encoding of a control word including one or more additional control words. And, one or more additional control words may control operations subsequent to the control word including the branch decision.

Figure 5b shows the programming loop merged by the compiler. Branch decisions that may be made as part of program execution may support programming loop 562. Programming loop 562 may be controlled by branches, such as conditional branches, execution of subroutines, or procedures. To support programming loops, operations from the end of the loop and the beginning of the loop can be merged into a control word. Control words containing operations from the end of the loop and the beginning of the loop are enabled by a parallel processing architecture that uses speculative encoding. A compiler is used to merge the code words represented by tree 502. The tree contains seven segments, segment A, segment B, segment C, segment D, segment E, segment F and segment G. The merged control word 550 includes operations associated with the beginning of the loop and the end of the loop. The beginning of the loop is known a priori to include the operations from segment A, but what other operations will be executed is not known until branch decisions are made. Accordingly, merged control word 556 includes operations from segments D, E, F, and G. Other operations from the seven segments that can be merged into control words can include control words 552, 554, 556, 558, and 560.

Figure 6 shows a compiler view of the code image. As previously discussed, multiple operations can be merged into a control word. A merge may include speculatively encoded operations for at least two possible branch paths. Because merging can support parallel execution of a set of operations, the number of cycles required to execute operations associated with a path through branches of the program tree can be reduced. In example 600, the number of cycles progressing along the path through the tree may be reduced to 7 cycles. Compiler views of code images can be enabled by a parallel processing architecture that uses speculative encoding. A two-dimensional (2D) array of computational elements is accessed, where each computational element in the array of computational elements is known to the compiler and is coupled to neighboring computational elements in the array of computational elements. Control is provided on a cycle-by-cycle basis to an array of computational elements, where control is enabled by a stream of wide, variable length control words generated by the compiler. Two or more operations are merged into a control word, where the control word includes a branch decision and operations associated with the branch decision.

A compiler view of the code image based operations that can be merged into control words is shown. Operations within control words can be executed sequentially or in parallel, cycle by cycle. In the example shown, operations A0 and A1 may be executed in parallel during the first cycle and operation A2 may be executed during the second cycle. Recall that the merged control word may include a branch decision (e.g., which side of the branch is taken) and operations associated with the branch decision. In the figure, there are three branch decisions marked as operations A4, B4 and C4. The three branch decisions may include conditional branches. The upstream branch decision that may be decided in a previous cycle may determine which branch decision may be selected in a subsequent cycle. In the usage example, a branch decision at A4 that selects branch B precludes the need to determine a branch decision at C4 because branch C has been eliminated by the branch decision at A4.

Figure 7 shows suppressed operations for expected branch path 700. Branch decisions and merging of branch decisions and actions are described throughout. Additionally, the branch outcome determined in a previous cycle (e.g., which aspect of the branch is taken) may determine which branch decision is selected in a subsequent cycle. In part, this “determinism” can be due to the one cycle latency of branch decision information leaving the array of computational elements. Operations on expected branch paths are enabled by a parallel processing architecture that uses speculative encoding. Recall that branch decisions used to determine the set of operations to perform and the data sets on which the operations will act can be injected using a multiplexer (MUX). As a result, the compressed control word (CCW) may include one or more bits or fields that can be used as input select lines for the MUX. Input select lines may select a compute element to receive a potential branch decision signal. In embodiments, more than two potential branches may be supported per cycle. Based on the branch decision, one or more MUX input select lines, etc., operations associated with the taken aspect of the branch are processed or executed, while operations associated with one or more untaken aspects of the branch are not processed. Actions associated with one or more untaken aspects of a branch can be ignore, delete, flush, etc.

Additional embodiments include suppressing one or more operations associated with a branch decision that are not indicated by the branch decision. Inhibition may include stopping execution of operations, stopping operations, etc. In embodiments, inhibition is achieved dynamically. Dynamic suppression may be based on the current branch decision, previous branch decision, etc. In embodiments, suppression may prevent speculative branch execution delays. Delay may include waiting for fetches of compressed control words, fetches of data, etc. to complete. Suppression of operations associated with one or more unmarked branch decisions may enable a reduction in the number of operations performed during a given cycle, fewer data requests, etc. In embodiments, suppression may enable power reduction in a 2D array of computational elements. Power reduction may be achieved by using techniques such as idling one or more processing elements that are not required for processing operations during a given cycle. In other embodiments, suppression may prevent data from being committed. Committing data may include writing data from a 2D array of computational elements to storage, such as external storage.

In a use case, possible branch decisions A4 and B4 or C4 may be made while performing operations associated with a compiler view of the code image. Branch or path C may be a predicted branch or path. The branch decision at A4 may be to proceed along branch C, and thus operations associated with branches B, D, and E may be suppressed. That is, the operations of B3, B4, C1, D1, D2, E2, D3, D4, E3, E4, F3, and F4 can be suppressed. Other operations associated with branches D, C, and E may be performed as part of speculative encoding. Additionally, no branch decision will be required at B4. Suppression of operations associated with B, D, and E may be accomplished by idling computational elements that would have been assigned to perform operations associated with B, D, and E. Idle computational elements can enable power reduction in a 2D array.

Figure 8 shows the compressed code word fetch and decompression pipeline. Program execution may be based on control words, such as compressed control words. Compressed control words may be based on merged operations and may include a branch decision and one or more operations that may be associated with the branch decision. Compressed control words can be fetched from storage and decompressed before providing the decompressed control word or words to a 2D array of computational elements. Fetching and decompressing compressed control words enables a parallel processing architecture using speculative encoding. A two-dimensional (2D) array of computational elements is accessed. Control over the array of computational elements is provided on a cycle-by-cycle basis, where control is enabled by a stream of wide, variable length control words generated by the compiler. Two or more operations are merged into a control word, where the control word includes a branch decision and operations associated with the branch decision.

A compressed code word fetch and decompression pipeline is shown (800). The operations performed within the pipeline are shown with associated cycles in which the various operations may be performed. Operations in the pipeline can be initiated by driving a branch decision out of the array. Referring to previously discussed examples, branching decisions may include selecting a B branch and a D or E branch, a C branch and an F or G branch, etc. Based on the branch decision, one or more fetch cycles may be executed. In the example shown, four fetch cycles may be performed. One or more fetch cycles may be used to fetch one or more compressed control words associated with a branch decision. One or more compressed control words may be decompressed. One or more decompression cycles may be performed to decompress one or more compressed control words associated with a taken branch. The decompressed control word is provided or driven to an array of computational elements. The decompressed control word can be executed by a 2D array of computational elements.

9 shows code word encoding and naive ( ) shows a demand-driven fetch pipeline overlay. In the absence of speculative encoding in the encoded control word stream, fetches on non-predicted branches can cause significant delays in program execution. An example of a naive demand-driving fetch, such as a fetch on a non-predicted branch, is shown at 900. Code word encodings 910 are shown with cycles associated with a code word request fetch 920. Code word request fetch may be based on a branch decision at A4. In a use case based on the previously described code trees and fetch and decode pipeline, the branch decision at A4 may occur during cycle 3. Control words associated with a predicted or typical branch decision proceeding along branch C are shown (912). However, if the branch decision at A4 is to proceed along branch B, a fetch cycle may be initiated on an unexpected branch. The control words shown at 912 may be suppressed, where suppressing may include idling computational elements to reduce power consumption by the array. A fetch initiated for branch B will involve deciding to branch out of the array, driving four fetch cycles, two decode cycles, and driving the decompressed control word for the branch taken into the array. Execution of the decompressed control word can then begin with B1 (Cycle 12). Execution of operation B1 during the twelfth cycle is based on the compressed control word for branch B being available in the L1 cache accessible by the 2D array of computational elements. If the compressed control word is not available in the L1 cache, additional delays can be expected. In embodiments, operations that may be performed may be speculatively encoded into subsequent compressed control words. Actions may be associated with paths taken and paths not taken. Speculative encoding of compressed control words can mitigate the creation of side effects, such as computational element actions that may require commit. Committing may include writing data to storage external to the 2D array.

Figure 10 shows compiler coarse branch prefetch hints. As previously discussed, compiled code may be represented as branches of a tree, where one or more operations may be associated with each branch of the tree. Whether the operations of a given branch are executed may be based on the branch decision. Branch decisions may be determined based on values, expressions, etc. Two or more operations may be merged into a control word, where the control word may include a branch decision and operations associated with the branch decision. As the number of branches in the tree increases, the width of the possible execution cone may also increase. That is, the number of branch decisions and the number of operations associated with each of the branch decisions also increase, resulting in larger, single compressed control word sizes. By allowing the stream of compressed control words to diverge into separate streams based on actual branch decisions made and branches executed, the sizes of compressed control words can be reduced. However, if fetching new compressed control words is not expected to be successful, the 2D array of computational elements may be halted while a new control word stream is fetched. Compiler driving prefetch hints within the stream of compressed control words can be used to fetch and decode the start of a possible new uncompressed control word stream. Compiler driving prefetch hints enable a parallel processing architecture using speculative encoding. Fetching and decoding can be accomplished using a 2-read 1-write (2R1W) level 1 (L1) compressed control word store (e.g., L1 cache) and an additional decompressor.

An example execution cone and compiler driving prefetch hint are shown (1000). Execution cone 1010 may include branch decisions. A branch decision may cause execution to process operations based on the first aspect of branch 1012 or the second aspect of branch 1014. Execution of the first aspect of branch 1012 may be based on the expected branch decision, while compiler driving prefetch hint 1020 may prefetch compressed control words associated with the second aspect of branch 1014. May be introduced into the control word stream. Accordingly, when a branch decision at cone 1010 is determined, execution of the decompressed control words with first side 1012 or second side 1014 begins without interrupting the 2D array of computational elements. It can be.

Figure 11 shows a system block diagram for compiler interactions. As discussed throughout, the computational elements within the 2D array are known to the compiler, which can compile tasks and subtasks for execution on the array. Compiled tasks and subtasks are executed to achieve task processing. Various interactions may be associated with the compiler, such as placement of tasks, data routing, etc. Compiler interaction uses speculative encoding to enable a parallel processing architecture. A two-dimensional (2D) array of computational elements is accessed. Each computational element in the array of computational elements is known to the compiler and is coupled to neighboring computational elements in the array of computational elements. Control over the array of computational elements is provided on a cycle-by-cycle basis. Control is enabled by a stream of wide, variable length control words generated by the compiler. Control may include two or more way branching operations. Two or more actions are merged into a control word. The control word includes a branch decision and operations associated with the branch decision.

System block diagram 1100 includes a compiler 1110. Compilers may include high-level compilers such as C, C++, Python, or similar compilers. The compiler may include a compiler implemented for a hardware description language, such as a VHDL™ or Verilog™ compiler. The compiler may include a compiler for a portable, language-independent intermediate representation, such as a low-level virtual machine (LLVM) intermediate representation (IR). A compiler can generate a set of instructions that can be provided to computer elements and other elements in the array. A compiler may be used to compile task 1120. A task may include multiple tasks associated with a processing task. Tasks may further include a plurality of subtasks. Tasks may be application based, such as a video processing or audio processing application. In embodiments, tasks may be associated with machine learning functionality. The compiler may generate directions 1130 for handling calculation element results. Computation element results include arithmetic, vector, array, and matrix operations; It may include results derived from Boolean operations, etc. In embodiments, computational element results are generated in parallel from an array of computational elements. Parallel results can be generated by computational elements when the computational elements can share input data, use independent data, etc. A compiler may generate a set of instructions that control data movement 1132 for an array of computational elements. Control of data movement may include movement of data to, from, and among computational elements within an array of computational elements. Controlling data movement may include loading and storing data, such as temporary data storage, during data movement. In other embodiments, data movement may include intra-array data movement.

Like a general-purpose compiler used to generate tasks and subtasks for execution on one or more processors, the compiler can provide instructions for handling tasks and subtasks, handling input data, handling intermediate and result data, etc. . The compiler may additionally generate instructions for configuring compute elements, storage elements, control units, ALUs, etc. associated with the array. As discussed previously, the compiler generates instructions for data handling to support task handling. In the system block diagram, data movement may include loads and stores 1140 with a memory array. Loads and stores can involve handling a variety of data types, such as integers, floats, double-precision, characters, and other data types. Load and Store can load and store data to local storage such as registers, register files, caches, etc. The cache may include one or more levels of cache, such as level 1 (L1) cache, level 2 (L2) cache, level 3 (L3) cache, etc. Loads and stores can also be associated with storage such as shared memory, distributed memory, etc. In addition to loads and stores, the compiler can handle other memory and storage management operations, including memory priorities. In the system block diagram, memory access priority may enable ordering of memory data 1142. Memory data may be ordered based on task data requirements, subtask data requirements, etc. Memory data ordering can enable parallel execution of tasks and subtasks.

In system block diagram 1100, ordering of memory data may enable computational element result sequencing 1144. In order for task processing to be successfully achieved, tasks and subtasks must be executed in an order that accommodates task priority, task priority, schedule of operations, etc. Memory data may be ordered so that data required by tasks and subtasks is available for processing when the tasks and subtasks are scheduled for execution. Accordingly, the results of processing data by tasks and subtasks can be ordered to optimize task execution and reduce or eliminate memory contention conflicts. The system block diagram includes enabling simultaneous execution 1146 of two or more potential compiled task outcomes based on a set of instructions. Code compiled by a compiler may include branches, where the branches may include calculations or flow control. Flow control transfers instruction execution to another instruction sequence. For example, because the outcome of a branch decision is not known a priori, sequences of instructions associated with two or more potential task outcomes can be fetched, and each sequence of instructions can begin execution. When the exact result of a branch is determined, the sequence of instructions associated with the correct branch result continues execution, while branches not taken are aborted and the associated instructions are flushed. In embodiments, two or more potential compiled results may be executed on spatially separate computational elements within an array of computational elements.

The system block diagram includes idling computational elements (1148). In an embodiment, a set of instructions from a compiler may idle unnecessary computational elements within a row of computational elements located in an array of computational elements. Depending on the task being processed, subtask, etc., not all computational elements are required for processing. Computation elements may not be needed simply because there are fewer tasks to perform than there are compute elements available in the array. In embodiments, idling may be controlled by a single bit in a control word generated by the compiler. In the system block diagram, computational elements within the array can be configured for various computational element functions 1150. Computational element functions can enable various types of computational architectures, processing configurations, etc. In embodiments, a set of instructions may enable machine learning functionality. Machine learning functions can be trained to process various types of data such as image data, audio data, medical data, etc. In embodiments, machine learning functionality may include a neural network implementation. Neural networks may include convolutional neural networks, recurrent neural networks, deep learning networks, etc. The system block diagram may include placement of computational elements within an array of computational elements, routing of results, and computational wave-front propagation 1152. A compiler may generate instructions or instructions that can place tasks and subtasks on computational elements within the array. Placement may include placing tasks and subtasks based on data dependencies between or among tasks or subtasks, or placing tasks to prevent memory conflicts or communication conflicts. Directions may enable computational wavefront propagation. The compiler can direct the 2D wavefront execution flow in the array to foster computational wavefront propagation in the array to support multiple threads of execution to exchange results or operands by intersecting in both 2D space and time.

In the system block diagram, the compiler may control architecture cycles 1160. An architectural cycle may include an abstract cycle that associates elements within an array of elements. Elements of the array may include compute elements, storage elements, control elements, ALUs, etc. An architecture cycle may include an “abstract” cycle, where the abstract cycle may refer to various architecture level operations such as a load cycle, execute cycle, write cycle, etc. Architectural cycles may refer to macro-operations of an architecture rather than low-level operations. One or more architectural cycles are controlled by the compiler. An architecture cycle is a cycle controlled by a single control word. When the array is paused, the memory system continues to run based on “wall clock” time (or “wall clock” cycles). Therefore, the architecture cycle is not the same as the wall clock cycle. The closer the number of architecture cycles is to the monthly clock cycle, the better the architectural efficiency of the system, which includes both compiler and hardware efficiency. The execution of an architectural cycle may depend on more than one condition. In embodiments, an architectural cycle may occur when a control word is available to be pipelined into an array of computational elements and all data dependencies are met. That is, the array of computational elements does not have to wait until dependent data is loaded or the entire memory queue is cleared. In the system block diagram, an architectural cycle may include one or more physical cycles 1162. A physical cycle may refer to one or more cycles at the element level required to implement load, execute, write, etc. In embodiments, a set of instructions may control an array of computational elements on a physical cycle basis. Physical cycles may be based on a clock, such as a local, module, or system clock, or some other timing or synchronization technique. In embodiments, a physical cycle unit may include an architectural cycle. Physical cycles may be based on an enable signal for each element of the array of elements, while architectural cycles may be based on a global architecture signal. In embodiments, the compiler may provide, on a cycle-by-cycle basis, valid bits for each column of the array of computational elements, via a control word. A valid bit may indicate that data is valid and ready to be processed, that an address such as a jump address is valid, etc. In an embodiment, a valid bit may indicate that a valid memory load access is coming from the array. A valid memory load access from the array can be used to access data within the memory or storage element. In other embodiments, the compiler may provide operand size information for each row of the array of computational elements, via a control word. Operand size determines how many load operations may be required to acquire the data, since the operand may span multiple data banks or multiple cache lines, which may require multiple accesses. It is used to Various operand sizes can be used. In embodiments, operand sizes may include bytes, half-words, words, and double words.

Figure 12 is a system diagram for parallel processing. Parallel processing is performed on a parallel processing architecture, where the parallel processing architecture uses speculative encoding. System 1200 may include one or more processors 1210 attached to memory 1212 that stores instructions. System 1200 may include data; intermediate stage; direction; control word; compressed control word; A control word that implements the Very Long Instruction Word (VLIW) function; It may further include a display 1214 coupled to one or more processors 1210 to display topologies including systolic, vector, cyclic, spatial, streaming, or VLIW topologies. In embodiments, one or more processors 1210 are coupled to memory 1212 and the one or more processors, when executing stored instructions, access a two-dimensional (2D) array of computational elements - within the array of computational elements. Each computational element is known to the compiler and is coupled to neighboring computational elements in an array of computational elements -; Provides control of an array of computational elements on a cycle-by-cycle basis - control enabled by a stream of wide, variable-length, control words generated by the compiler; It is configured to merge two or more operations into a control word, where the control word includes a branch decision and operations associated with the branch decision. In embodiments, the merged control word includes speculatively encoded operations for at least two possible branch paths. At least two possible branching paths can produce independent side effects. In other embodiments, at least two possible branch paths may produce compute element actions for which the compute element actions must be committed. Committing a computational element action may include saving the computational element action results to storage. Operations may be performed on data that may be promoted, and the promoted data may be used in downstream operations. Downstream operations may include arithmetic or Boolean operations, matrix operations, etc. The two or more possible branching paths may include a marked branching decision and one or more unmarked branching decisions. One or more operations associated with the branch decision that are not indicated by the branch decision may be suppressed. Suppression operations may enable power reduction in a 2D array of computational elements. Computational elements may include computational elements within one or more integrated circuits or chips; Computational elements or cores configured within one or more programmable chips, such as application specific integrated circuits (ASICs); field programmable gate arrays (FPGAs); Heterogeneous processors configured as a mesh; It may include stand-alone processors, etc.

System 1200 may include cache 1220 . Cache 1220 may be used to store data such as data associated with branch decisions, instructions for computational elements, control words, intermediate results, microcode, etc. A cache may include small, local, easily accessible memory available to one or more computational elements. In embodiments, the data stored may include data associated with two or more branch decisions. Data associated with marked branch decisions may be promoted for downstream operations, while data associated with unmarked branch decisions may be ignored. Embodiments include storing relevant portions of an instruction or control word in a cache associated with an array of computational elements. A cache may have access to one or more computational elements. The cache may include a double read, single write (2R1W) cache if present. That is, the 2R1W cache can enable two read operations and one write operation simultaneously without the read and write operations interfering with each other. System 1200 may include accessing component 1230 . Accessing component 1230 may include control logic and functions for accessing a two-dimensional (2D) array of computational elements, where each computational element within the array of computational elements is known to the compiler and has neighbors within the array of computational elements. It is combined with computational elements that do. A computational element may include one or more processors, processor cores, processor macros, etc. Each computational element may contain a certain amount of local storage. Local storage may be accessible to one or more computational elements. Each computational element may communicate with neighbors, where neighbors may include nearest neighbors or more remote “neighbors.” Communication between computational elements may be accomplished using a bus, such as an industry standard bus, a ring bus, a network such as a wired or wireless computer network, and the like. In an embodiment, the ring bus is implemented with a distributed multiplexer (MUX). As discussed below, operations associated with marked branch decisions may be executed, while operations associated with unmarked branch decisions may be suppressed.

The indicated branch decision may be based on code conditional constraints, where the conditional constraints may be established by the compiler via control word(s). The decision reached at the computational element is selected for inspection by the control unit. Code conditional constraints can include branch points, decision points, conditions, etc. In embodiments, conditional constraints may determine code jumps. Code jumps can change code execution from sequential execution of instructions to execution of a different set of instructions. In a use case, the 2R1W cache may support concurrent fetching of operations associated with merged code words. Because the branch decision indicated by an instruction or control word containing a branch may be data dependent and thus not known a priori, the control words associated with more than one branch decision may be prefetched prior to execution (prefetch) of the branch control word. Can be fetched. As discussed elsewhere, the initial portion of two or more branch paths based on branch decisions can be instantiated in a series of merged control words. When the correct branch decision is determined, computations associated with unmarked branch decisions may be suppressed.

System 1200 may include a providing component 1240 . Providing component 1240 may include controls and functions for providing control over an array of computational elements on a cycle-by-cycle basis, where control is enabled by a stream of wide, variable length control words generated by a compiler. . Control words may be based on low-level control words such as assembly language words, microcode words, etc. Controlling an array of computational elements on a cycle-by-cycle basis may include configuring the array to perform various computing operations. In embodiments, a stream of wide, variable length control words generated by a compiler provides direct, fine-grained control of a 2D array of computational elements. Computing operations may enable audio or video processing, artificial intelligence processing, machine learning, deep learning, etc. Providing control may be based on microcode control words, where the microcode control words may include opcode fields, data fields, compute array configuration fields, etc. Compilers that generate control may include general-purpose compilers, parallel compilers, compilers optimized for arrays of computational elements, compilers specialized to perform one or more processing tasks, etc. Providing control may implement one or more topologies, such as processing topologies within an array of computational elements. In embodiments, topologies implemented within an array of computational elements may include systolic, vector, cyclic, spatial, streaming, or Very Long Instruction Word (VLIW) topology. Other topologies may include neural network topologies. Controls can enable machine learning functions for neural network topologies.

A branch decision may be part of a compiled task, which may be one of many tasks associated with a processing operation. The compiled task may be executed on one or more computational elements within the array of computational elements. In embodiments, execution of a compiled task may be distributed across computational elements to parallelize execution. Executing a compiled task may include executing tasks (eg, single instruction multiple data or SIMD execution) to process multiple datasets. Embodiments may include providing for concurrent execution of two or more potential compiled task results. Recall that a provided control word or words may control code conditional constraints on an array of computational elements. In embodiments, two or more potential compiled task conclusions include computation results or flow control. Code conditional constraints, which may be based on calculating a condition such as a value, Boolean equation, etc., may result in the execution of one of two or more sequences of instructions based on the condition. In embodiments, two or more potential compiled conclusions may be controlled by the same control word. In other embodiments, conditional constraints may determine code jumps. Two or more potential compiled task conclusions may be based on one or more branch paths, data, etc. Execution may be based on one or more instructions or control words. Because the potential compiled task results are not known a priori upon evaluation of the condition, a set of instructions can enable simultaneous execution of two or more potential compiled task results. When a condition is evaluated, execution of the set of instructions associated with the condition may continue, while the set of instructions not associated with the condition (e.g., a path not taken) may be halted, flushed, etc. In embodiments, the same instruction or control word may be executed in a given cycle across an array of computational elements. Execution of tasks may be performed by computational elements located throughout an array of computational elements. In embodiments, two or more potential compiled conclusions may be executed on spatially distinct computational elements within an array of computational elements. Using spatially separated computational elements reduces storage, bus, and network contention; This may enable reduced power dissipation by computational elements, etc.

System 1200 may include a merge component 1250 . Merge component 1250 may include control logic and functions for merging two or more operations into a control word, where the control word includes a branch decision and operations associated with the branch decision. In embodiments, the merged control word is a single control word. Recall that code, programs, applications, apps, etc. run on arrays of computational elements. The execution of code, programs, etc. can be thought of as a tree, where each branch of the tree can be associated with a branch decision. The exact path through the tree associated with an execution is not known a priori. In embodiments, the merged control word may include speculatively encoded operations for at least two possible branch paths. A branch may contain a different number of possible branch paths. Merging of encoding operations may be based on one or more conditions. In embodiments, at least two possible branching paths may produce independent side effects. Side effects may include program execution interruption, an increase in the apparent functional density of compressed control words, etc. In other embodiments, at least two possible branch paths may produce compute element actions that must be committed. Actions that must be committed may include accesses such as writes to storage, where the storage may be external to the array of computational elements. In further embodiments, operations on at least two possible branch paths may be performed in parallel by a 2D array of computational elements. Parallel execution may be performed when at least two possible branch paths operate on the same data and operate on independent data (e.g., single instruction multiple data (SIMD) execution). In some codes, programs, etc., branch decisions may support program loops. Program loops can include conditional loops or non-conditional loops. In embodiments, merging may include operations from both the end of the loop and the beginning of the loop. As discussed throughout, execution of code, programs, etc. may involve cycles of operation of a 2D array of computational elements. In embodiments, merging may include two or more cycles of operation on a cycle-by-cycle basis. Merging can be used to control multiple operational cycles. In embodiments, merging may enable reduction of operation cycles on a cycle-by-cycle basis. Reduction in operational cycles can be achieved by performing two or more operations in a given cycle, combining read or write operations within a cycle, etc.

System 1200 may include a computer program product embodied in a computer-readable medium for processing a task, wherein the computer program product causes one or more processors to access a two-dimensional (2D) array of computational elements—compute. Each computational element in the array of elements is known to the compiler and is coupled to neighboring computational elements in the array of computational elements -; providing control on a cycle-by-cycle basis over an array of computational elements, control enabled by a stream of wide, variable-length, control words generated by a compiler; and merging two or more operations into a control word, wherein the control word includes a branch decision and operations associated with the branch decision.

Each of the above methods may be executed on one or more processors on one or more computer systems. Embodiments may include various forms of distributed computing, client/server computing, and cloud-based computing. Additionally, it will be understood that the depicted steps or boxes included in the flow diagrams of this disclosure are exemplary and explanatory only. Steps may be modified, omitted, repeated, or reordered without departing from the scope of the present disclosure. Additionally, each step may include one or more substeps. Although the foregoing drawings and description illustrate functional aspects of the disclosed systems, no specific implementation or arrangement of software and/or hardware should be inferred from these descriptions unless explicitly stated or otherwise clear from context. All such arrangements of software and/or hardware are intended to be within the scope of this disclosure.

Block diagrams and flow diagrams illustrate methods, devices, systems and computer program products. Elements and combinations of elements in block diagrams and flow diagrams illustrate functions, steps, or groups of steps of methods, devices, systems, computer program products, and/or computer-implemented methods. Any and all such functions, generally referred to herein as a “circuit,” “module,” or “system,” may be implemented by computer program instructions, by special-purpose hardware-based computer systems, or by special-purpose hardware and computer instructions. It may be implemented by combinations, by combinations of general purpose hardware and computer instructions, etc.

A programmable device executing any of the foregoing computer program products or computer implemented methods may include one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, programmable devices, programmable gate arrays, programmable It may include array logic, memory devices, custom integrated circuits, etc. Each may be suitably employed or configured to process computer program instructions, execute computer logic, store computer data, etc.

It will be understood that a computer may include a computer program product from a computer-readable storage medium, which may be internal or external, removable and replaceable, or fixed. Additionally, a computer may include a Basic Input/Output System (BIOS), firmware, operating system, database, etc. that may include, interface with, or support the software and hardware described in this specification.

Embodiments of the invention are not limited to either conventional computer applications or programmable devices that run them. To illustrate: Embodiments of the invention may include optical computers, quantum computers, analog computers, etc. Computer programs can be loaded on a computer to produce a specific machine capable of performing any and all of the functions shown. This particular machine provides the means for performing any and all of the functions shown.

non-transitory computer-readable media for storage; electronic, magnetic, optical, electromagnetic, infrared, or semiconductor computer-readable storage media, or any suitable combination of the foregoing; Portable computer diskettes; hard disk; random access memory (RAM); Read-only memory (ROM), erasable programmable read-only memory (EPROM, Flash, MRAM, FeRAM, or phase change memory); optical fiber; portable compact disc; optical storage device; magnetic storage device; Alternatively, any combination of one or more computer-readable media may be used, including but not limited to any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain or store an instruction execution system, apparatus, or program for use by or in connection with a device.

It will be understood that computer program instructions may include computer executable code. A variety of languages for expressing computer program instructions include, but are not limited to, C, C++, Java, JavaScript™, ActionScript™, assembly language, Lisp, Perl, Tcl, Python, Ruby, hardware description languages, database programming languages, and functional programming languages. , imperative programming languages, etc. In embodiments, computer program instructions may be stored, compiled, or interpreted for execution on a computer, programmable data processing device, processors, or heterogeneous combination of processor architectures, etc. Without limitation, embodiments of the invention may take the form of web-based computer software, including client/server software, software-as-a-service, peer-to-peer software, and the like.

In embodiments, a computer may enable execution of computer program instructions comprising multiple programs or threads. Multiple programs or threads may be processed approximately simultaneously to enhance utilization of the processor and enable substantially concurrent functions. By way of implementation, any and all methods, program code, program instructions, etc. described herein may be implemented in one or more threads, which in turn may spawn other threads, which may themselves Can have associated priorities. In some embodiments, the computer may process these threads based on priority or other order.

Unless explicitly stated or otherwise clear from context, the verbs "execute" and "process" refer to executing, processing, interpreting, compiling, assembling, linking, loading, or any combination thereof. Can be used interchangeably to bet. Accordingly, embodiments that execute or process computer program instructions, computer executable code, etc. may act on the instructions or code in any and all of the ways described. Additionally, the method steps depicted are intended to include any suitable method of causing one or more parties or entities to perform the steps. A party performing a step or part of a step need not be located in a particular geographic location or within a country border. For example, if an entity located within the United States causes method steps, or portions thereof, to be performed outside the United States, the method is considered to be performed in the United States by a temporary entity.

Although the present invention has been disclosed with respect to preferred embodiments which have been shown and described in detail, various modifications and improvements thereto will become apparent to those skilled in the art. Accordingly, the foregoing examples should not limit the spirit and scope of the present invention; Rather, it should be understood in the broadest sense permitted by law.

Claims (41)

As a method of implementing a processor for executing a program,
Accessing a two-dimensional (2D) array of compute elements, each compute element in the array of compute elements being known to the compiler and coupled to neighboring compute elements in the array of compute elements;
Providing control over the array of computational elements on a cycle-by-cycle basis, the control being controlled by a wide, variable length, control word generated by the compiler. enabled by a stream of -; and
A method comprising coalescing two or more operations into a control word, wherein the control word includes a branch decision and an operation associated with the branch decision. The method of claim 1, wherein the merged control word includes speculatively encoded operations for at least two possible branch paths. 3. The method of claim 2, wherein the at least two possible branching paths produce independent side effects. 3. The method of claim 2, wherein the at least two possible branch paths generate compute element actions that must be committed. 3. The method of claim 2, wherein operations on the at least two possible branch paths can be performed in parallel by the 2D array of computational elements. The method of claim 1, wherein the branch decision supports subroutine execution. The method of claim 1, wherein the branch decision supports a programming loop. 8. The method of claim 7, wherein the merging step includes operations from both the end of the loop and the beginning of the loop. The method of claim 1, wherein the two or more operations control data flow within the 2D array of computational elements. The method of claim 1, wherein the merged control words are a single control word. The method of claim 1, further comprising suppressing one or more operations associated with the branch decision that are not indicated by the branch decision. 12. The method of claim 11, wherein the inhibiting step is accomplished dynamically. 12. The method of claim 11, wherein said suppressing enables power reduction in the 2D array of computational elements. 12. The method of claim 11, wherein suppressing prevents data from being committed. The method of claim 1, wherein the merging step includes branch determination and speculative encoding of the control word including one or more additional control words. 16. The method of claim 15, wherein the one or more additional control words control operations subsequent to the control word including a branch decision. The method of claim 1, further comprising ignoring one or more operations associated with the branch decision that are not indicated by the branch decision. 18. The method of claim 17, wherein the ignoring step is accomplished by setting an idle bit in the control word. The method of claim 1, wherein the merging step includes two or more operational cycles in the cycle unit. 20. The method of claim 19, wherein the merging step enables reduction of the cycle-by-cycle operation cycle. The method of claim 1, wherein each operation from the operations represents an instruction equivalent. 22. The method of claim 21, wherein the instruction equivalents comprise building blocks for a high-level language. The method of claim 1, wherein the stream of wide, variable length control words generated by the compiler provides direct fine-grained control of the 2D array of computational elements. A computer program product embodied in a computer-readable medium for program execution, wherein the computer program product causes one or more processors to:
accessing a two-dimensional (2D) array of computational elements, each computational element in the array of computational elements being known to a compiler and coupled to neighboring computational elements in the array of computational elements;
providing control of the array of computational elements on a cycle-by-cycle basis, the control being enabled by a stream of wide, variable length control words generated by the compiler; and
A computer program product comprising code for causing the operations to be performed: coalescing two or more operations into a control word, the control word comprising a branch decision and an operation associated with the branch decision. 25. The computer program product of claim 24, wherein the merged control word includes speculatively encoded operations for at least two possible branch paths. 26. The computer program product of claim 25, wherein the at least two possible branch paths produce independent side effects. 26. The computer program product of claim 25, wherein the at least two possible branch paths generate computational element actions that must be committed. 26. The computer program product of claim 25, wherein operations on the at least two possible branch paths can be performed in parallel by the 2D array of computational elements. 25. The computer program product of claim 24, wherein the branch decision supports a programming loop. 26. The computer program product of claim 25, further comprising code to suppress one or more operations associated with the branch decision that are not indicated by the branch decision. 26. The computer program product of claim 25, further comprising code for ignoring one or more operations associated with the branch decision that are not indicated by the branch decision. 32. The computer program product of claim 31, wherein the ignoring is accomplished by setting an idle bit in the control word. A computer system for executing a program, comprising:
memory to store instructions;
Comprising one or more processors coupled to the memory, wherein when executing stored instructions, the one or more processors:
Access a two-dimensional (2D) array of computational elements, each computational element in the array of computational elements known to the compiler and coupled to neighboring computational elements in the array of computational elements;
providing control over the array of computational elements on a cycle-by-cycle basis, wherein the control is enabled by a stream of wide, variable length control words generated by the compiler;
A computer system configured to merge two or more operations into a control word, wherein the control word includes a branch decision and operations associated with the branch decision. 34. The computer system of claim 33, wherein the merged control word includes speculatively encoded operations for at least two possible branch paths. 35. The computer system of claim 34, wherein the at least two possible branching paths produce independent side effects. 35. The computer system of claim 34, wherein the at least two possible branch paths generate computational element actions that must be committed. 35. The computer system of claim 34, wherein operations on the at least two possible branch paths can be performed in parallel by the 2D array of computational elements. 34. The computer system of claim 33, wherein the branch decision supports a programming loop. 34. The computer system of claim 33, further configured to suppress one or more operations associated with the branch decision that are not indicated by the branch decision. 34. The computer system of claim 33, further configured to ignore one or more operations associated with the branch decision that are not indicated by the branch decision. 41. The computer system of claim 40, wherein the ignoring is accomplished by setting an idle bit in the control word.

Images