Operating system support of programming language implementaion

Francois-Rene Rideau rideau@clipper.ens.fr
Fri, 17 Mar 95 20:09:16 +0100


   I am working on a paper here at Clemson Universtiy on: Operating 
   system support for programming languages implementaion, and was wonder
   if anyone out here on the 'net' might be able to direct me in the 
   subject.  Any help would be greatly appreciated.
			      thanks,
				 James Bragg

   Ahem. I don't know what you mean exactly, and it depends on what you
call "Operating system", and what you call "language", and what kind of
support you expect, whether you are interested only in available widespread
OSes, are also in custom OSes or even research OSes.
   UNIX and alikes offer minimalistic support, with very architecture dependent
memory mapping capabilities (would be useful for efficient garbage collecting
persistent languages). Their official philosophy is "just abstract the hardware
and let the user do what he wants", which results in "let's do nothing, let
the language have all the hassle, with no support or security in sharing,
and bloated horrid interfaces to devices".

   To me, the OS is everything that you can rely the people you're
communicating to to have (or be able to get). Thus, if I'm only talking
to people using emacs, emacs is the OS, etc. Any Turing-equivalent software
that allows full (even if filtered) access to the hardware is equivalent to
any other in functionality, and anything can be implemented on top of it
(well, there may still be different resource limitations as different systems
offer different memory waste).
   Thus, emacs or other lisp systems generally offer support for linking
with external C/whatever code, but you typically have to reboot for it to
take effects (however more and more dynamic loading packages are being
developped for more and more systems); but you could very well write
a C->LISP translator. Thus, in most system, the support is virtual,
and nobody uses it. But still it exists. Will you consider such support ?
   Oberon, FORTH, ADA, Smalltalk are OSes in themself.
   Many languages are not implemented yet, but may well be. Will you consider
them ? Some are implemented on top of many abstractions (e.g. C) on top of
existing OSes. Will you consider these ?
   All OSes do impose constraints on software running on top of it. Now
POSIX is different from a particular implementation that may offer more
support, which almost nobody will use to stay POSIX compliant. What about
these ?
   In OSes that use a flat address space(s), the key points are:
how is memory segmented and mapped, can the language implementor map
addresses at will ? What happens when interrupts (signals) happen ?
If your language supports persistence, you will be anxious about the OS
buffer flushing semantics, and if you share data, you'll look at the OS
security semantics.
   Then you'll see that all standard OSes give you no security warranty at all,
and you'll have to pray for everything going well.



   Well, personally, I want to write a new kind of OS, with support for
high-level persistent programming. This OS may be implemented on top of
POSIX, though it will inherit its unsecurity; I will also implement it on
386 class machines. What's important about an OS, whatever it be, is the
semantics of its operations. UNIX and Windows are just horrible bloats whose
instructions have chaotic unsecure low-level semantics. LISP systems or other
programming environments for high-level languages have much cleaner semantics,
but seldom grant you access to the hardware to extend the system in a
low-level fashion (i.e. adding drivers, writing routines that need be faster
than what the system already provides, etc). What prevents high-level
systems to grant such low-level access is portability upon bloated OSes.
I know it is possible to interface the low-level abstractions in a
high-level way, if only someone is willing to write the proper OS layer,
so that implementing a new language would just be a matter of changing the
high-level front end (beware: a front end can be a batch compiler, but also
an interpreter or a dynamic interaction system).
   All this may seem unclear and confuse, but this message is a tight place
to write all I mean.
   I am coordinating the TUNES free project for a new kind of OS, which
will eventually include its own language, and support for any other language
through generic and specific language-to-language translation facilities,
about which you may find more information in the URL below in my .sig.
I've not written down all my ideas about OS support for languages, but if
you ask me clear questions, I will try to bring clear answers there.

   Sorry if I disturbed you. Feedback (even negative) welcome.
I'm interested in whatever paper you may publish, btw.

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
Join the TUNES project for a computing system based on computing freedom !
		   TUNES is a Useful, Not Expedient System
WWW URL: http://acacia.ens.fr:8080/home/rideau/Tunes/