diff options
Diffstat (limited to 'papers')
| -rw-r--r-- | papers/LOCO-24/contents.latex | 59 |
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. |