Update on Overleaf.

1 files changed, 1 insertions, 1 deletions

diff --git a/algorithm.tex b/algorithm.tex
index f50a482..a2f8c8c 100644
--- a/algorithm.tex
+++ b/algorithm.tex
@@ -5,7 +5,7 @@
 This section covers the main architecture of the HLS tool, and the way in which the back end was added to \compcert{}.  This section will also cover an example of converting a simple C program into hardware, expressed in the Verilog language.
 %\JW{I've experimented with adding a few paragraph headings to the text below -- see what you think. The advantage of headings is that it can make the text easier to read quickly.}\YH{Yes I think it works well actually, makes the sections clearer.}
 
-\paragraph{Choice of source language}\YH{Could combine this with ``Choice of implementation language'' maybe, as there is a bit of overlap.}
+\paragraph{Choice of source language}\YH{Could combine this with ``Choice of implementation language'' maybe, as there is a bit of overlap.} \JW{Although the answers to these questions happen to overlap, I think the questions are distinct and it is logical to ask them separately.}
 First of all, the choice of C for the input language of \vericert{} is because it is the most widely supported language for HLS, and most major HLS tools also use it as an input.  As a lot of existing code is also written in C for HLS, supporting C as an input language compared to a custom domain-specific language means that \vericert{} is more practical.  Another alternative was to support LLVM IR as an input language, however, to get a full work flow from a higher level language to hardware, a front end for that language to LLVM IR would also have to be verified.  Finally, a language similar to Occam was also considered, as it has inherent parallel constructs, however, this would not qualify as being high-level synthesis due to the manual parallelism that would have to be performed. %\JW{Can we mention one or two alternatives that we considered?}
 
 \paragraph{Choice of target language}