LOCO: rewording and organizing, better better

1 files changed, 32 insertions, 27 deletions

diff --git a/papers/LOCO-24/contents.latex b/papers/LOCO-24/contents.latex
index 6e8e0f2..c87c992 100644
--- a/papers/LOCO-24/contents.latex
+++ b/papers/LOCO-24/contents.latex
@@ -277,15 +277,10 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
   computers that can be maintained by an individual.
 
 \subsection{Embracing the language: Scheme}
-  This makes \textit{Scheme} and its possible extensions a good choice to
-  please \textit{vernacular programmers}\cite{MythsPL:Shaw}, that comprehend a
-  good compromise between available technical literacy from the user side and a
-  wide audience to benefit.
-
   \textit{Scheme} is a simple language, with a minimal standard, but that
   enables a huge level of abstraction thanks to its minimal but powerful core
   concepts which are also present in mainstream programming languages today
-  (Python, JavaScript) reducing the friction with seasoned programmers.
+  (Python, JavaScript).
 
   The \textit{Lisp} family of languages have proven to be flexible and powerful
   for system design \cite{LispMachine:Greenblatt} and particularly
@@ -335,41 +330,51 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom }
 
 
 \subsection{Computer hardware that embraces the language}
-  Attempts have been done to run Scheme in a bare-metal environment
-  \cite{MIMOSA:Yvon} [LOKO], but none of them approached the problem of a CPU
-  that is heavily optimized for a software model that has other underlying
-  concepts.
+  Attempts have been done to run Scheme in a bare-metal environment using
+  commodity hardware\cite{MIMOSA:Yvon} [LOKO], but they do not take advantage
+  of hardware optimized for \textit{Scheme}, which would provide huge
+  performance benefits and simplify the interpreter and possibly also the CPU.
 
 \subsubsection{Optimization for tree structures}
-  \textit{Scheme} is based (not only that, the language itself is a list) in
-  the \textit{cons cell}, similar to a \textit{linked-list} node, and the data
-  structures that can be created from it (\textit{lists} and \textit{trees}).
-  Optimizing the CPU for that case, with fast lookups and \code{car} and
-  \code{cdr} operations hugely impacts in its performance. This can also affect
-  the memory, but as it is managed, the user would never notice any difference.
+  \textit{Scheme} is profoundly based on the \textit{cons cell}, similar to a
+  \textit{linked-list} node, and the data structures that can be created from
+  it (\textit{lists} and \textit{trees}). Optimizing the CPU for that case,
+  with fast lookups and \code{car} and \code{cdr} operations would impact its
+  performance. This might require developing new caching and memory access
+  mechanism, but could simplify the ones present in mainstream CPUs and
+  reducing its security concerns.
 
 \subsubsection{CPU as a reducer}
   \textit{Scheme} supports many paradigms but the basis of the language is the
-  expression reduction, not like imperative language, where the basis is the
-  \textit{statement}. This opens the door for optimizations like those applied
-  in current \textit{Scheme} interpreters but in a hardware level. [REDUCER
-  CPUs]
+  expression reduction, in opposition to imperative language, where the basis
+  is the \textit{statement}, that matches current processor architectures
+  better. This opens the door for optimizations like those applied in current
+  \textit{Scheme} interpreters but in a hardware level. [REDUCER CPUs]
 
 \subsubsection{Hardware garbage collection}
+% TODO LANGUAGE
   When the whole system uses managed memory, the Garbage Collection,
-  \textit{GC}, can be pushed down in the stack. Oberon's GC is in the kernel,
-  but we could push it down to the hardware.
+  \textit{GC}, can be pushed down in the stack. Oberon\cite{Oberon:Wirth} and
+  MIMOSA \cite{MIMOSA:Yvon} propose a OS-level GC, but it can be done directly
+  in hardware[HARDWARE GC], reducing the requirements of the OS and the CPU.
 
 \subsubsection{FPGA}
+% TODO LANGUAGE
+  SKIM \cite{FPhardware:Stoye} tries to go for custom hardware, with a
+  functional programming language. Instead of making real machines, we could
+  just go for FPGAs, they are powerful nowadays, and we could do it
+  incrementally, as our language is simple and can be represented using
+  imperative CPUs.
+
   Focusing on personal computing can be a extremely powerful way to explore
   optimization and simplification of computing systems to the point they can be
   run in custom unoptimized CPUs implemented in FPGAs \cite{Oberon:Wirth}.
 
-  For our case, a FPGA facilitates the testing and the evaluation of the
-  impacts of the proposed optimizations. If a Hardware Description Language,
-  \textit{HDL}, is provided with the system and the Operating System has
-  support for Partial and Dynamic Reconfiguration\cite{FPGAReconf:Vipin}, the
-  whole system can be updated together, improving the OS and the needed
+  For our case, a FPGA facilitates the incremental testing and the evaluation
+  of the impacts of the proposed optimizations. If a Hardware Description
+  Language, \textit{HDL}, is provided with the system and the Operating System
+  has support for Partial and Dynamic Reconfiguration\cite{FPGAReconf:Vipin},
+  the whole system can be updated together, improving the OS and the needed
   hardware at the same time. A \textit{rollback}[GUIX/NIX] mechanism could
   always recover the state of both hardware and software as if they were the
   same thing.