diff options
author | Ekaitz Zarraga <ekaitz@elenq.tech> | 2024-08-29 13:30:46 +0200 |
---|---|---|
committer | Ekaitz Zarraga <ekaitz@elenq.tech> | 2024-08-29 13:32:14 +0200 |
commit | 9e0f8888cd74bc3394833d7d0a8b8261ac4f0c74 (patch) | |
tree | f368e72922a9e4194c9494cecb1f3aa6ec49ae51 | |
parent | d0be387433a8c941f35f301eccf03e9013a7e42e (diff) |
LOCO: lay out the Proposal further
-rw-r--r-- | papers/LOCO-24/contents.latex | 240 |
1 files changed, 154 insertions, 86 deletions
diff --git a/papers/LOCO-24/contents.latex b/papers/LOCO-24/contents.latex index 7253dc3..9a59dd3 100644 --- a/papers/LOCO-24/contents.latex +++ b/papers/LOCO-24/contents.latex @@ -80,6 +80,8 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom } %% the next command will enable that style. %%\citestyle{acmauthoryear} +%% Easy way to write code inline +\newcommand{\code}{\texttt} %% end of the preamble, start of the body of the document source. \begin{document} @@ -278,92 +280,136 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom } \section{Embracing the language} - %% TODO: embracing the language means embracing the people - - From what we just discussed we can see most interesting things in Unix's - ideas are dangerous from von Neumann to shared-resource concurrency and - others are not comfortable for programmers, who prefer to use interpreted - languages instead as the abstractions they provide are easier to deal with. - But CPUs are optimized for the Unix case, instead of embracing the facilities - the programmers prefer to use. + If a computing system aims to embrace the language, it needs to make a proper + analysis of what a programming language is and how people make use of the + programming facilities that computing systems provide. Focusing on providing + facilities for \textit{vernacular programmers}\cite{MythsPL:Shaw} shapes a + good compromise between available technical literacy from the user side and a + wide audience to benefit. + +% %% TODO: embracing the language means embracing the people +% +% From what we just discussed we can see most interesting things in Unix's +% ideas are dangerous from von Neumann to shared-resource concurrency and +% others are not comfortable for programmers, who prefer to use interpreted +% languages instead as the abstractions they provide are easier to deal with. +% But CPUs are optimized for the Unix case, instead of embracing the facilities +% the programmers prefer to use. \subsection{Personal computers} - %% TODO: is this part of the intro really? - - %% TODO: What's `personal` in personal computer? embrace the user-programmer - %% TODO: make sure dates are right - - Personal computers like those before the 90s were simple. A user could - maintain them and even manipulate the electronics. They often made a strong - bet for one language (ZX Spectrum / Apple II with BASIC), but the languages - had poor abstraction capabilities. - - The introduction of larger RAM memories and more complex CPUs, made the - personal computing industry pivot towards Unix-based operating systems, as - they were proven to work in complex scenarios. This shift contributed to the - extinction of many \textit{simple} operating systems that flourished during - the previous era but facilitated the galloping increase personal computing - specs in the following years\cite{EvolutionComputing:Larus}. - - %% TODO graphical user interfaces hid the programming part - - Graphical User Interfaces, \textit{GUI}, became widespread in the early 1980s - and made computers accessible and useful to many - people\cite{EvolutionComputing:Larus} but at the expense of the access to - lower level capabilities, as \textit{protecting the user}, and the computing - literacy that traditional text-oriented usage encouraged. - - - Operating systems like Oberon \cite{Oberon:Wirth} blur the line between - \textit{GUI}s and programming, making them work together instead of hiding - the programming part of the system, while keeping a simple core in its design - that keeps the system maintainable, still making a strong bet for the - language (Oberon). - - Our proposal is to recover the feeling of personal computers from the 80s, - but with the powerful abstraction capabilities we widely regard as - comfortable. - - %% TODO: explain the GUI apparition and how before everyone was a vernacular - %% programmer and now it's not like that - %% TODO: if we want to improve the connection with the vernacular programmer, - %% we need to ask ourselves: what's a language? \cite{MythsPL:Shaw} - - For \textit{vernacular programmers}, because they represent the vast majority - of programmers \cite{MythsPL:Shaw}: simplicity (few concepts), explorability - (repl), flexible, practical, also valid for professional programmers, - extendable, can represent other kind of goals like \textit{HDLs} and even - \textit{data} via DSLs. +%% TODO: do this the other way around!!! (to make it shorter) +% Before the Unix model won, personal computers were mainstream: they were +% simple and so on. We think those computers had the base where we can build +% computers that embrace the language and the person + Before the Unix model flooded the personal computer market, computers were + simple devices designed to be operated by a single person, each brand + marketed their own \textit{ad-hoc} operating system and most of them had a + vehicular language. Computer users were familiarized with the system and were + able to manipulate it down to the electronics, creating a large generation of + computer enthusiasts that still lasts today. + + The introduction of Graphical User Interfaces, \textit{GUI}, widened the + spectrum of users \cite{EvolutionComputing:Larus} but at the expense of the + access to lower level capabilities, as \textit{protecting the user}, and the + computing literacy that traditional usage encouraged. + + Treating the users as adults (not protecting them from themselves), like + early personal computers did, and providing them the adequate interface for + exploration happens to be a extremely powerful way to explore optimization + and simplification of computing systems \cite{Oberon:Wirth}. + +% %% TODO: is this part of the intro really? +% +% %% TODO: What's `personal` in personal computer? embrace the user-programmer +% %% TODO: make sure dates are right +% +% Personal computers like those before the 90s were simple. A user could +% maintain them and even manipulate the electronics. They often made a strong +% bet for one language (ZX Spectrum / Apple II with BASIC), but the languages +% had poor abstraction capabilities. +% +% The introduction of larger RAM memories and more complex CPUs, made the +% personal computing industry pivot towards Unix-based operating systems, as +% they were proven to work in complex scenarios. This shift contributed to the +% extinction of many \textit{simple} operating systems that flourished during +% the previous era but facilitated the galloping increase personal computing +% specs in the following years\cite{EvolutionComputing:Larus}. +% +% %% TODO graphical user interfaces hid the programming part +% +% Graphical User Interfaces, \textit{GUI}, became widespread in the early 1980s +% and made computers accessible and useful to many +% people\cite{EvolutionComputing:Larus} but at the expense of the access to +% lower level capabilities, as \textit{protecting the user}, and the computing +% literacy that traditional text-oriented usage encouraged. +% +% +% Operating systems like Oberon \cite{Oberon:Wirth} blur the line between +% \textit{GUI}s and programming, making them work together instead of hiding +% the programming part of the system, while keeping a simple core in its design +% that keeps the system maintainable, still making a strong bet for the +% language (Oberon). +% +% Our proposal is to recover the feeling of personal computers from the 80s, +% but with the powerful abstraction capabilities we widely regard as +% comfortable. +% +% %% TODO: explain the GUI apparition and how before everyone was a vernacular +% %% programmer and now it's not like that +% %% TODO: if we want to improve the connection with the vernacular programmer, +% %% we need to ask ourselves: what's a language? \cite{MythsPL:Shaw} +% +% For \textit{vernacular programmers}, because they represent the vast majority +% of programmers \cite{MythsPL:Shaw}: simplicity (few concepts), explorability +% (repl), flexible, practical, also valid for professional programmers, +% extendable, can represent other kind of goals like \textit{HDLs} and even +% \textit{data} via DSLs. \subsection{The language} - - If we want to embrace the language we need to choose a language to embrace. - We have to place a bet: but we are betting to the widest option we know that - is also \textit{practical}. - - Scheme: - \begin{itemize} - \item It's abstract enough - \item Other languages can compile to it (Wisp) - \item Simple concepts but powerful abstractions - \item Minimal standard - \item Extensibility - \item Language oriented programming (Racket) - \item Proven experience with the lambda papers and lisp machines => abandoned, - but still living in Emacs. - \end{itemize} + The \textit{Lisp} family of languages have proven to be flexible and powerful + (Lisp Machines and currently Emacs) and \textit{Scheme} has a long history of + research in language and CPU design (lambda papers). + + \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. + + The nature of the Lisp family of languages also makes them suitable as file + formats (sxml) for storage and configuration files, writing DSLs (language + oriented programming), or extending the language (GOOPS, WISP) to the users' + needs (Typed Racket, Kawa). + +% If we want to embrace the language we need to choose a language to embrace. +% We have to place a bet: but we are betting to the widest option we know that +% is also \textit{practical}. +% +% Scheme: +% \begin{itemize} +% \item It's abstract enough +% \item Other languages can compile to it (Wisp: srfi-119) (srfi-110 for the +% difficulty of reading) +% \item Simple concepts but powerful abstractions +% \item Minimal standard +% \item Extensibility +% \item Language oriented programming (Racket) +% \item Proven experience with the lambda papers and lisp machines => abandoned, +% but still living in Emacs. +% \item Typed Racket / Kawa / ... +% \end{itemize} + + \subsection{Operating System} - Unix based operating systems, have demonstrated to have several troublesome - concepts that are stuck in modern day programmers and users, but valid - alternatives had also been successfully proven in other areas of the - programming practice. Betting in a language enables applying those in the - operating system level. +% Unix based operating systems, have demonstrated to have several troublesome +% concepts that are stuck in modern day programmers and users, but valid +% alternatives had also been successfully proven in other areas of the +% programming practice. Betting in a language enables applying those in the +% operating system level. \subsubsection{The kernel-interpreter} - From the programming perspective, the \textit{kernel} and programming language \textit{interpreters} act as hosts: they prepare an isolated environment for the running program and manage resources for it via @@ -374,31 +420,51 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom } interpretation. Engineering the kernel as an interpreter reduces its complexity and allows for further specialization for the chosen language. -\paragraph{Managed memory} +\subsubsection{Managed memory} Virtual memory is an attempt to isolate programs from each other but it is a - leaky abstraction that can be exploited. Removing direct access to memory, - replacing it with managed memory, removes the need of virtual memory. + leaky abstraction that can be exploited\cite{SpectreMeltdown:HillMasters}. + Removing direct access to memory, replacing it with managed memory, removes + the need of virtual memory. -\paragraph{No threads/processes but tasks} +\subsubsection{No threads/processes but tasks} Unix-style parallelism, reinforced by modern \textit{multi-core} CPU design, focuses on the implementation rather than the usage. Browser-like task design based on Coroutines/Generators/Asynchronous calls. -\paragraph{Capability based security "lambda-style"} +\subsubsection{Capability based security "lambda-style"} Reduces the amount of permission issues inherited from von Neumann style and - Unix. No user support. + Unix. No \textit{user} support. \subsubsection{Filesystem} - This allows for new paradigms in Filesystem design. -\subsection{CPU designed for the kernel-interpreter} + +\subsection{Hardware for the kernel-interpreter} + + Once the language is chosen and the structure of the kernel is well-defined, + many optimizations can be applied to the underlying hardware, the same way it + is done nowadays. \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. + \subsubsection{Hardware garbage collection} -\subsubsection{Extendable CPU} + 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. - \cite{riscvSelfHostingComputer:Somlo} +\subsubsection{Extendable CPU} + In order to test all those options, we could work in a FPGA, even using a HDL + written in \textit{Scheme}. The FPGAs are more power hungry and not as fast + as ASICs but the reduction of complexity proposed in this paper should be + enough for personal computing. Also, letting the user configure the CPU from + the computer itself reduces the need for constant upgrades, uses commodity + hardware instead of very specialized devices and reduces the chance of a + supply chain attack in many levels \cite{riscvSelfHostingComputer:Somlo}. \section{Conclusion} @@ -416,6 +482,8 @@ Computing}{December 05, 2024}{Glasgow, Scotland, United Kingdom } Embracing the language is embracing the person in charge of the computer. +\clearpage + %% The acknowledgments section is defined using the "acks" environment %% (and NOT an unnumbered section). This ensures the proper %% identification of the section in the article metadata, and the |