Changes between Version 6 and Version 7 of Architecture

Timestamp:

12/31/69 19:21:53 (55 years ago)

Author:

binoy

Comment:

--

Architecture

@@ -11 +11 @@
 We then develop a variant of the execution graph, called ''dynamic execution graph'', which captures the relationship between the basic block and itself in the future. If a basic block is accessed more than once during the lifetime of the program, then it appears as different blocks in the dynamic execution graph. This graph is useful for detecting the dependencies between loop iterations.
 
-The third phase is the reconstruction of the program. In this phase, we divide the code into, hopefully, independent parts named ''super blocks'' that represent subsets of the execution graph. Every super block doesn't overlap with other super blocks in accessed variables, and represents a long sequence of instructions, including branch statements, that commonly execute in this pattern. As a branch instruction has ''taken'' and ''not taken'' paths, the super block may contain one or both of the two paths according to the frequency of using these paths. For example, in biased branches, one of the paths is often considered so it is included in the super block, leaving the other path outside the super block. On the other hand, in unbiased branches, both paths may be included in the super block. Therefore, a super block has multiple exits, according to the control flow it chooses during its execution. A super block also has  multiple entries, as a jump or branch instruction may target one of the basic blocks that constructs it. The ''parallelizer'' module, orchestrates the construction of super blocks and distributes them over parallel threads, which may potentially lead to out-of-order execution of the code. I/O instructions are excluded from super blocks, as changing their execution order affects the program semantics.
+The third phase is the reconstruction of the program. In this phase, we divide the code into, hopefully, independent parts named ''super blocks'' that represent subsets of the execution graph. Every super block doesn't overlap with other super blocks in accessed variables, and represents a long sequence of instructions, including branch statements, that commonly execute in this pattern. As a branch instruction has ''taken'' and ''not taken'' paths, the super block may contain one or both of the two paths according to the frequency of using these paths. For example, in biased branches, one of the paths is often considered so it is included in the super block, leaving the other path outside the super block. On the other hand, in unbiased branches, both paths may be included in the super block. Therefore, a super block has multiple exits, according to the program control flow during its execution. A super block also has  multiple entries, as a jump or branch instruction may target one of the basic blocks that constructs it. The ''parallelizer'' module, orchestrates the construction of super blocks and distributes them over parallel threads. However, this may potentially lead to out-of-order execution of the code (which we address in the next phase). I/O instructions are excluded from super blocks, as changing their execution order affects the program semantics.
 
-Finally, we combine and link super blocks according to their exits, to form the same behavior of the original program. This phase must preserve data consistency and program order, because in the execution graph construction, we don't use any pointer tracking technique to avoid aliasing. Also, memory arithmetic (e.g., array indexed with variables) may easily violate this program reconstruction. Thus, to ensure data consistency, we employ [wiki:VMTM software transactional memory] that detects any memory access violation, where each super block executing as a thread represents a transaction. Additionally, program order is maintained by deferring the commit of transactions that complete early till their valid execution time.
+Finally, we combine and link super blocks according to their exits, to form the same behavior as that of the original program. This phase must preserve data consistency and program order, because in the execution graph construction, we don't use any pointer tracking technique to avoid aliasing. Also, memory arithmetic (e.g., array indexed with variables) may easily violate this program reconstruction. Thus, to ensure data consistency, we employ [wiki:VMTM software transactional memory], where each super block executing as a thread represents a transaction. Memory access violations are now detected and resolved by STM through transactional conflict detection, abort, roll-back, and retry. Additionally, program order is maintained by deferring the commit of transactions that complete early till their valid execution time.