commit 12040bc91961caec8fa998f8d877f76664763950 Author: Robert Strandh Date: Mon Oct 28 08:10:20 2013 +0100 Initial commit diff --git a/Documentation/Makefile b/Documentation/Makefile new file mode 100644 index 0000000..2abbba6 --- /dev/null +++ b/Documentation/Makefile @@ -0,0 +1,35 @@ +NAME=lispos + +TEXFILES=$(NAME).tex $(shell ./tex-dependencies $(NAME).tex) +BIBFILES=$(NAME).bib +PDF_T=$(shell ./strip-dependence inputfig $(TEXFILES)) +VERBATIM=$(shell ./strip-dependence verbatimtabinput $(TEXFILES)) +CODEFILES=$(shell ./strip-dependence inputcode $(TEXFILES)) +PDF=$(subst .pdf_t,.pdf,$(PDF_T)) + +all : $(NAME).pdf + +%.pdf: %.fig + fig2dev -Lpdftex -m 0.75 $< $@ + +%.pdf_t: %.fig %.pdf + fig2dev -Lpdftex_t -m 0.75 -p $(basename $<).pdf $< $@ + +%.code: %.lisp + ./codify $< + +$(NAME).pdf: $(TEXFILES) $(PDF) $(PDF_T) $(VERBATIM) $(CODEFILES) $(BIBFILES) + pdflatex $< + makeindex $(NAME) + bibtex $(NAME) + pdflatex $< + pdflatex $< + +view: $(NAME).pdf + xpdf $< + +clean: + rm -f *.aux *.log *~ *.pdf *.pdf *.pdf_t *.bbl *.blg + +spotless: clean + rm -f *.ps *.dvi *.pdf *.pdf_t *.toc *.idx *.ilg *.ind *.fig.bak diff --git a/Documentation/app-macros.tex b/Documentation/app-macros.tex new file mode 100644 index 0000000..7c8f014 --- /dev/null +++ b/Documentation/app-macros.tex @@ -0,0 +1,94 @@ +\chapter{All standard macros} +\label{app-all-standard-macros} + +\texttt{and} +\texttt{assert} +\texttt{call-method} +\texttt{case} +\texttt{ccase} +\texttt{check-type} +\texttt{cond} +\texttt{ctypecase} +\texttt{declaim} +\texttt{decf} +\texttt{defclass} +\texttt{defconstant} +\texttt{defgeneric} +\texttt{define-compiler-macro} +\texttt{define-condition} +\texttt{define-method-combination} +\texttt{define-modify-macro} +\texttt{define-setf-expander} +\texttt{define-symbol-macro} +\texttt{defmacro} +\texttt{defmethod} +\texttt{defpackage} +\texttt{defparameter} +\texttt{defsetf} +\texttt{defstruct} +\texttt{deftype} +\texttt{defun} +\texttt{defvar} +\texttt{destructuring-bind} +\texttt{do} +\texttt{do*} +\texttt{do-all-symbols} +\texttt{do-external-symbols} +\texttt{do-symbols} +\texttt{dolist} +\texttt{dotimes} +\texttt{ecase} +\texttt{etypecase} +\texttt{formatter} +\texttt{handler-bind} +\texttt{handler-case} +\texttt{ignore-errors} +\texttt{in-package} +\texttt{incf} +\texttt{lambda} +\texttt{loop} +\texttt{loop-finish} +\texttt{multiple-value-bind} +\texttt{multiple-value-list} +\texttt{multiple-value-setq} +\texttt{nth-value} +\texttt{or} +\texttt{pop} +\texttt{pprint-exit-if-list-exhausted} +\texttt{pprint-logical-block} +\texttt{pprint-pop} +\texttt{print-unreadable-object} +\texttt{prog} +\texttt{prog*} +\texttt{prog1} +\texttt{prog2} +\texttt{psetf} +\texttt{psetq} +\texttt{push} +\texttt{pushnew} +\texttt{remf} +\texttt{restart-bind} +\texttt{restart-case} +\texttt{return} +\texttt{rotatef} +\texttt{setf} +\texttt{shiftf} +\texttt{step} +\texttt{time} +\texttt{trace} +\texttt{typecase} +\texttt{unless} +\texttt{untrace} +\texttt{when} +\texttt{with-accessors} +\texttt{with-compilation-unit} +\texttt{with-condition-restarts} +\texttt{with-hash-table-iterator} +\texttt{with-input-from-string} +\texttt{with-open-file} +\texttt{with-open-stream} +\texttt{with-output-to-string} +\texttt{with-package-iterator} +\texttt{with-simple-restart} +\texttt{with-slots} +\texttt{with-standard-io-syntax} diff --git a/Documentation/chap-environments.tex b/Documentation/chap-environments.tex new file mode 100644 index 0000000..e45e4f9 --- /dev/null +++ b/Documentation/chap-environments.tex @@ -0,0 +1,55 @@ +\chapter{Environments} +\label{chap-environments} + +Recall that an \emph{environment} is a mapping from \emph{names} to +\emph{objects}. This mapping consists of a set of \emph{bindings}. + +When a user is created in the system, a \emph{default global + environment} is created for that user. The global environment of a +user consists of a \emph{system-wide} environment and a +\emph{user-specific} environment. + +The system-wide environment consists of bindings that are themselves +immutable (i.e., the user is not allowed to alter the binding) such as +the binding of the symbol \texttt{cl:length} to the function that +returns the length of a sequence. The objects of these bindings are +also immutable, such as the length function itself. The system-wide +environment is the same for every user, allowing the installation of +software that is immediately visible to all users. + +The user-specific environment consists of bindings that are created by +the user. These bindings are of three different kinds: + +\begin{itemize} +\item Bindings created by the user for instance as a result of + executing a \texttt{defparameter} or \texttt{defun} form. +\item Default system-wide bindings that can be altered by the user, + such as the value of \texttt{*print-base*}. +\item Immutable bindings where the \emph{object} can be modified by + the user, such as system-defined generic functions to which the user + is allowed to add specific methods. Each user has a private copy of + such objects. +\end{itemize} + +When a function or method object is created as a result of calling +\texttt{compile} on a lambda expression, or as a result of loading a +\emph{fasl} file, the object is \emph{linked} to the current global +environment, in that external references are then resolved. When such +a function or method object is given to a different user, that +different user can execute it, but external references in it will +still refer to the environment into which it was compiled or loaded. + +This mechanism provides an efficient method of protection. A user A +can grant controlled access to part of his or her global environment +by allowing a user B to execute a function made available to him or +her through the \emph{object store}. \seechap{chap-object-store} +In a traditional modern operating system such as Unix, this kind of +controlled access required the use of the \emph{setuid} mechanism, +simply because in such a system there is no way to access an object +other than through the global file system, and the accessing user must +have the right permissions to access the object. + +The same mechanism can be used by the system itself to protect objects +that would be unwise to give users direct access to, such as disks or +printers. + diff --git a/Documentation/chap-intro.tex b/Documentation/chap-intro.tex new file mode 100644 index 0000000..098a146 --- /dev/null +++ b/Documentation/chap-intro.tex @@ -0,0 +1,311 @@ +\chapter{Introduction} +\pagenumbering{arabic} + +\section{What a Lisp operating system is} + +A Lisp Operating System (LispOS for short) is not just another +operating system that happens to be written in Lisp (although that +would be a good thing in itself). A LispOS is also an operating +system that uses the Lisp interactive environment as an inspiration +for the interface between the user and the system, and between +applications and the system. + +In this document, we give some ideas on what a LispOS might contain, +how it would be different from existing operating systems, and how +such a system might be created. + +\section{Problems with existing systems} + +\subsection{The concept of a \emph{process}} + +Most popular existing operating systems are derived from Unix which +was written in the 1970s. The computers for which Unix was intended +has a very small address space; too small for most usable end-user +applications. To solve this problem, the creators of Unix used the +concept of a \emph{process}. A large application was written so +that it consisted of several smaller programs, each of which ran in +its own address space. These smaller programs would communicate by +having one application write text to its output stream for another +application to read. This method of communication was called +a \emph{pipe} and a sequence of small applications was called +a \emph{pipeline}. As a typical example of a chain of applications, +consider the pipeline for producing a typeset document (one of the +main applications for which Unix was designed). This chain had a +program for creating tables (called \texttt{tbl}), a program for +generating pictures (called \texttt{pic}), a program for generating +equations (called \texttt{eqn}), and of course the typesetting program +itself (called \texttt{troff}). + +Using pipes to communicate between different components of an +application has several disadvantages: + +\begin{itemize} +\item To communicate complex data structures (such as trees or +graphs), they must be converted to a stream of bytes by the +creating component, and it must be analyzed and parsed into an +equivalent data structure by the using component. Not only is +this unparsing/parsing inefficient in terms of computing +resources, but it is also problematic from a +software-engineering point of view, because the external format +must be specified and maintained as a separate aspect of each +component. +\item An artificial \emph{order} between the different components is +imposed, so that components can not work as libraries that other +components can use in any order. Sometimes (as in the example +of the \texttt{troff} chain) the end result of a computation +depends in subtle ways on the order between the components of +the chain. Introducing a new component may require other +components to be modified. +\end{itemize} + +It is an interesting observation that in most text books on +operating systems, the concept of a process is presented as playing +a central role in operating-system design, whereas it ought to be +presented as an unfortunate necessity due to the limited address +space of existing minicomputers in the 1970s. It is also presented +as \emph{the} method for obtaining some kind of \emph{security}, +preventing one application from intentionally or accidentally +modifying the data of some other application. In reality, there are +several ways of obtaining such security, and separate address spaces +should be considered to be a method with too many disadvantages. + +Nowadays, computers have addresses that are 64 bit wide, making it +possible to address almost 20 exabytes of data. To get an idea of +the order of magnitude of such a number, consider a fairly large +disc that can hold a terabyte of data. Then 20 million such discs +can be directly addressed by the processor. We can thus consider +the problem of too small an address space to be solved. + +\subsection{Hierarchical file systems} + +Existing operating system come with a \emph{hierarchical file +system}. There are two significant problems, +namely \emph{hierarchical} and \emph{file}. + +The \emph{ hierarchy} is also a concept that dates back to the +1970s, and it was considered a vast improvement on flat file +systems. However, as some authors% +\footnote{See + \texttt{http://www.shirky.com/writings/ontology\_overrated.html}} +explain, most things are not naturally hierarchical. A hierarchical +organization imposes an artificial order between names. Whether a +document is called \texttt{Lisp/Programs/2013/stuff}, +\texttt{Programs/Lisp/2013/stuff}, or something else like +\texttt{2013/Programs/Lisp/stuff}, is usually not important. + +The problem with a \emph{file} is that it is only a sequence of +bytes with no structure. This lack of structure fits the Unix pipe +model very well, because intermediate steps between individual +software components can be saved to a file without changing the +result. But it also means that in order for complex data structures +to be stored in the file system, they have to be transformed into a +sequence of bytes. And whenever such a structure needs to be +modified by some application, it must again be parsed and +transformed into an in-memory structure. + +\subsection{Distinction between primary and secondary memory} + +Current system (at least for desktop computers) make a very clear +distinction between primary and secondary memory. Not only are the +two not the same, but they also have totally different semantics: +\begin{itemize} +\item Primary memory is \emph{volatile}. When power is turned off, + whatever was in primary memory is lost. + \item Secondary memory is \emph{permanent}. Stored data will not + disappear when power is turned off. +\end{itemize} + +This distinction coupled with the semantics of the two memories +creates a permanent conundrum for the user of most applications, in +that if current application data is \emph{not} saved, then it will +be lost in case of power loss, and if it \emph{is} saved, then +previously saved data is forever lost. + +Techniques were developed as early in the 1960s for presenting +primary and secondary memory as a single abstraction to the user. +For example, the Multics system had a single hierarchy of fixed-size +byte arrays (called segments) that served as permanent storage, but +that could also be treated as any in-memory array by applications. +As operating systems derived from Unix became widespread, these +techniques were largely forgotten. + +\section{Objectives for a Lisp operating system} + +The three main objectives of a Lisp operating system correspond to +solutions to the two main problems with exiting systems as indicated +in the previous section. + +\subsection{Single address space} + +Instead of each application having its own address space, we propose +that all applications share a single large address space. This way, +applications can share data simply by passing pointers around, +because a pointer is globally valid, unlike pointers in current +operating systems. + +Clearly, if there is a single address space shared by all +applications, there needs to be a different mechanism to +ensure \emph{protection} between them so that one application can +not intentionally or accidentally destroy the data of another +application. Most high-level programming languages (in particular +Lisp, but also Java, and many more) propose a solution to this +problem by simply not allowing users to execute arbitrary machine +code. Instead, they allow only code that has been produced from the +high-level notation of the language and which excludes arbitrary +pointer arithmetic so that the application can only address its own +data. This technique is sometimes called "trusted compiler". + +It might sometimes be desirable to write an application in a +low-level language like C or even assembler, or it might be +necessary to run applications that have been written for other +systems. Such applications could co-exist with the normal ones, but +they would have to work in their own address space as with current +operating systems, and with the same difficulties of communicating +with other applications. + +\subsection{Object store based on tags} + +Instead of a hierarchical file system, we propose an \emph{object + store} which can contain any objects. If a file (i.e. a +sequence of bytes) is desired, it would be stored as an array of +bytes. + +Instead of organizing the objects into a hierarchy, objects in the +store can optionally be associated with an arbitrary number +of \emph{tags}. These tags are \emph{key/value} pairs, such as for +example the date of creation of the archive entry, the creator (a +user) of the archive entry, and the \emph{access permissions} for +the entry. Notice that tags are not properties of the objects +themselves, but only of the archive entry that allows an object to +be accessed. Some tags might be derived from the contents of the +object being stored such as the \emph{sender} or the \emph{date} of +an email message. It should be possible to accomplish most searches +of the store without accessing the objects themselves, but only the +tags. Occasionally, contents must be accessed such as when a raw +search of the contents of a text is wanted. + +For a more detailed description of the object store, see +\refChap{chap-object-store}. + +It is sometimes desirable to group related objects together as +with \emph{directories} of current operating systems. Should a user +want such a group, it would simply be another object (say instances +of the class \texttt{directory}) in the store. Users who can not +adapt to a non-hierarchical organization can even store such +directories as one of the objects inside another directory. + +Here are some examples of possible keyword/value pairs, how they +might be used, and what kinds of values are permitted: + +\newcolumntype{Y}{>{\raggedright\arraybackslash}X} + + +When (a pointer to) an object is returned to a user as a result of a +search of the object store, it is actually similar to what is called +a "capability" in the operating-system literature. Such a +capability is essentially only a pointer with a few bits indicating +what \emph{access rights} the user has to the objects. Each creator +may interpret the contents of those bits as he or she likes, but +typically they would be used to restrict access, so that for +instance executing a \emph{reader} method is allowed, but executing +a \emph{writer} method is not. + +\subsection{Single memory abstraction} + +Instead of two different memory abstractions (primary and +secondary), the Lisp operating system would contain a single +abstraction which looks like any interactive Lisp system, except +that data is permanent. + +Since data is permanent, application writers are encouraged to +provide a sophisticated \emph{undo} facility. + +The physical main (semiconductor) memory of the computer simply acts +as a \emph{cache} for the disk(s), so that the address of an object +uniquely determines where on the disk it is stored. The cache is +managed as an ordinary \emph{virtual memory} with existing +algorithms. + +\subsection{Other features} + +\subsubsection{Crash proof (maybe)} + +There is extensive work on crash-proof systems, be it operating +systems or data base systems. In our opinion, this work is +confusing in that the objective is not clearly stated. + +Sometimes the objective is stated as the desire that no data be lost +when power is lost. But the solution to that problem already exists +in every laptop computer; it simply provides a \emph{battery} that +allow the system to continue to work, or to be \emph{shut down} in a +controlled way. + +Other times, the objective is stated as a protection against +defective software, so that data is stored at regular intervals +(checkpointing) perhaps combined with a \emph{transaction log} so +that the state of the system immediately before a crash can always +be recovered. But it is very hard to protect oneself against +defective software. There can be defects in the checkpointing code +or in the code for logging transactions, and there can be defects in +the underlying file system. We believe that it is a better use of +developer time to find and eliminate defects than to aim for a +recovery as a result of existing defects. + +\subsubsection{Multiple simultaneous environments} + +To allow for a user to add methods to standard generic functions +(such as \texttt{print-object}) without interfering with other +users, we suggest that each user gets a different \emph{global +environment}. The environment maps \emph{names} +to \emph{objects} such as functions, classes, types, packages, and +more. Immutable objects (such as the \texttt{common-lisp} package) +can exist in several different environments simultaneously, but +objects (such as the generic function \texttt{print-object} would be +different in different environments. + +Multiple environments would also provide more safety for users in +that if a user inadvertently removes some system feature, then it +can be recovered from a default environment, and in the worst case a +fresh default environment could be installed for a user who +inadvertently destroyed large parts of his or her environment. + +Finally, multiple environments would simplify experimentation with +new features without running the risk of destroying the entire +system. Different versions of a single package could exist in +different environments. + +\section{How to accomplish it} + +The most important aspect of a Lisp operating system is not that all +the code be written in Lisp, but rather to present a Lisp-like +interface between users and the system and between applications and +the system. It is therefore legitimate to take advantage of some +existing system (probably Linux or some BSD version) in order to +provide services such as device drivers, network communication, +thread scheduling, etc. + +\subsection{Create a Lisp system to be used as basis} + +The first step is to create a Common Lisp system that can be used as +a basis for the Lisp operating system. It should already allow for +multiple environments, and it should be available on 64-bit +platforms. Preferably, this system should use as little C code as +possible and interact directly with the system calls of the +underlying kernel. + +\subsection{Create a single-user system as a Unix process} + +The next step is to transform the Common Lisp system into an +operating system in the sense of the API for users and +applications. This system would contain the object store, but +perhaps not access control functionality. + +When this step is accomplished, it is possible to write or adapt +applications such as text editors, inspectors, debuggers, GUI +interface libraries, etc. for the system. + +\subsection{Create device drivers} + +The final step is to replace the temporary Unix kernel with native +device drivers for the new system and to turn the system into a full +multi-user operating system. diff --git a/Documentation/chap-object-store.tex b/Documentation/chap-object-store.tex new file mode 100644 index 0000000..415e61f --- /dev/null +++ b/Documentation/chap-object-store.tex @@ -0,0 +1,110 @@ +\chapter{Object store} +\label{chap-object-store} + +The \emph{object store} is a system-wide database containing +any kind of objects. Each object is a \emph{capability}. + +An object in the store can optionally be associated with a certain +number of \emph{attributes}. An attribute is a \emph{pair} consisting +of the \emph{attribute name} and the \emph{attribute value}. The +attribute name is a symbol in the \texttt{keyword} package. The +attribute value can be any object. + +\begin{tabularx}{\linewidth}% +{|>{\setlength\hsize{.2\hsize}}X|% + >{\setlength\hsize{.8\hsize}}X|} +\hline +Keyword & Possible-values\\ +\hline\hline +\textbf{category} & + +The nature of the object such +as \textbf{movie}, \textbf{music}, \textbf{article}, \textbf{book}, \textbf{user +manual}, \textbf{dictionary}, \textbf{course}, \textbf{lecture}, +\textbf{recipe}, \textbf{program}, \textbf{bank statement}, +\textbf{email}. These would be chosen from an +editable set that is defined per user.\\ +\hline +\textbf{name} & + +A string that is displayed with the object, such as "A Dramatic +Turn of Events", "Three seasons", "Alternative energy".\\ +\hline +\textbf{author} & + +An object identifying a person, an organization, a company, +etc. \\ +\hline +\textbf{genre} & + +\textbf{progressive +metal}, \textbf{science}, \textbf{algorithms}, \textbf{garbage +collection}, \textbf{game}, \textbf{programming language +implementation}, \textbf{operating system}. These would be +chosen from an editable set that is defined per user.\\ +\hline +\textbf{format} & + +This attribute can be used to identify the file type of documents such +as \textbf{PDF}, \textbf{ogg/vorbis}, \textbf{MPEG4} \textbf{PNG}, in +which case the attribute can be assigned automatically, but also to +identify the source format of files in a directory containing +things like articles or user manuals, for +example \textbf{LaTeX}, \textbf{Texinfo}, \textbf{HTML}. These would +be chosen from an editable set that is defined per user. \\ +\hline +\end{tabularx} + +\begin{tabularx}{\linewidth}% +{|>{\setlength\hsize{.2\hsize}}X|% + >{\setlength\hsize{.8\hsize}}X|} +\hline +Keyword & Possible-values\\ +\hline\hline +\textbf{date of creation} & + +A date interval.\\ +\hline +\textbf{composer} & + +An object representing a person. On a compilation album there +can be more than one attribute of this kind. \\ +\hline +\textbf{language} & + +An object representing a natural language such +as \textbf{English}, \textbf{Vietnamese}, or a programming languages +such as \textbf{Lisp}, \textbf{Python}. These would +be chosen from an editable set that is defined per user. If +appropriate, a document can have several of these attributes, for +instance if some program uses multiple programming languages, or +if a document is written using several languages, such as a +dictionary. \\ +\hline +\textbf{duration} & + +An object representing a duration. \\ +\hline +\textbf{source control} & + +\textbf{GIT}, \textbf{SVN}, \textbf{CVS}, \textbf{darks}, etc. These +would be chosen from an editable set that is defined per user.\\ +\hline +\end{tabularx} + +In a typical operating system installation, there are many fairly +large objects such as movies, music files, pictures, etc. The amount +data associated with such an object that would be stored in the object +store is typically very small compared to the object itself. Even a +fairly modest text file probably has $10^4 -- 10^5$ characters in it, +whereas the meta-data probably takes up no more than $10^2 -- 10^3$ +bytes. It is therefore likely that the entire object store will fit +in main memory. Scanning the entire object store would then take at +most a few second of CPU time. For better performance, one or more +\emph{indexes} could be created. The objects could for instance be +divided by \emph{category}. + +Searching the object store amounts to defining a \emph{filter}, +i.e. a function that, given a set of keyword/value pairs returns +\emph{true} if and only if the corresponding object should be included +in the search result. diff --git a/Documentation/chap-protection.tex b/Documentation/chap-protection.tex new file mode 100644 index 0000000..0302284 --- /dev/null +++ b/Documentation/chap-protection.tex @@ -0,0 +1,78 @@ +\chapter{Protection} +\label{chap-protection} + +There are two kinds of protection that are important in an operating +system: + +\begin{itemize} +\item \emph{protecting different users from each other}. A user A + should not be able to access or destroy the data of some other user + B, other than if B explicitly permits it, and then only in ways that + are acceptable to B. +\item \emph{protecting the system from the users}. Users should be + able to access system resources such as memory and peripherals only + in controlled ways, so as to guarantee the integrity of the system. +\end{itemize} + +\section{Protecting users from each other} + +We use a combination of \emph{access control lists} and +\emph{capabilities}. All heap-allocated objects except \texttt{cons} +cells and (heap-allocated) numbers are manipulated through a +\emph{tagged pointer}. In addition to containing a type tag, the +pointer also contains an \emph{access tag}. The access tag consists +of the 4 most-significant bits of a 64-bit pointer. Before a pointer +is used to fetch an object from memory, the access bits are cleared. +A primitive operation to fetch the access tag of a pointer is +available to any user code. Each of the 4 bits represents a potential +\emph{access restriction}, the significance of which is up to the +programmer. A function that wishes to restrict permission to some +object can test the corresponding access bit and signal an error if +that bit is set. + +The author of some complex data structure may for instance grant +access to it only to certain other users. This would be done by +interpreting one of the access bits as \emph{read permission}, and by +having generic functions that access the data structures check that +this bit has the desired value (for instance in a \texttt{:before} +method). + +The access bits of a capability are determined when the object is +accessed through the object store. \seechap{chap-object-store} One of +the possible key/value pairs associated with the object in the object +store corresponds to the access permissions in the form of an +\emph{access control list}. A user who accesses the object from the +object store will be checked against the access control list and +appropriate access bits will be added to the object before it is given +to the user. + +\section{Protecting system from the users} + +In a typical modern operating system, the system is protected from the +users through the use of a \emph{mode} of execution of the processor, +which can be either \emph{user mode} or \emph{supervisor mode}. +Certain instructions are restricted to supervisor mode, such as +instructions for input/output or for remapping the address space. + +In \sysname{}, the normal mode of execution is \emph{supervisor mode}. +The code executed by the user is translated to machine code by a +\emph{trusted compiler} which is known not to generate code that, if +executed, might represent a risk to the integrity of the system. +Since no remapping of the address space is required as a result of an +\emph{interrupt} or a \emph{trap}, such events can be handled very +quickly. + +Occasionally, it might be useful to write or install some software +that is compiled to machine code by some compiler that can not be +trusted. The result of such a compilation or installation is a single +(possibly large) Lisp function. When this function is executed, the +mode of execution is switched to \emph{user mode}. As with +traditional modern operating systems, the code of such software has +its own \emph{address space}, which means that it can not directly +manipulate \sysname{} capabilities. Instead, it has to communicate +with the system through the user of \emph{system calls}. A +system-wide object is referred to by such code through an interposing +\emph{object descriptor}, much like a file descriptor in Unix. The +details of this mechanism have not yet been fully determined. + + diff --git a/Documentation/codify b/Documentation/codify new file mode 100755 index 0000000..ddc66b0 --- /dev/null +++ b/Documentation/codify @@ -0,0 +1,5 @@ +OUTFILE=$(echo $1 | sed -e 's/lisp/code/') +echo -n "\\" >$OUTFILE +echo "begin{Verbatim}[frame=single]" >>$OUTFILE +expand $1 >>$OUTFILE +echo "\\end{Verbatim}" >>$OUTFILE diff --git a/Documentation/lispos.bib b/Documentation/lispos.bib new file mode 100644 index 0000000..24d210e --- /dev/null +++ b/Documentation/lispos.bib @@ -0,0 +1,291 @@ +@book{Sedgewick:1996:IAA:227351, + author = {Sedgewick, Robert and Flajolet, Philippe}, + title = {An introduction to the analysis of algorithms}, + year = {1996}, + isbn = {0-201-40009-X}, + publisher = {Addison-Wesley Longman Publishing Co., Inc.}, + address = {Boston, MA, USA}, +} + + +@book{McConnell:2007:AA:1374801, + author = {McConnell, Jeffrey J.}, + title = {Analysis of Algorithms}, + year = {2007}, + isbn = {9780763707828}, + edition = {2}, + publisher = {Jones and Bartlett Publishers, Inc.}, + address = {USA}, +} + + +@article{Sleator:1985:SBS:3828.3835, + author = {Sleator, Daniel Dominic and Tarjan, Robert Endre}, + title = {Self-adjusting binary search trees}, + journal = {J. ACM}, + issue_date = {July 1985}, + volume = {32}, + number = {3}, + month = jul, + year = {1985}, + issn = {0004-5411}, + pages = {652--686}, + numpages = {35}, + url = {http://doi.acm.org/10.1145/3828.3835}, + doi = {10.1145/3828.3835}, + acmid = {3835}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@incollection{Bayer:2002:BDP:944331.944346, + author = {Bayer, Rudolf}, + chapter = {B-trees and databases, past and future}, + title = {Software pioneers}, + editor = {Broy, Manfred and Denert, Ernst}, + year = {2002}, + isbn = {3-540-43081-4}, + pages = {232--244}, + numpages = {13}, + url = {http://dl.acm.org/citation.cfm?id=944331.944346}, + acmid = {944346}, + publisher = {Springer-Verlag New York, Inc.}, + address = {New York, NY, USA}, +} + +@article{Adelson-Velskii_Landis_1962, + title = {An algorithm for the organization of information}, + volume = {3}, + url = {http://en.scientificcommons.org/19884302}, + number = {2}, + journal = {Soviet Mathematics Doklady}, + publisher = {JOINT PUBLICATIONS RESEARCH SERVICE WASHINGTON DC}, + author = {Adelson-Velskii, G M and Landis, E M}, + year={1962}, + pages={263--266} +} + +@article{Tan:1972:FIS:361573.361588, + author = {Tan, K. C.}, + title = {On Foster's information storage and retrieval using AVL trees}, + journal = {Commun. ACM}, + issue_date = {Sept. 1972}, + volume = {15}, + number = {9}, + month = sep, + year = {1972}, + issn = {0001-0782}, + pages = {843--}, + url = {http://doi.acm.org/10.1145/361573.361588}, + doi = {10.1145/361573.361588}, + acmid = {361588}, + publisher = {ACM}, + address = {New York, NY, USA}, + keywords = {binary trees, information retrieval, information storage, search trees}, +} + +@inproceedings{Wilson:1992:UGC:645648.664824, + author = {Wilson, Paul R.}, + title = {Uniprocessor Garbage Collection Techniques}, + booktitle = {Proceedings of the International Workshop on Memory Management}, + series = {IWMM '92}, + year = {1992}, + isbn = {3-540-55940-X}, + pages = {1--42}, + numpages = {42}, + url = {http://dl.acm.org/citation.cfm?id=645648.664824}, + acmid = {664824}, + publisher = {Springer-Verlag}, + address = {London, UK, UK}, +} + +@book{Jones:2011:GCH:2025255, + author = {Jones, Richard and Hosking, Antony and Moss, Eliot}, + title = {The Garbage Collection Handbook: The Art of Automatic Memory Management}, + year = {2011}, + isbn = {1420082795, 9781420082791}, + edition = {1st}, + publisher = {Chapman \& Hall/CRC}, +} + +@article{Andersson:1999:GBT:308088.308094, + author = {Andersson, Arne}, + title = {General balanced trees}, + journal = {J. Algorithms}, + issue_date = {Jan. 1999}, + volume = {30}, + number = {1}, + month = jan, + year = {1999}, + issn = {0196-6774}, + pages = {1--18}, + numpages = {18}, + url = {http://dx.doi.org/10.1006/jagm.1998.0967}, + doi = {10.1006/jagm.1998.0967}, + acmid = {308094}, + publisher = {Academic Press, Inc.}, + address = {Duluth, MN, USA}, +} + +@article{Stout:1986:TRO:6592.6599, + author = {Stout, Q. F and Warren, B. L}, + title = {Tree rebalancing in optimal time and space}, + journal = {Commun. ACM}, + issue_date = {Sept. 1986}, + volume = {29}, + number = {9}, + month = sep, + year = {1986}, + issn = {0001-0782}, + pages = {902--908}, + numpages = {7}, + url = {http://doi.acm.org/10.1145/6592.6599}, + doi = {10.1145/6592.6599}, + acmid = {6599}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@article{Waters:1992:UNC:1039991.1039996, + author = {Waters, Richard C.}, + title = {Using the new common Lisp pretty printer}, + journal = {SIGPLAN Lisp Pointers}, + issue_date = {April-June 1992}, + volume = {V}, + number = {2}, + month = apr, + year = {1992}, + issn = {1045-3563}, + pages = {27--34}, + numpages = {8}, + url = {http://doi.acm.org/10.1145/1039991.1039996}, + doi = {10.1145/1039991.1039996}, + acmid = {1039996}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@INPROCEEDINGS{Waters89xp:a, + author = {Richard C. Waters}, + title = {XP: A Common Lisp Pretty Printing System}, + booktitle = {A.I. Memo 1102a, MIT Artificial Intelligence Laboratory}, + year = {1989} +} + +BibTeX | BibTeX (beta) | EndNote | ACM Ref + +@techreport{Huang:1990:FSM:898863, + author = {Huang, Bing and Langston, Michael A.}, + title = {Fast Stable Merging and Sorting in Constant Extra Space}, + year = {1990}, + source = {http://www.ncstrl.org:8900/ncstrl/servlet/search?formname=detail\&id=oai%3Ancstrlh%3Autk_cs%3Ancstrl.utk_cs%2F%2FUT-CS-90-106}, + publisher = {University of Tennessee}, + address = {Knoxville, TN, USA}, +} + +@article{Huang:1988:PIM:42392.42403, + author = {Huang, Bing-Chao and Langston, Michael A.}, + title = {Practical in-place merging}, + journal = {Commun. ACM}, + issue_date = {March 1988}, + volume = {31}, + number = {3}, + month = mar, + year = {1988}, + issn = {0001-0782}, + pages = {348--352}, + numpages = {5}, + url = {http://doi.acm.org/10.1145/42392.42403}, + doi = {10.1145/42392.42403}, + acmid = {42403}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@article{Katajainen:1996:PIM:642136.642138, + author = {Katajainen, Jyrki and Pasanen, Tomi and Teuhola, Jukka}, + title = {Practical in-place mergesort}, + journal = {Nordic J. of Computing}, + issue_date = {Spring 1996}, + volume = {3}, + number = {1}, + month = mar, + year = {1996}, + issn = {1236-6064}, + pages = {27--40}, + numpages = {14}, + url = {http://dl.acm.org/citation.cfm?id=642136.642138}, + acmid = {642138}, + publisher = {Publishing Association Nordic Journal of Computing}, + address = {Finland}, + keywords = {in-place algorithms, mergesort, sorting}, +} + +@inproceedings{Clinger:1990:RFP:93542.93557, + author = {Clinger, William D.}, + title = {How to read floating point numbers accurately}, + booktitle = {Proceedings of the ACM SIGPLAN 1990 conference on Programming language design and implementation}, + series = {PLDI '90}, + year = {1990}, + isbn = {0-89791-364-7}, + location = {White Plains, New York, USA}, + pages = {92--101}, + numpages = {10}, + url = {http://doi.acm.org/10.1145/93542.93557}, + doi = {10.1145/93542.93557}, + acmid = {93557}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@inproceedings{Burger:1996:PFN:231379.231397, + author = {Burger, Robert G. and Dybvig, R. Kent}, + title = {Printing floating-point numbers quickly and accurately}, + booktitle = {Proceedings of the ACM SIGPLAN 1996 conference on Programming language design and implementation}, + series = {PLDI '96}, + year = {1996}, + isbn = {0-89791-795-2}, + location = {Philadelphia, Pennsylvania, USA}, + pages = {108--116}, + numpages = {9}, + url = {http://doi.acm.org/10.1145/231379.231397}, + doi = {10.1145/231379.231397}, + acmid = {231397}, + publisher = {ACM}, + address = {New York, NY, USA}, + keywords = {floating-point printing, run-time systems}, +} + +@TECHREPORT{Gay90correctlyrounded, + author = {David M. Gay}, + title = {Correctly Rounded Binary-Decimal and Decimal-Binary Conversions}, + institution = {Numerical Analysis Manuscript 90-10, AT\&T Bell Laboratories}, + year = {1990} +} + +@inproceedings{Doligez:1993:CGG:158511.158611, + author = {Doligez, Damien and Leroy, Xavier}, + title = {A concurrent, generational garbage collector for a multithreaded implementation of ML}, + booktitle = {Proceedings of the 20th ACM SIGPLAN-SIGACT symposium on Principles of programming languages}, + series = {POPL '93}, + year = {1993}, + isbn = {0-89791-560-7}, + location = {Charleston, South Carolina, USA}, + pages = {113--123}, + numpages = {11}, + url = {http://doi.acm.org/10.1145/158511.158611}, + doi = {10.1145/158511.158611}, + acmid = {158611}, + publisher = {ACM}, + address = {New York, NY, USA}, +} + +@book{Kiczales:1991:AMP:574212, + author = {Kiczales, Gregor and Rivieres, Jim Des}, + title = {The Art of the Metaobject Protocol}, + year = {1991}, + isbn = {0262111586}, + publisher = {MIT Press}, + address = {Cambridge, MA, USA}, +} + diff --git a/Documentation/lispos.cb b/Documentation/lispos.cb new file mode 100644 index 0000000..e69de29 diff --git a/Documentation/lispos.cb2 b/Documentation/lispos.cb2 new file mode 100644 index 0000000..e69de29 diff --git a/Documentation/lispos.tex b/Documentation/lispos.tex new file mode 100644 index 0000000..059647b --- /dev/null +++ b/Documentation/lispos.tex @@ -0,0 +1,109 @@ +\documentclass[11pt]{book} +\newcommand{\Comment}[1]{\begin{center}\tt #1 \end{center}} +% \usepackage{doublespace} +\usepackage[paperwidth=7.5in, paperheight=9.25in, + inner=35mm, outer=25mm, + tmargin=25mm, bmargin=30mm]{geometry} +\usepackage[T1]{fontenc} +\usepackage[utf8]{inputenc} +\usepackage{alltt} +\usepackage{moreverb} +\usepackage{fancyvrb} +\usepackage{epsfig} +\usepackage{makeidx} +\usepackage{float} +\usepackage{color} +\usepackage{amsthm} +\usepackage{changebar} +\usepackage{tabularx} +\usepackage[nottoc]{tocbibind} +\usepackage{shadow} +\setlength\sdim{2mm} + +\floatplacement{figure}{!htbp} + +\newfloat{codefragment}{!htbp}{cod}[chapter] +\floatname{codefragment}{Code fragment} + +\newtheorem{theorem}{Theorem}[chapter] +\newtheorem{exercise}{Exercise}[chapter] +\newtheorem{definition}{Definition}[chapter] + +\setlength{\parskip}{0.3cm} +\setlength{\parindent}{0cm} + +\def\lispout#1{\underline{#1}} + +\def\mop{MOP} +\def\bs{$\backslash$} +\def\lispobj#1{\textsl{#1}} +\def\lispobjindex#1{\lispobj{#1}\index{#1@\lispobj{#1}}} +\def\syntax#1{\texttt{#1}} +\def\metavar#1{\textit{#1}} +\def\keyword#1{\code{\textbf{#1}}} +\def\code#1{\textsf{#1}} +\def\fixme#1{\footnote{\color{red}FIXME: #1}} + +\def\sysname{LispOS} + +\def\inputfig#1{\input #1} +\def\inputtex#1{\input #1} +\def\inputal#1{\input #1} +\def\inputcode#1{\input #1} + +\inputtex{logos.tex} +\inputtex{refmacros.tex} +\inputtex{other-macros.tex} + +\newenvironment{itemize0}{ +\begin{itemize} +\setlength{\parskip}{0cm}% +} +{\end{itemize}} + +\newenvironment{enumerate0}{ +\begin{enumerate} +\setlength{\parskip}{0cm}% +} +{\end{enumerate}} + +\newenvironment{smalltt}{ +\begin{alltt} +\small +} +{\end{alltt}} + +%UPDATE version number when it changes. +\def\majorversion{0} +\def\minorversion{1} +\def\bookversion{\majorversion{}.\minorversion{}} +\title{{\Huge \sysname{}\\ +Specification of a Lisp operating system.}} + +\author{Robert Strandh} + +\date{2013} + +\makeindex +\begin{document} +\pagenumbering{roman} + +\maketitle + +\newpage + +{\setlength{\parskip}{0cm} +\tableofcontents} + +\inputtex{chap-intro.tex} +\inputtex{chap-object-store.tex} +\inputtex{chap-protection.tex} +\inputtex{chap-environments.tex} + +\bibliography{lispos}{} +\bibliographystyle{alpha} + +\printindex + +\end{document} + diff --git a/Documentation/logos.tex b/Documentation/logos.tex new file mode 100644 index 0000000..041ee32 --- /dev/null +++ b/Documentation/logos.tex @@ -0,0 +1,46 @@ +% Programming languages. +\def\cl{Common Lisp} +\def\clos{CLOS} +\def\closs{Common Lisp Object System} +\def\lisp{Lisp} +\def\hs{HyperSpec} +\def\bs{$\backslash$} +\def\lispobj#1{\textsl{#1}} +\def\emphindex#1{\emph{#1}\index{#1}} +\def\syntax#1{\texttt{#1}} +\def\metavar#1{\textit{#1}} +\def\code#1{\textsf{#1}} +\def\FIXME#1{\footnote{\color{red}FIXME: #1}} +\def\java{Java} +\def\csharp{C\#} +\def\javascript{JavaScript} +\def\php{PHP} +\def\self{Self} +\def\perl{Perl} +\def\python{Python} +\def\ruby{Ruby} +\def\smalltalk{Smalltalk} +\def\simula{Simula} +\def\clanguage{C} +\def\cplusplus{C++} +\def\fortran{Fortran} +\def\pascal{Pascal} +\def\algol{Algol} +\def\ml{ML} +\def\haskell{Haskell} +\def\miranda{Miranda} +\def\cobol{COBOL} +\def\plone{PL/I} +\def\emacs{Emacs} + +% Operating systems and kernels. +\def\multics{Multics} +\def\unix{UNIX}% The Wikipedia article says this is the way it is written. +\def\gnulinux{GNU/Linux} +\def\linux{Linux} +\def\mach{Mach} +\def\atlas{Atlas} +\def\vms{VMS} +\def\ibmvmcms{VM/CMS} +\def\msdos{MS DOS} +\def\genera{Genera} diff --git a/Documentation/other-macros.tex b/Documentation/other-macros.tex new file mode 100644 index 0000000..5735152 --- /dev/null +++ b/Documentation/other-macros.tex @@ -0,0 +1,6 @@ +\def\sll{simply linked list} +\def\Sll{Simply linked list} +\def\dll{doubly linked list} +\def\Dll{Doubly linked list} +\def\ttt{2-3 tree} + diff --git a/Documentation/refmacros.tex b/Documentation/refmacros.tex new file mode 100644 index 0000000..4befd44 --- /dev/null +++ b/Documentation/refmacros.tex @@ -0,0 +1,50 @@ +\newcommand{\refalgo}[1]{algorithm~\ref{#1}}% +\newcommand{\refAlgo}[1]{Algorithm~\ref{#1}}% +\newcommand{\seealgo}[1]{(See \refAlgo{#1}.)}% +\newcommand{\seealgox}[2]{(See \refAlgo{#1} #2.)}% + +\newcommand{\refpart}[1]{part~\ref{#1}}% +\newcommand{\refPart}[1]{Part~\ref{#1}}% +\newcommand{\seepart}[1]{(See \refPart{#1}.)}% +\newcommand{\seepartx}[2]{(See \refPart{#1} #2.)}% + +\newcommand{\refchap}[1]{chapter~\ref{#1}}% +\newcommand{\refChap}[1]{Chapter~\ref{#1}}% +\newcommand{\seechap}[1]{(See \refChap{#1}.)}% +\newcommand{\seechapx}[2]{(See \refChap{#1} #2.)}% + +\newcommand{\refapp}[1]{appendix~\ref{#1}}% +\newcommand{\refApp}[1]{Appendix~\ref{#1}}% +\newcommand{\seeapp}[1]{(See \refApp{#1}.)}% +\newcommand{\seeappx}[2]{(See \refApp{#1} #2.)}% + +\newcommand{\refsec}[1]{section~\ref{#1}}% +\newcommand{\refSec}[1]{Section~\ref{#1}}% +\newcommand{\seesec}[1]{(See \refSec{#1}.)}% +\newcommand{\seesecx}[2]{(See \refSec{#1} #2.)}% + +\newcommand{\reffig}[1]{figure~\ref{#1}}% +\newcommand{\refFig}[1]{Figure~\ref{#1}}% +\newcommand{\seefig}[1]{(See \refFig{#1}.)}% +\newcommand{\seefigx}[2]{(See \refFig{#1} #2.)}% + +\newcommand{\refdef}[1]{definition~\ref{#1}}% +\newcommand{\refDef}[1]{Definition~\ref{#1}}% +\newcommand{\seedef}[1]{(See \refDef{#1}.)}% +\newcommand{\seedefx}[2]{(See \refDef{#1} #2.)}% + +\newcommand{\reftheo}[1]{theorem~\ref{#1}}% +\newcommand{\refTheo}[1]{Theorem~\ref{#1}}% +\newcommand{\seetheo}[1]{(See \refTheo{#1}.)}% +\newcommand{\seetheox}[2]{(See \refTheo{#1} #2.)}% + +\newcommand{\refexo}[1]{exercise~\ref{#1}}% +\newcommand{\refExo}[1]{Exercise~\ref{#1}}% +\newcommand{\seeexo}[1]{(See \refExo{#1}.)}% +\newcommand{\seeexox}[2]{(See \refExo{#1} #2.)}% + +\newcommand{\refcode}[1]{code fragment~\ref{#1}}% +\newcommand{\refCode}[1]{Code fragment~\ref{#1}}% +\newcommand{\seecode}[1]{(See \refCode{#1}.)}% +\newcommand{\seecodex}[2]{(See \refCode{#1} #2.)}% + diff --git a/Documentation/strip-dependence b/Documentation/strip-dependence new file mode 100755 index 0000000..fd0645d --- /dev/null +++ b/Documentation/strip-dependence @@ -0,0 +1,12 @@ +#!/bin/sh +CHAINE=$1 +MOTIF="^\\\\$CHAINE\{.*\}" +shift +for i in $* +do + egrep $MOTIF $i \ + | sed "s/^\\\\$CHAINE{\(.*\)}/\1/" \ + | tr ['\n'] [' '] +done + + diff --git a/Documentation/tex-dependencies b/Documentation/tex-dependencies new file mode 100755 index 0000000..ac18392 --- /dev/null +++ b/Documentation/tex-dependencies @@ -0,0 +1,10 @@ +#!/bin/sh + +#set -x +TEXFILES=$(./strip-dependence inputtex $1) +echo -n $TEXFILES +for i in $TEXFILES +do + echo -n " " $(./tex-dependencies $i) +done +echo