From: utzoo!decvax!harpo!eagle!mit-vax!masscomp!tjt
Newsgroups: net.unix-wizards
Title: Re: Is Unix Really This Bad?
Article-I.D.: masscomp.107
Posted: Fri Mar 11 17:00:33 1983
Received: Sun Mar 13 07:14:37 1983
References: sri-unix.5226

There are several specific deficiencies of UNIX with respect to NIL
(New Implementation of LISP) that I am aware of:

1) The assembler/linker environment is extremely simple: the
assembler has no macros. The UNIX assemblers were intended primarily
as the final pass of a compiler and therefore macros were considered
unnecessary. Preprocessors such as m4 are not equivalent to e.g. DEC
MACRO-11 and MACRO-32 which implement conditionals based on internal
assembler state such as whether a symbol is defined. However, I do
not know offhand whether m4 is in fact sufficient for the types of
macros used in NIL, and I am unfamiliar with the NIL source code.

The bigger problem that NIL runs into is the restriction to only 3
program sections -- .text, .data and .bss.  The VAX/UNIX assembler is
a little better but still highly restrictive.  NIL takes advantage of
multiple program sections to initialize several symbol tables
throughout the source code by having each module append
initializations to separate program sections.  Early versions of C
had only fairly simple mechanisms for initializing static variables.
Even now there are few high-level languages that allow the type of
sophisticated static initializations possible by appending or merging
initializations in separate source modules (perhaps ADA, but I would
have to check a manual to find out for sure).

If you don't think this would be useful, take a look at the source of
James Gosling's EMACS if you have it: the symbol table is initialized
by executable code in each module.  This makes it slightly easier to
add new primitives although it is necessary to both define the code
for the primitive and to include initialization code to add the
primitive to the internal symbol table.  A richer language for
distributed data initializations and suitable macros would allow
these to be better integrated. i.e. the code for the primitive could
be immediately preceded by the initialization of the symbol table
information.

Obviously, there are alternatives to the approach used by NIL, but
the biggest problem is either the time required to convert the source
code and/or to build appropriate tools to solve the problem
differently.

2) NIL expects to manage its address space as a collection of pages,
each with independent access rights.  In particular, when NIL
dynamically loads a new function it would like to make the new "text"
segment read only.  The address space of a NIL process often becomes
alternating "text" and "data" pages.  This memory management scheme
is incompatible with the three-segments used in standard unix (text,
data and stack).  This is not an insurmountable (or even a serious)
barrier to implementation of dynamic linking as Franz Lisp clearly
demonstrates.  However, it is clearly useful to make all code
read-only if possible when debugging.  This type of memory access
control is not possible under 4.1BSD, although may be possible under
4.2 (again, I would have to check a manual).  In any case, this is
an example of system service provided by most "paged" operating
systems not currently provided by UNIX.

The lack of independently settable access modes for individual pages
does cause insurmountable problems with NIL's stack management.
I don't remember the details, but the VMS implementation of NIL
maintained two "stacks" separated by a hole in virtual memory: when
the upper stack ran into the hole, the lower stack was moved down and
more memory allocated to the upper stack.  I think the lower "stack"
was in fact some other type of expandable data structure.  In any
case, the point is not whether this is a good scheme for memory
allocation but rather that it is impossible to implement in 4.1BSD.

In summary, NIL and UNIX are largely incompatible as they currently
exist.  In some ways, this is not surprising since NIL was apparently
not written with portability in mind.  Much of the early source code
was written in macro-32 and bliss-32.  This is at least partially due
to the initial lack of a NIL compiler.  However, I don't think much
thought was devoted to which parts of NIL were operating system
dependent and/or machine dependent.

At the same time, UNIX lacks some features that make porting the
current version of NIL impossible, and may very well have made any
implementation of NIL awkward.  I think it is clear that UNIX
operating systems for larger machines (i.e. with paged address
spaces) will need to evolve, and I think that 4.2BSD is a step in the
right direction.  However, it is unfortunate that any such evolution
of UNIX will unavoidably conflict with UNIX on non-paged machines,
and must be born as the price of progress.