summaryrefslogtreecommitdiffstats
path: root/algorithm.tex
diff options
context:
space:
mode:
authorJohn Wickerson <j.wickerson@imperial.ac.uk>2020-11-20 10:58:30 +0000
committeroverleaf <overleaf@localhost>2020-11-20 11:07:45 +0000
commit441c14831ba0cf8660a6cc8c6f177c469da5dce6 (patch)
tree08d7a812d0ce6b2a43d2b9d73697fcf7f5cf6486 /algorithm.tex
parent59cb3ef8d8e2596488d97b96cc37ea3927890a67 (diff)
downloadoopsla21_fvhls-441c14831ba0cf8660a6cc8c6f177c469da5dce6.tar.gz
oopsla21_fvhls-441c14831ba0cf8660a6cc8c6f177c469da5dce6.zip
Update on Overleaf.
Diffstat (limited to 'algorithm.tex')
-rw-r--r--algorithm.tex5
1 files changed, 3 insertions, 2 deletions
diff --git a/algorithm.tex b/algorithm.tex
index 9337b85..971d4e7 100644
--- a/algorithm.tex
+++ b/algorithm.tex
@@ -63,7 +63,7 @@ The main work flow of \vericert{} is given in Figure~\ref{fig:rtlbranch}, which
\compcert{} is made up of 11 intermediate languages in between the Clight input and the assembly output, so the first thing we must decide is where best to branch off to our Verilog back end.
-We select CompCert's three-address code (3AC)\footnote{This is known as register transfer language (RTL) in the \compcert{} literature. We use `3AC' is used in this paper instead to avoid confusion with register-transfer level (RTL), which is another name for the final hardware target of the HLS tool.} as the branching off point. If we branch off before this (at CminorSel or earlier), then CompCert has not had the opportunity to perform such optimisations as constant propagation and dead code elimination, which have been shown to be valuable not just in conventional compilation but also in HLS~\cite{cong+11}. And if we branch off after this (at LTL or later) then CompCert has already performed register allocation to reduce the number of registers and spill some variables to the stack; this transformation is not required in HLS because there are many more registers available, and these should be used instead of RAM whenever possible.
+We select CompCert's three-address code (3AC)\footnote{This is known as register transfer language (RTL) in the \compcert{} literature. We use `3AC' is used in this paper instead to avoid confusion with register-transfer level (RTL), which is another name for the final hardware target of the HLS tool.} as the branching off point. If we branch off before this point (at CminorSel or earlier), then CompCert has not had the opportunity to perform such optimisations as constant propagation and dead code elimination, which have been shown to be valuable not just in conventional compilation but also in HLS~\cite{cong+11}. And if we branch off after this point (at LTL or later) then CompCert has already performed register allocation to reduce the number of registers and spill some variables to the stack; this transformation is not required in HLS because there are many more registers available, and these should be used instead of RAM whenever possible.
3AC is also attractive because it is the closest intermediate language to LLVM IR, which is used by several existing HLS compilers. It has an unlimited number of pseudo-registers, and is represented as a control flow graph (CFG) where each instruction is a node with links to the instructions that can follow it. One difference between LLVM IR and 3AC is that 3AC includes operations that are specific to the chosen target architecture; we chose x86\_32 because each instruction maps well to hardware.
@@ -217,7 +217,8 @@ An HTL program thus consists of two maps: a control map that describes how to ca
\node[scale=0.4] at (3.5,3.6) {$\cdots$};
\node[scale=0.4] at (3.5,3.4) {\texttt{reg\_8}};
\end{tikzpicture}
- \caption{The FSMD for our running example.\YH{Removed the register block because these are technically just internal to the update function. Also not sure if we should keep the RAM block because it is a bit misleading as we don't use those signals to communicate with the RAM, instead we just use a RAM.}}\label{fig:accumulator_diagram}
+ \caption{The FSMD for our running example.%\YH{Removed the register block because these are technically just internal to the update function. Also not sure if we should keep the RAM block because it is a bit misleading as we don't use those signals to communicate with the RAM, instead we just use a RAM.}
+ }\label{fig:accumulator_diagram}
%\JW{Maybe replace `State' with `Current State'? And maybe `Calculate State' could be clearer as `Calculate Next State'?} \JW{Can state 15 (or should it be state 16??) have a dangling incoming arrow to indicate that it is the start state? And perhaps state 1 could have a double outline to indicate that it is an `accepting' state? Since there's space above the `Calculate State' box, I'd be mildly in favour of expanding that box a bit so that it included all 15 states explicitly (snaking back and forth).}\YH{If this is better I can mock up a tikz version of it maybe and fix the last bits then too.}
\end{figure*}