What would people be interested in seeing in a Lisp dialect designed
specifically for system programming (by which I mean things at the
level of OS development, etc.)?
So far, I'm thinking:
- Compiled (no brainer, IMHO)
- Very easy inlined code (assembly or C)
- An asynchronously message-passing threads system (as seen in Erlang)
- All the Lispy goodness
I'm interested in doing something along these lines because:
- I'm just getting into Lisp and I figure making one is a good way to
understand it
- There doesn't seem to be a good way to do this in CL or Scheme (if
there is, I'm all ears)
- I'm interested in both compiler design and OS development
Sorry to both you all with random ponderings,
Greg
·············@gmail.com wrote:
> What would people be interested in seeing in a Lisp dialect designed
> specifically for system programming (by which I mean things at the
> level of OS development, etc.)?
>
> So far, I'm thinking:
> - Compiled (no brainer, IMHO)
> - Very easy inlined code (assembly or C)
You might want to look at ECL (http://ecls.sourceforge.net), which uses
a lisp-to-C compiler and can thus inline C code easily. We build both
UFFI and CFFI (sort of standard Lisp foreign function interfaces) on
top of those inline forms.
> - All the Lispy goodness
Full ANSI Common Lisp compliance, not so god at MOP (Meta-Object
Protocol)
> - An asynchronously message-passing threads system (as seen in Erlang)
This you might have to code yourself. However, ECL is based on native
threads which probably do not scale well to thousands of processes
which is what Erlang programmers are used to. But incorporating
userland threads like Erlang should not be too difficult, since indeed
that was what EcoLisp (the parent of ECL) used.
Juanjo
Juanjo wrote:
> ·············@gmail.com wrote:
> > What would people be interested in seeing in a Lisp dialect designed
> > specifically for system programming (by which I mean things at the
> > level of OS development, etc.)?
> >
> > So far, I'm thinking:
> > - Compiled (no brainer, IMHO)
> > - Very easy inlined code (assembly or C)
>
> You might want to look at ECL (http://ecls.sourceforge.net), which uses
> a lisp-to-C compiler and can thus inline C code easily. We build both
> UFFI and CFFI (sort of standard Lisp foreign function interfaces) on
> top of those inline forms.
That link seems to be broken, at least at the moment. However, I'm very
interested...is it feasible, in your opinion, to use ECL for something
like OS development?
> > - All the Lispy goodness
>
> Full ANSI Common Lisp compliance, not so god at MOP (Meta-Object
> Protocol)
That's fine, I'm not a fan of OO myself.
> > - An asynchronously message-passing threads system (as seen in Erlang)
>
> This you might have to code yourself. However, ECL is based on native
> threads which probably do not scale well to thousands of processes
> which is what Erlang programmers are used to. But incorporating
> userland threads like Erlang should not be too difficult, since indeed
> that was what EcoLisp (the parent of ECL) used.
No worries, that shouldn't be too much of a problem.
Paolo Amoroso wrote:
> Movitz: a Common Lisp x86 development platform
> http://common-lisp.net/project/movitz/
I've looked at Movitz, but there doesn't seem to be an explanation
anywhere of how to use it as the base of an OS. (i.e. what functions
you can use to directly access the hardware, etc.)
Thanks for the help,
Greg
·············@gmail.com wrote:
> Paolo Amoroso wrote:
> > Movitz: a Common Lisp x86 development platform
> > http://common-lisp.net/project/movitz/
>
> I've looked at Movitz, but there doesn't seem to be an explanation
> anywhere of how to use it as the base of an OS. (i.e. what functions
> you can use to directly access the hardware, etc.)
Okay, so I lied. I haven't looked at it in a while. I just did...and
there's actually quite a bit of nice documentation. I'm going to try
out Movitz and maybe ECL.
·············@gmail.com wrote:
> Juanjo wrote:
> > You might want to look at ECL (http://ecls.sourceforge.net)
>
> That link seems to be broken, at least at the moment.
Yes, I will contact the SourceForge people about it.
> However, I'm very
> interested...is it feasible, in your opinion, to use ECL for something
> like OS development?
The only difficulties are:
1) The garbage collector expects some support from the system, such as
mmap(), signals, etc. You can revisit the older, conservative garbage
collector which was shipped with EcoLisp and which we keep in the
source tree.
2) ECL assumes a decent C library behind. For instance, I/O is done
using ANSI C streams; the filesystem is managed using POSIX functions,
etc; we use sprintf, strlen, etc...
If ECL already sits on top of a OS kernel, such as Mach, Linux, *BSD,
etc, there should be no problem. Otherwise you should reimplement some
minimal C/POSIX backend. But this is true also if you intend to do C
programming.
Go to the ECL mailing list if you find problems with ECL or want to
comment your needs, wishes, etc.
Regards,
Juanjo
·············@gmail.com writes:
> I've looked at Movitz, but there doesn't seem to be an explanation
> anywhere of how to use it as the base of an OS. (i.e. what functions
> you can use to directly access the hardware, etc.)
I agree that the documentation is rather limited, but finding such
information shouldn't be too difficult. There's the accessor
muerte:io-port for accessing the I/O adress space, and similarly the
accessor muerte:memref for the regular memory address space, for
starters. These operators even work at the REPL, if you want to play
around with it.
--
Frode Vatvedt Fjeld
What wo
·············@gmail.com writes:
> uld people be interested in seeing in a Lisp dialect designed
> specifically for system programming (by which I mean things at the
> level of OS development, etc.)?
>
> So far, I'm thinking:
> - Compiled (no brainer, IMHO)
> - Very easy inlined code (assembly or C)
> - An asynchronously message-passing threads system (as seen in Erlang)
> - All the Lispy goodness
>
> I'm interested in doing something along these lines because:
> - I'm just getting into Lisp and I figure making one is a good way to
> understand it
> - There doesn't seem to be a good way to do this in CL or Scheme (if
> there is, I'm all ears)
> - I'm interested in both compiler design and OS development
Have a look at http://www.coyotos.org and its BitC language/compiler.
There's also pre-scheme, and of course, Common Lisp, as in Movitz.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You never feed me.
Perhaps I'll sleep on your face.
That will sure show you.
> - I'm interested in both compiler design and OS development
Although the problems involved in using Lisp(s) for this sort of thing
are, indeed, interesting (and others have pointed out BitC, for
example), IMHO these are both dead fields and you ought to spend your
neural cycles elsewhere. No new OS can do better than Linux or Windows,
and these (esp. Linux) will rapidly adsorb (yes, I mean "d") any new
concepts that arise and are found to be useful, so you might as well
just start with Linux. If you are proposing hacking Lisp-based Linux or
Windows add-on components, that makes some sense, but if you are
proposing to build new OSs then the only sensible target for this is
special purpose hardware, for example a LispOS (for lack of a better
term) for your R/C helicopter, and that sort of thing. Even in those
domains, the hardware is usually powerful enough that microLinuxs
(Lini?) can run on them. This said, it would be great to be able to
program my R/C heli in Lisp (that is, if I could get it off the ground
to begin with without crashing!), so if that's what you're on about, I
say: Go For It! :-)
ps. Compiler design doesn't need to have OS-level Lisps. You can do
compiler design and development perfectly well -- in fact, EXTREMELY
well -- in Lisp-as-is. What is it that you think is missing that needs
new capabilities in this area?
········@gmail.com wrote:
> ps. Compiler design doesn't need to have OS-level Lisps. You can do
> compiler design and development perfectly well -- in fact, EXTREMELY
> well -- in Lisp-as-is. What is it that you think is missing that needs
> new capabilities in this area?
Correct...but I was interested in making my own bare-metal Lisp, or
experimenting with some other ones, THEN making my own. Just for the
experience. Not because I think it will be a better OS than Linux or
Windows (maybe Windows--not hard. Just kidding, but...) Making my own
Lisp which would double as an OS would include both OS and compiler
design.
·········@gmail.com" <········@gmail.com> writes:
> neural cycles elsewhere. No new OS can do better than Linux or Windows,
Or OS X, which is currently "doing better" than either of those.
> Or OS X, which is currently "doing better" than either of those.
Depends upon what dimension you're scoring along, but, point taken; I
was counting OSX as "linux". (Although properly both should just be
called "Unix".)
·········@gmail.com" <········@gmail.com> writes:
> No new OS can do better than Linux or Windows, and these
> (esp. Linux) will rapidly adsorb (yes, I mean "d") any new concepts
> that arise and are found to be useful, so you might as well just
> start with Linux. [..]
I agree that Linux, Windows, and the BSDs do what they do very well,
and trying to more or less re-implement them in lisp would be mostly
pointless. However, they are all based on the certain (the very same!)
basic concepts and assumptions. The interesting design-spaces for
e.g. a lisp-OS are those that cannot reasonably be absorbed by Linux
&Co.
Looking at history, the basic design choices of current OS-es grew out
of very specific circumstances: Extreme resource scarcity, and many
users per machine. Obviously this playing field has changed: For many
or most things, resources are plentiful, and oftentimes there is one
or more machines per user. Where it used to be that performance
eclipsed other considerations for a good user experience, it seems
reasonable now that the ever-present error messages such as "Error:
General exception 34242352" and the like, very poor integration of
applications, poor maintainability and limited possibilities for
customization of applications and the system as a whole, might be
addressed (better) with a fresh take on things.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> ·········@gmail.com" <········@gmail.com> writes:
>
> > No new OS can do better than Linux or Windows, and these
> > (esp. Linux) will rapidly adsorb (yes, I mean "d") any new concepts
> > that arise and are found to be useful, so you might as well just
> > start with Linux. [..]
>
> I agree that Linux, Windows, and the BSDs do what they do very well,
> and trying to more or less re-implement them in lisp would be mostly
> pointless. However, they are all based on the certain (the very same!)
> basic concepts and assumptions. The interesting design-spaces for
> e.g. a lisp-OS are those that cannot reasonably be absorbed by Linux
> &Co.
>
> Looking at history, the basic design choices of current OS-es grew out
> of very specific circumstances: Extreme resource scarcity, and many
> users per machine. Obviously this playing field has changed: For many
> or most things, resources are plentiful, and oftentimes there is one
> or more machines per user. Where it used to be that performance
> eclipsed other considerations for a good user experience, it seems
> reasonable now that the ever-present error messages such as "Error:
> General exception 34242352" and the like, very poor integration of
> applications, poor maintainability and limited possibilities for
> customization of applications and the system as a whole, might be
> addressed (better) with a fresh take on things.
>
Hi Frode, is Movitz still active? Also, how difficult do you think it
would be to convert the compiler to emit ARM instructions instead of
X86?
Cheers
Brad
"bradb" <··············@gmail.com> writes:
> Hi Frode, is Movitz still active? Also, how difficult do you think
> it would be to convert the compiler to emit ARM instructions instead
> of X86?
Movitz is still active, even if movement is slightly glacial. I would
estimate it to be quite a bit of work to retarget Movitz. Probably
just having it emit ARM instructions would not be so difficult, but
presumably there would be other architectural aspects that would
change also, requiring a rethink of some central Movitz design
components.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld wrote:
> ·········@gmail.com" <········@gmail.com> writes:
>
> > No new OS can do better than Linux or Windows, and these
> > (esp. Linux) will rapidly adsorb (yes, I mean "d") any new concepts
> > that arise and are found to be useful, so you might as well just
> > start with Linux. [..]
>
> I agree that Linux, Windows, and the BSDs do what they do very well,
> and trying to more or less re-implement them in lisp would be mostly
> pointless. However, they are all based on the certain (the very same!)
> basic concepts and assumptions. The interesting design-spaces for
> e.g. a lisp-OS are those that cannot reasonably be absorbed by Linux
> &Co.
>
> Looking at history, the basic design choices of current OS-es grew out
> of very specific circumstances: Extreme resource scarcity, and many
> users per machine. Obviously this playing field has changed: For many
> or most things, resources are plentiful, and oftentimes there is one
> or more machines per user. Where it used to be that performance
> eclipsed other considerations for a good user experience, it seems
> reasonable now that the ever-present error messages such as "Error:
> General exception 34242352" and the like, very poor integration of
> applications, poor maintainability and limited possibilities for
> customization of applications and the system as a whole, might be
> addressed (better) with a fresh take on things.
I think that that problem is best attacked at the application level.
If application program runtimes are improved so ugly faults are less
likely then the situation improves, without the need for new OSes which
would require troublesome migration.
I don't think this is the ideal solution, but I think it's the most
practical one.
Frode Vatvedt Fjeld wrote:
> > Looking at history, the basic design choices of current OS-es grew
> > out of very specific circumstances: Extreme resource scarcity, and
> > many users per machine. Obviously this playing field has changed:
> > For many or most things, resources are plentiful, and oftentimes
> > there is one or more machines per user. Where it used to be that
> > performance eclipsed other considerations for a good user
> > experience, it seems reasonable now that the ever-present error
> > messages such as "Error: General exception 34242352" and the like,
> > very poor integration of applications, poor maintainability and
> > limited possibilities for customization of applications and the
> > system as a whole, might be addressed (better) with a fresh take
> > on things.
"Rob Thorpe" <·······@realworldtech.com> writes:
> I think that that problem is best attacked at the application level.
> If application program runtimes are improved so ugly faults are less
> likely then the situation improves, without the need for new OSes
> which would require troublesome migration.
Considering the last thirty years or so of development on this
evolutionary path, I must say that I am not convinced that we are
converging towards realizing the full potential of what software can
do.
Regarding migration costs, it seems to me we are collectively stuck in
some strange paradoxia where operating systems must remain compatible
across decades, yet very little software remains in use across periods
of 2-3 years.
> I don't think this is the ideal solution, but I think it's the most
> practical one.
What is "practical" is of course entirely dependant on what your goals
are.
--
Frode Vatvedt Fjeld
·············@gmail.com wrote:
> What would people be interested in seeing in a Lisp dialect designed
> specifically for system programming (by which I mean things at the
> level of OS development, etc.)?
I would like to see something which could interface with mobile devices
and smaller platforms. It is very heartening to see games on mobiles
using the J2ME. If Java can do it, I can't think of any reason why it
can't be done in Lisp too. I would love to see an implementation of
Lisp similar to GOAL
http://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
Alok
·············@gmail.com writes:
> What would people be interested in seeing in a Lisp dialect designed
> specifically for system programming (by which I mean things at the
> level of OS development, etc.)?
[...]
> - There doesn't seem to be a good way to do this in CL or Scheme (if
> there is, I'm all ears)
See also:
Movitz: a Common Lisp x86 development platform
http://common-lisp.net/project/movitz/
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
·············@gmail.com wrote:
> What would people be interested in seeing in a Lisp dialect designed
> specifically for system programming (by which I mean things at the
> level of OS development, etc.)?
I'm not sure you need a new 'dialect' of Lisp for that. Existing
Lisp dialects may need some additional features in
the form of a specific implementation.
There were a few Lisps used to develop Lisp-based operating systems
or Lisp-services on top of a kernel. Some can be said about
using Lisp in current operating systems (say, Linux, *BSD*, Windows,
Cisco's
IOS, ...). Sometimes you might find a hidden embedded Lisp for
debugging,
sometimes you find implementations embedded in
the kernel (Schemix). SCSH is also very interesting.
In the history dialects like InterLisp (D) and Lisp Machine Lisp have
been used to implement whole operating systems.
The latter you can study seeing the source. Brad Parker has written an
emulator
for the CADR Lisp Machine. The source to the OS
is available (mostly) and also the manual.
See here:
http://www.unlambda.com/
You can see that he also has links to a few other emulators.
Good candidates are also:
* Movitz (already mentioned)
** targets bare PC / Intel hardware
* http://common-lisp.net/pipermail/movitz-devel/2006-June/000218.html
describes an attempt to get movitz working with Parallels on a MacBook.
* ECL (already mentioned), Common Lisp
** embeddedable
** very portable
* CLISP, Common Lisp
** compact with virtual machine and compiler for its VM
** very portable
* OpenMCL, Common Lisp
** compact with native code compiler
** inline assembler and good FFI
Some more obscure stuff:
Not much is known about 'L' (A Common Lisp for Embedded Systems)
http://www.cs.cmu.edu/~chuck/pubpg/LUV-1995.html
Little is also known about Minima, a real-time OS written in ZetaLisp
used in ATM switches.
There was an early version of Dylan (Ralph, when it was still a Lisp),
that was used
by Apple to write an operating system. Which unfortunately has not been
released.
>
> So far, I'm thinking:
> - Compiled (no brainer, IMHO)
> - Very easy inlined code (assembly or C)
> - An asynchronously message-passing threads system (as seen in Erlang)
> - All the Lispy goodness
>
> I'm interested in doing something along these lines because:
> - I'm just getting into Lisp and I figure making one is a good way to
> understand it
> - There doesn't seem to be a good way to do this in CL or Scheme (if
> there is, I'm all ears)
> - I'm interested in both compiler design and OS development
>
> Sorry to both you all with random ponderings,
> Greg