From 32b9b8478f5ef2a7a06bcb3e15590012ea3fdcbd Mon Sep 17 00:00:00 2001
From: Ekaitz Zarraga <ekaitz@elenq.tech>
Date: Tue, 3 Sep 2024 23:39:35 +0200
Subject: LOCO: rewording and organizing, better better
---
papers/LOCO-24/contents.latex | 59 +++++++++++++++++++++++--------------------
1 file changed, 32 insertions(+), 27 deletions(-)
(limited to 'papers/LOCO-24')
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.
--
cgit v1.2.3