I have been kind of amazed at all the software that is written in C,
especially for example on a unix or linux system.
I am curious. Do you think that a full operating system(meaning
applications and possibly low-level drivers) could be written in lisp?
Take ls.c. Could that be written in Lisp. It seems like a good thing
for software engineering?
Berlin Brown
I have always wanted to develop a linux-KERNEL based operating system
with a complete new set of applications (not written in C, if I can
help it).
I will keep these comments in mind.
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <4303d6F1l2vv2U1@individual.net>
ramza2 wrote:
> I have always wanted to develop a linux-KERNEL based operating system
> with a complete new set of applications (not written in C, if I can
> help it).
Then personally I wouldn't go for reimplementing the classic Unix tools,
like /bin/ls. They are cryptic and far too low level to be useful
(well, they are, but in an ugly kind of way).
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
>
> Then personally I wouldn't go for reimplementing the classic Unix tools,
> like /bin/ls. They are cryptic and far too low level to be useful
> (well, they are, but in an ugly kind of way).
>
I think the key would be to lisp-ize the operating system to make
it/lisp ubiquitous.
On Mon, 16 Jan 2006 09:24:09 +0100, <·····@bigpond.net.au> wrote:
>
>>
>> Then personally I wouldn't go for reimplementing the classic Unix tools,
>> like /bin/ls. They are cryptic and far too low level to be useful
>> (well, they are, but in an ugly kind of way).
>>
>
> I think the key would be to lisp-ize the operating system to make
> it/lisp ubiquitous.
>
Well have a cross eyed look at Genera a all Lisp OS developed by Symbolics
Inc.
http://www.symbolics.com/Genera-1.htm
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <4317ldF1leq4aU1@individual.net>
·····@bigpond.net.au wrote:
>> Then personally I wouldn't go for reimplementing the classic Unix tools,
>> like /bin/ls. They are cryptic and far too low level to be useful
>> (well, they are, but in an ugly kind of way).
>>
>
> I think the key would be to lisp-ize the operating system to make
> it/lisp ubiquitous.
Sure, but if you want to live on top of a general purpose OS that the
user is running along with several applications they need, then it's
cool to build on top of an existing OS. Still, all OSes I've seen or
used so far could use a decent high-level environment that isn't
inflexible and written in tiddly-fiddly C.
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
Ulrich Hobelmann wrote:
> ramza2 wrote:
> > I have always wanted to develop a linux-KERNEL based operating system
> > with a complete new set of applications (not written in C, if I can
> > help it).
>
> Then personally I wouldn't go for reimplementing the classic Unix tools,
> like /bin/ls. They are cryptic and far too low level to be useful
> (well, they are, but in an ugly kind of way).
Though there are some fairly cryptic tools in Unix 'ls' is hardly one
of them, I can hardly think of a more simple and obvious command line
tool. It's also pretty hard to argue that it's not useful, if you work
at the command line level then you need to list the contents of
directories.
If you work only with a GUI of course, then it isn't useful.
Rob Thorpe wrote:
> Though there are some fairly cryptic tools in Unix 'ls' is hardly one
> of them, I can hardly think of a more simple and obvious command line
> tool. It's also pretty hard to argue that it's not useful, if you work
> at the command line level then you need to list the contents of
> directories.
> If you work only with a GUI of course, then it isn't useful.
One problem is that ls, like all UNIX tools, suffers from the
"everything is a stream of ASCII octets, separated by LF characters"
problem.
Extracting actual data from that listing depends, for instance, on
arbitrary column widths in the ls implementation not being exceeded,
and reverse-engineering things like the symbolic link notation, etc.,
etc. Hardly a robust link in a classic UNIX pipeline.
It works fine for human consumption, but for a real program, you
really need to break down and walk through the directory calling stat()
(or whatever the right low-level incantation is.)
Another solution would be to return a list of objects capable of
providing the relevant information on a file, that, when sent to a
terminal or GUI for the user, formats itself as sufficiently pretty
text.
··············@hotmail.com wrote:
> Rob Thorpe wrote:
>
> > Though there are some fairly cryptic tools in Unix 'ls' is hardly one
> > of them, I can hardly think of a more simple and obvious command line
> > tool. It's also pretty hard to argue that it's not useful, if you work
> > at the command line level then you need to list the contents of
> > directories.
> > If you work only with a GUI of course, then it isn't useful.
>
> One problem is that ls, like all UNIX tools, suffers from the
> "everything is a stream of ASCII octets, separated by LF characters"
> problem.
>
> Extracting actual data from that listing depends, for instance, on
> arbitrary column widths in the ls implementation not being exceeded,
> and reverse-engineering things like the symbolic link notation, etc.,
> etc. Hardly a robust link in a classic UNIX pipeline.
>
> It works fine for human consumption, but for a real program, you
> really need to break down and walk through the directory calling stat()
> (or whatever the right low-level incantation is.)
Yes. The programmer should generally use the library interface, I
thought we were talking about the user.
> Another solution would be to return a list of objects capable of
> providing the relevant information on a file, that, when sent to a
> terminal or GUI for the user, formats itself as sufficiently pretty
> text.
Or if ls had a particular flag that meant "send output to be parsed by
something else"
GNU ls does this to some extent.
I've written successful scripts that parse the output of ls, but there
are some hazards.
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <431h2iF1l9b39U1@individual.net>
Rob Thorpe wrote:
> Though there are some fairly cryptic tools in Unix 'ls' is hardly one
> of them, I can hardly think of a more simple and obvious command line
> tool. It's also pretty hard to argue that it's not useful, if you work
> at the command line level then you need to list the contents of
> directories.
> If you work only with a GUI of course, then it isn't useful.
Sorry. What I meant was that "ls", like most other Unix tools, has a
huge set of options that may or may not differ for different Unices.
That's fairly cryptic to me. If you write C code to the POSIX API
you're quite safe, but it'd still be much better if you just had a
simple API to get information about certain objects.
One example related to 'ls' is the FTP program. Since the exact output
of a "ls" or "ls -l" isn't exactly specified (or I don't know where;
maybe POSIX does specify it??), graphical FTP programs have to guess how
to parse the information coming from the server. The standard doesn't
really specify anything (especially it doesn't say IF ftp should output
information as "ls -l"; some clients seem to send "LIST -l" to the
server, but the standard doesn't say that LIST takes any arguments
except a filename).
A consistent, very high-level environment would be cool, and it could
encapsulate (like I hear Gnome and KDE do) pseudo-file-systems like tar,
ftp, zip, databases, or CD images; many things that you could do on
Unix, but only with extensive re-coding of many operations that are
fixed at far too low a level. Most of Unix spends its time parsing one
of numerous Unix ad-hoc data formats (or sedding or awking around),
where s-exps would be an obvious alternative.
I think it'd be much easier to do that in Lisp than in C dialects.
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
Ulrich Hobelmann wrote:
> Rob Thorpe wrote:
> > Though there are some fairly cryptic tools in Unix 'ls' is hardly one
> > of them, I can hardly think of a more simple and obvious command line
> > tool. It's also pretty hard to argue that it's not useful, if you work
> > at the command line level then you need to list the contents of
> > directories.
> > If you work only with a GUI of course, then it isn't useful.
>
> Sorry. What I meant was that "ls", like most other Unix tools, has a
> huge set of options that may or may not differ for different Unices.
> That's fairly cryptic to me.
I think it's important to be comparable here, Unix has some nastiness,
but so do many other systems.
'ls' is no less nasty than say 'open' in common lisp, which has loads
of options, some of which are specific to compilers, others which are
standard.
In both cases it often doesn't matter much, since most of the options
are never used. I've never used any option to 'ls' except 'l' (long)
and 'a' (all). Similarly I've not used many of the option to 'open'.
> If you write C code to the POSIX API
> you're quite safe, but it'd still be much better if you just had a
> simple API to get information about certain objects.
Do you mean for the user or the programmer? For the programmer it's
more uniform than for the user, but it's not that difficult for either.
> One example related to 'ls' is the FTP program. Since the exact output
> of a "ls" or "ls -l" isn't exactly specified (or I don't know where;
> maybe POSIX does specify it??)
No, the output of 'ls' is very regular, many scripts that do matching
operations on it would not work without this. The problem is the "ls"
used in ftp programs.
>, graphical FTP programs have to guess how
> to parse the information coming from the server. The standard doesn't
> really specify anything (especially it doesn't say IF ftp should output
> information as "ls -l"; some clients seem to send "LIST -l" to the
> server, but the standard doesn't say that LIST takes any arguments
> except a filename).
>
> A consistent, very high-level environment would be cool, and it could
> encapsulate (like I hear Gnome and KDE do) pseudo-file-systems like tar,
> ftp, zip, databases, or CD images; many things that you could do on
> Unix, but only with extensive re-coding of many operations that are
> fixed at far too low a level.
The intention in Unix is that a great many things can be represented as
files. That streams are a high-level not a low-level concept. The
problem with it is that it isn't followed rigourously. The right way
(from the Unix p.o.v.) to do ftp, tar, zip etc is to make it possible
to access them through filesystems.
The problem is that this hasn't been done. GNU Hurd can use ftp as a
filesystem, and I think they're a Linux module to do it too, but it's
not common.
In Unix adding a VFS layer in a library (as Gnome and KDE have) is
really rather hacky. If you're thinking of a different or new OS
though, this may not be the case.
> Most of Unix spends its time parsing one
> of numerous Unix ad-hoc data formats (or sedding or awking around),
No it doesn't. Unix programs hardly ever use sed or awk internally.
Though they do often have nasty parsing code inside them.
Scripts sometimes do a fair amount of awking around.
> where s-exps would be an obvious alternative.
Yes.
> I think it'd be much easier to do that in Lisp than in C dialects.
It would be, but it's been done in C, there isn't much reason to redo
most of it.
I've mentioned much of the above just because it's important to be fair
when criticising a system.
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <4320rfF1lefjgU1@individual.net>
Rob Thorpe wrote:
>> If you write C code to the POSIX API
>> you're quite safe, but it'd still be much better if you just had a
>> simple API to get information about certain objects.
>
> Do you mean for the user or the programmer? For the programmer it's
> more uniform than for the user, but it's not that difficult for either.
Luckily for the programmer most options and structs are specified, yes.
>> One example related to 'ls' is the FTP program. Since the exact output
>> of a "ls" or "ls -l" isn't exactly specified (or I don't know where;
>> maybe POSIX does specify it??)
>
> No, the output of 'ls' is very regular, many scripts that do matching
> operations on it would not work without this. The problem is the "ls"
> used in ftp programs.
Well, that was only an example anyway. But it's annoying that for
everything you do in Unix, you need to build some kind of parser,
especially when you do it in C without a good string library.
> The intention in Unix is that a great many things can be represented as
> files. That streams are a high-level not a low-level concept. The
> problem with it is that it isn't followed rigourously. The right way
> (from the Unix p.o.v.) to do ftp, tar, zip etc is to make it possible
> to access them through filesystems.
Yes. Some systems allow user-level file systems and mounts done by the
user. Plan 9 goes further. But since almost nobody uses Plan 9, it'd
be cool to have an abstract API that maps to files, but is higher-level.
>> Most of Unix spends its time parsing one
>> of numerous Unix ad-hoc data formats (or sedding or awking around),
>
> No it doesn't. Unix programs hardly ever use sed or awk internally.
> Though they do often have nasty parsing code inside them.
> Scripts sometimes do a fair amount of awking around.
Scripts do. Other programs usually parse directly in C. For that
reason line-oriented file formats are encouraged (also see ESR's The Art
of Unix Programming on this). Of course all of this introduces numerous
opportunities for buffer overflows to creep in.
>> I think it'd be much easier to do that in Lisp than in C dialects.
>
> It would be, but it's been done in C, there isn't much reason to redo
> most of it.
I'm not really satisfied with any of current high-level APIs on OSes,
nor with current OSes in general. It's mostly '70s technology, except
the Mac, which is '80s technology (Mach and Next).
> I've mentioned much of the above just because it's important to be fair
> when criticising a system.
Sure, I'm only saying that many things could be MUCH better. As far as
their job goes, many programmers do a fairly good job. You can't simply
build a new OS or powerful API without lots of money behind you and your
boss saying that your idea is ok, even though it might take years to persue.
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
Ulrich Hobelmann wrote:
> Rob Thorpe wrote:
> >> If you write C code to the POSIX API
> >> you're quite safe, but it'd still be much better if you just had a
> >> simple API to get information about certain objects.
> >
> > Do you mean for the user or the programmer? For the programmer it's
> > more uniform than for the user, but it's not that difficult for either.
I think you're criticising Unix and C together. These days we don't
really have to use them together, it's possible to pick other
implementation languages, which helps a great deal.
> > I've mentioned much of the above just because it's important to be fair
> > when criticising a system.
>
> Sure, I'm only saying that many things could be MUCH better. As far as
> their job goes, many programmers do a fairly good job.
There are things that could be better in the details, yes. Much
better, probably.
Looking at the alternatives around today the free unices are some of
the best OSes around. Undoubtably it's possible to build a better OS
though.
> You can't simply
> build a new OS or powerful API without lots of money behind you and your
> boss saying that your idea is ok, even though it might take years to persue.
Hmm, I'm not sure about that. It's been done in the past :).
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <4327fpF1kvoqeU1@individual.net>
Rob Thorpe wrote:
> Ulrich Hobelmann wrote:
>> Rob Thorpe wrote:
>>>> If you write C code to the POSIX API
>>>> you're quite safe, but it'd still be much better if you just had a
>>>> simple API to get information about certain objects.
>>> Do you mean for the user or the programmer? For the programmer it's
>>> more uniform than for the user, but it's not that difficult for either.
>
> I think you're criticising Unix and C together. These days we don't
> really have to use them together, it's possible to pick other
> implementation languages, which helps a great deal.
I'm not complaining about the underlying Unix concept of files and
directories, and simple byte-streams. I'm only complaining about the
actual systems built on top of it, with *everything* done in totally
ad-hoc ways. It isn't really about C, but of course C plays a role, due
to its lack of good abstractions and modularity. The Unix system of
linking and loading also plays a role.
>> You can't simply
>> build a new OS or powerful API without lots of money behind you and your
>> boss saying that your idea is ok, even though it might take years to persue.
>
> Hmm, I'm not sure about that. It's been done in the past :).
Yes, but today nobody would pay money for an operating system or
platform. Languages and compilers, frameworks and platforms are free.
Only services sell. Maybe with a good marketing team you could convince
people that buying a good platform is cheaper than hiring thousands of
service hours, though. Fighting against IBM, Sun, Java, and Linux ;)
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
Ulrich Hobelmann <···········@web.de> writes:
> Well, that was only an example anyway. But it's annoying that for
> everything you do in Unix, you need to build some kind of parser,
> especially when you do it in C without a good string library.
This is a misconception.
Everything needs some kind of parsing, but the deepest loops.
For example something as "simple" as RPC involves a lot of unparsing
and parsing. Lisp-to-C FFI involves parsing the lisp arguments, and
building a C call stack frame, with conversion of the values, and
vice-versa.
If unix commands output s-expr, they'd have to unparse them (implement
PRINT), and parse them (implement READ).
If unix commands communicated via pipe with binary data structures,
each program would still have to do the unparse/parse dance around
pointers and different language FFI.
If unix commands communicated via shared memory, the same.
Even inside a single program, you may have some "parsing" to do, when
you transform data structures to adapt them between two optimized
algorithms. Everytime you map a list to a hash table, or hash table
to an array or whatever, you're unparsing and parsing between two
phases of the program.
What may be annoying, is that the format of the output of interactive
commands, is not standardized and for user interaction commands, not
easy to parse.
--
__Pascal Bourguignon__ http://www.informatimago.com/
ATTENTION: Despite any other listing of product contents found
herein, the consumer is advised that, in actuality, this product
consists of 99.9999999999% empty space.
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <432782F1bs0raU1@individual.net>
Pascal Bourguignon wrote:
> Ulrich Hobelmann <···········@web.de> writes:
>> Well, that was only an example anyway. But it's annoying that for
>> everything you do in Unix, you need to build some kind of parser,
>> especially when you do it in C without a good string library.
>
> This is a misconception.
> Everything needs some kind of parsing, but the deepest loops.
Yes, but is the grammar more or less regular, or a decade of accumulated
cruft? Is it maybe a simple meta-grammar, like s-exps, or a complicated
one, but still standard, like XML?
I'm not complaining about the un/marshalling of data, but about the need
to hand-code parsers all the time.
Modern software uses XML for everything, which is a solution, though I'd
replace libxml with something 10x as small. It doesn't matter a lot,
unless you care to hand-manipulate files once in a while.
> For example something as "simple" as RPC involves a lot of unparsing
> and parsing. Lisp-to-C FFI involves parsing the lisp arguments, and
> building a C call stack frame, with conversion of the values, and
> vice-versa.
Oh sure, and it has its uses.
> If unix commands output s-expr, they'd have to unparse them (implement
> PRINT), and parse them (implement READ).
Sure, but a tiny library (a few Kb) can do that easily, and no need to
worry about buffer overflows in your own code.
> If unix commands communicated via pipe with binary data structures,
> each program would still have to do the unparse/parse dance around
> pointers and different language FFI.
>
> If unix commands communicated via shared memory, the same.
No, shared mem is the exception; you can simply pass around whole structs.
> Even inside a single program, you may have some "parsing" to do, when
> you transform data structures to adapt them between two optimized
> algorithms. Everytime you map a list to a hash table, or hash table
> to an array or whatever, you're unparsing and parsing between two
> phases of the program.
Yes. Maybe some kind of macro can make that more easy, but overall it's
not that hard to write a few lines of conversion code.
> What may be annoying, is that the format of the output of interactive
> commands, is not standardized and for user interaction commands, not
> easy to parse.
Exactly.
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
ramza2 wrote:
> I have been kind of amazed at all the software that is written in C,
> especially for example on a unix or linux system.
>
> I am curious. Do you think that a full operating system(meaning
> applications and possibly low-level drivers) could be written in lisp?
Yes.
> Take ls.c. Could that be written in Lisp. It seems like a good thing
> for software engineering?
Which ls.c?
> Berlin Brown
From: Troels Henriksen
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <8764olma4r.fsf@sigkill.dk>
Nathan Baum <···········@btinternet.com> writes:
> Which ls.c?
I assume he means the standard /bin/ls program on Unix systems. And
yes, it could be written in Lisp, but I don't know why you would want
to that.
--
\ Troels "Athas" Henriksen
/\ sigkill.dk/blog (Danish)
From: Edi Weitz
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <uvewltcxt.fsf@agharta.de>
On 15 Jan 2006 13:04:32 -0800, "ramza2" <············@gmail.com> wrote:
> I have been kind of amazed at all the software that is written in C,
> especially for example on a unix or linux system.
>
> I am curious. Do you think that a full operating system(meaning
> applications and possibly low-level drivers) could be written in
> lisp?
This is an FAQ. For an example of a full OS (including everything)
written in Lisp see here:
<http://en.wikipedia.org/wiki/Lisp_machine>
For something more recent see this one:
<http://common-lisp.org/project/movitz/>
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
ramza2 wrote:
> I have been kind of amazed at all the software that is written in C,
> especially for example on a unix or linux system.
>
> I am curious. Do you think that a full operating system(meaning
> applications and possibly low-level drivers) could be written in lisp?
>
> Take ls.c. Could that be written in Lisp. It seems like a good thing
> for software engineering?
>
>
> Berlin Brown
>
There was another thread on this earlier, and the near unanimous answer
was YES! You can do OS development in Lisp, you just have to have a
Lisp interpreter that can run on bare metal or teach a Lisp native-code
compiler how to compile a freestanding executable with no functions
relying on the operating system.
On the other hand, should you code an OS in Lisp? My answer is that
unless you want a lot of extra work, no. Operating systems interact
with the machine at a very low level and Lisp is designed for processing
data rather than talking to the machine. Example: interrupts. In order
to write an interrupt handler in Lisp you must first write the same
assembler stub you would for a C kernel, then write some low-level code
to translate the interrupt and register information on the stack into
Lisp objects. Those objects are then passed to your Lisp interrupt
handler. Finally, the handler returns something (perhaps a processed
version of the register objects), the returned objects along with the
old register objects are processed back into something the processor
understands, and the interrupt returns.
If you really want to do an OS in Lisp, I think you should code the
mechanisms in a lower-level language and write the policies in Lisp.
From: Tin Gherdanarra
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <436sc8F1lj3miU1@individual.net>
Eli Gottlieb wrote:
> ramza2 wrote:
>
SNIP
>
> On the other hand, should you code an OS in Lisp? My answer is that
> unless you want a lot of extra work, no.
Many hands make light work.
Operating systems interact
> with the machine at a very low level and Lisp is designed for processing
> data rather than talking to the machine.
You are right, but. It is easier to make Lisp talking to the
hardware than it is to make C or C++ work for sophisticated
projects. And you know THAT has been done quite often.
Example: interrupts. In order
> to write an interrupt handler in Lisp you must first write the same
> assembler stub you would for a C kernel, then write some low-level code
> to translate the interrupt and register information on the stack into
> Lisp objects.
Well, yes and no. A Lisp OS would probably run on a virtual machine
anyway, so all you have to do is feed the interrupt into the
virtual machine. You could make the interrupt set a flag and have
the VM interpreter poll that flag. This assumes that the
nittygritty-lowlevel stuff is written in Lisp, too. This is not
a requirement, though. On Unix you usually don't deal with interrupts
either. All you need is a driver architecture that snaps into
the virtual machine interpreter and/or the Lisp's OOP system.
Those objects are then passed to your Lisp interrupt
> handler. Finally, the handler returns something (perhaps a processed
> version of the register objects), the returned objects along with the
> old register objects are processed back into something the processor
> understands, and the interrupt returns.
This assumes that the OS is native, binary code compiled from
Lisp -- probably a bad idea anyway. (Unfortunately, Movitz goes
into this direction).
>
> If you really want to do an OS in Lisp, I think you should code the
> mechanisms in a lower-level language and write the policies in Lisp.
I think you should put interrupt-handling, talking to hardware ports
and talking to memory into the VM interpreter, who
is also the scheduler. (Virtual) Memory and disk caching go
into the garbage collector who can swap out "old" allocated chunks. The
garbage collector also enforces security
by tagging data with its owner and the privileges, not only what
type of data it is and how old it is.
The system's GUI model is written in a sandboxed, object oriented
lisp that is basically a lisp listener that can be reprogrammed
over a wire. You upload and override your buttons, menus and
window-backgrounds to the machine that actually displays
these elements, whip up the overridden main window and tell the uploadee
"I'm your application, call me back as soon as someone clicks on
a button or a menu item. DON'T call me back as long as someone just
moves the mouse
cursor or windows around. You know how to handle that. Talk to
you later."
Such a system would not require a shell. Lisp would be its shell
and its scripting language. No pipe symbols required -- use
lazy evaluation of shared fifos
instead. Such a system would not run as fast as Linux, of course,
but it would probably be smaller and much easier to program and
use. And the lisp interpreter or the compiler for the vm
could be built in such a way that
it can automatically spread purely functional code over multiple
CPUs for parallel execution -- probably a big asset for multi-multi-core
machines, the wave of the future.
Tin Gherdanarra wrote:
> Eli Gottlieb wrote:
>
>> ramza2 wrote:
>>
> SNIP
>
>>
>> On the other hand, should you code an OS in Lisp? My answer is that
>> unless you want a lot of extra work, no.
>
>
> Many hands make light work.
>
> Operating systems interact
>
>> with the machine at a very low level and Lisp is designed for
>> processing data rather than talking to the machine.
>
>
> You are right, but. It is easier to make Lisp talking to the
> hardware than it is to make C or C++ work for sophisticated
> projects. And you know THAT has been done quite often.
>
> Example: interrupts. In order
>
>> to write an interrupt handler in Lisp you must first write the same
>> assembler stub you would for a C kernel, then write some low-level
>> code to translate the interrupt and register information on the stack
>> into Lisp objects.
>
>
> Well, yes and no. A Lisp OS would probably run on a virtual machine
> anyway, so all you have to do is feed the interrupt into the
> virtual machine. You could make the interrupt set a flag and have
> the VM interpreter poll that flag. This assumes that the
> nittygritty-lowlevel stuff is written in Lisp, too. This is not
> a requirement, though. On Unix you usually don't deal with interrupts
> either. All you need is a driver architecture that snaps into
> the virtual machine interpreter and/or the Lisp's OOP system.
>
>
> Those objects are then passed to your Lisp interrupt
>
>> handler. Finally, the handler returns something (perhaps a processed
>> version of the register objects), the returned objects along with the
>> old register objects are processed back into something the processor
>> understands, and the interrupt returns.
>
>
> This assumes that the OS is native, binary code compiled from
> Lisp -- probably a bad idea anyway. (Unfortunately, Movitz goes
> into this direction).
>
>>
>> If you really want to do an OS in Lisp, I think you should code the
>> mechanisms in a lower-level language and write the policies in Lisp.
>
>
> I think you should put interrupt-handling, talking to hardware ports
> and talking to memory into the VM interpreter, who
> is also the scheduler. (Virtual) Memory and disk caching go
> into the garbage collector who can swap out "old" allocated chunks. The
> garbage collector also enforces security
> by tagging data with its owner and the privileges, not only what
> type of data it is and how old it is.
>
> The system's GUI model is written in a sandboxed, object oriented
> lisp that is basically a lisp listener that can be reprogrammed
> over a wire. You upload and override your buttons, menus and
> window-backgrounds to the machine that actually displays
> these elements, whip up the overridden main window and tell the uploadee
> "I'm your application, call me back as soon as someone clicks on
> a button or a menu item. DON'T call me back as long as someone just
> moves the mouse
> cursor or windows around. You know how to handle that. Talk to
> you later."
>
> Such a system would not require a shell. Lisp would be its shell
> and its scripting language. No pipe symbols required -- use
> lazy evaluation of shared fifos
> instead. Such a system would not run as fast as Linux, of course,
> but it would probably be smaller and much easier to program and
> use. And the lisp interpreter or the compiler for the vm
> could be built in such a way that
> it can automatically spread purely functional code over multiple
> CPUs for parallel execution -- probably a big asset for multi-multi-core
> machines, the wave of the future.
However, the original post was about LOW-LEVEL operating system
development, ie: on bare metal. If you are so eager to see an operating
system that runs on a VM then write one.
I do agree, however, that certain tasks like abstracting machine
interrupts and I/O ports into Lisp objects should be the job of software
below what we would now call the OS. Most likely it would be the
bare-metal Lisp interpreter's job to perform the grunt machine-talking work.
From: Tin Gherdanarra
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <439hhnF1medl9U1@individual.net>
Eli Gottlieb wrote:
> Tin Gherdanarra wrote:
>
>> Eli Gottlieb wrote:
>>
>>> ramza2 wrote:
>>>
>> SNIP
>>
>>>
>>> On the other hand, should you code an OS in Lisp? My answer is that
>>> unless you want a lot of extra work, no.
>>
>>
>>
>> Many hands make light work.
>>
>> Operating systems interact
>>
>>> with the machine at a very low level and Lisp is designed for
>>> processing data rather than talking to the machine.
>>
>>
>>
>> You are right, but. It is easier to make Lisp talking to the
>> hardware than it is to make C or C++ work for sophisticated
>> projects. And you know THAT has been done quite often.
>>
>> Example: interrupts. In order
>>
>>> to write an interrupt handler in Lisp you must first write the same
>>> assembler stub you would for a C kernel, then write some low-level
>>> code to translate the interrupt and register information on the stack
>>> into Lisp objects.
>>
>>
>>
>> Well, yes and no. A Lisp OS would probably run on a virtual machine
>> anyway, so all you have to do is feed the interrupt into the
>> virtual machine. You could make the interrupt set a flag and have
>> the VM interpreter poll that flag. This assumes that the
>> nittygritty-lowlevel stuff is written in Lisp, too. This is not
>> a requirement, though. On Unix you usually don't deal with interrupts
>> either. All you need is a driver architecture that snaps into
>> the virtual machine interpreter and/or the Lisp's OOP system.
>>
>>
>> Those objects are then passed to your Lisp interrupt
>>
>>> handler. Finally, the handler returns something (perhaps a processed
>>> version of the register objects), the returned objects along with the
>>> old register objects are processed back into something the processor
>>> understands, and the interrupt returns.
>>
>>
>>
>> This assumes that the OS is native, binary code compiled from
>> Lisp -- probably a bad idea anyway. (Unfortunately, Movitz goes
>> into this direction).
>>
>>>
>>> If you really want to do an OS in Lisp, I think you should code the
>>> mechanisms in a lower-level language and write the policies in Lisp.
>>
>>
>>
>> I think you should put interrupt-handling, talking to hardware ports
>> and talking to memory into the VM interpreter, who
>> is also the scheduler. (Virtual) Memory and disk caching go
>> into the garbage collector who can swap out "old" allocated chunks.
>> The garbage collector also enforces security
>> by tagging data with its owner and the privileges, not only what
>> type of data it is and how old it is.
>>
>> The system's GUI model is written in a sandboxed, object oriented
>> lisp that is basically a lisp listener that can be reprogrammed
>> over a wire. You upload and override your buttons, menus and
>> window-backgrounds to the machine that actually displays
>> these elements, whip up the overridden main window and tell the uploadee
>> "I'm your application, call me back as soon as someone clicks on
>> a button or a menu item. DON'T call me back as long as someone just
>> moves the mouse
>> cursor or windows around. You know how to handle that. Talk to
>> you later."
>>
>> Such a system would not require a shell. Lisp would be its shell
>> and its scripting language. No pipe symbols required -- use
>> lazy evaluation of shared fifos
>> instead. Such a system would not run as fast as Linux, of course,
>> but it would probably be smaller and much easier to program and
>> use. And the lisp interpreter or the compiler for the vm
>> could be built in such a way that
>> it can automatically spread purely functional code over multiple
>> CPUs for parallel execution -- probably a big asset for
>> multi-multi-core machines, the wave of the future.
>
> However, the original post was about LOW-LEVEL operating system
> development, ie: on bare metal.
That's right, and I told you guys that this is doable, but
not practical. Lisp machines had special hardware for a
reason. "On the bare metal" should be understood as: There
is no OS in the conventional sense, the VM for the Lisp is
the OS.
> If you are so eager to see an operating
> system that runs on a VM then write one.
Funny you'd mention it. That's precisely what I've started to do last
week (Thursday, I think it was). It will take a while, though,
because I'm of very limited abilities. And automated garbage
collection is not as trivial as I thought. But since the MIT
guys and Symbolics have thrown in the towel, and since nobody
else is doing it, I have to step in and create that world-dominating
LispOS of the future. Wish me luck.
>
> I do agree, however, that certain tasks like abstracting machine
> interrupts and I/O ports into Lisp objects should be the job of software
> below what we would now call the OS. Most likely it would be the
> bare-metal Lisp interpreter's job to perform the grunt machine-talking
> work.
This is not a matter of either/or. A reduced low-level lisp can be
used to handle interrupts, memory segments and I/O-ports. An extreme
case is Movitz which uses an x86 assembler with a sexp-syntax. This
works very well, but it is conceivable to wrap a typeless, word-oriented
langague like BCPL around a lisp-syntax. So the programmer of a lisp
system has ample room for shuffling responsibilites between the
macro-assembler, some Lisp/C/assembler-bastard, the VM, the high-level
implementation and who bootstraps whom and who abstracts away what. In this
sense, a LispOS resembles a ForthOS, Forth being the other unpopular
syntaxless language with meta-programming facilities. The difference is
that such Forth system have actually and routinely been built from
scratch a thousand times, with varying degrees of virtualization
of the hardware and varying priorities. In contrast to Forth, Lisp
does not have such a deep tradition on this terrain.
As an aside, I believe that virtual machines and automated garbage
collection will play an increasingly prominent role on all levels
of computing. Eventually the microprocessor industry will adopt this
trend and modify their architectures with GC and VMs in mind. This
does not mean that Intel will start to make Lisp-Machine CPUs, but
they will end up making something like Java-Machine CPUs or
.NET-Machine CPUs. Today's microprocessors are more or less optimized
for running something like a Unix-kernel (including various
Windows-kernels), but this is a dead end. I'm afraid that a lot
of interesting things will happen to address the shortcomings of
today's "Dinosaurs are ruling the earth, and it sucks"-issues,
but without lisp on the map. I mean, none of the more prominent
vms (java, .net or parrot) knows how to cons or supports symbols, for
example. And their take on implementing classes and object instances are
not only incompatible with each other, but also totally inadequate to
implement CLOS in an efficient
way. It is still baffling that lisp knows a lot of answers, but
nobody is asking, leave alone listens. Mention lisp and eyes start
to roll up and you hear "oh no, one of THOSE guys". And then they
continue to argue over how many XML-angels can dance on the "let's
make a totally abstract programming language"-pin.
Tin Gherdanarra wrote:
> > If you are so eager to see an operating
> > system that runs on a VM then write one.
>
> Funny you'd mention it. That's precisely what I've started to do last
> week (Thursday, I think it was). It will take a while, though,
> because I'm of very limited abilities. And automated garbage
> collection is not as trivial as I thought. But since the MIT
> guys and Symbolics have thrown in the towel, and since nobody
> else is doing it, I have to step in and create that world-dominating
> LispOS of the future. Wish me luck.
I suppose it would be overly cycnical to refuse this wish, so I will
wish you the best of luck. Hope you have fun and learn much.
Before you get too far, you have noticed Movitz, right?
http://common-lisp.net/project/movitz/
From: Tin Gherdanarra
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <439orgF1mf5kvU1@individual.net>
··············@hotmail.com wrote:
> Tin Gherdanarra wrote:
>
>
>>> If you are so eager to see an operating
>>>system that runs on a VM then write one.
>>
>>Funny you'd mention it. That's precisely what I've started to do last
>>week (Thursday, I think it was). It will take a while, though,
>>because I'm of very limited abilities. And automated garbage
>>collection is not as trivial as I thought. But since the MIT
>>guys and Symbolics have thrown in the towel, and since nobody
>>else is doing it, I have to step in and create that world-dominating
>>LispOS of the future. Wish me luck.
>
>
> I suppose it would be overly cycnical to refuse this wish, so I will
> wish you the best of luck. Hope you have fun and learn much.
>
> Before you get too far, you have noticed Movitz, right?
>
> http://common-lisp.net/project/movitz/
>
Yes, as stated above, I'm very fond of Movitz but
it does not use a virtual machine. I think a virtual
machine is very important and very useful. I can't
guarantee that I won't end up building on Movitz
eventually, however.
Tin Gherdanarra wrote:
>> However, the original post was about LOW-LEVEL operating system
>> development, ie: on bare metal.
>
> That's right, and I told you guys that this is doable, but
> not practical. Lisp machines had special hardware for a
> reason. "On the bare metal" should be understood as: There
> is no OS in the conventional sense, the VM for the Lisp is
> the OS.
>
As you wish.
>> If you are so eager to see an operating system that runs on a VM then
>> write one.
>
>
> Funny you'd mention it. That's precisely what I've started to do last
> week (Thursday, I think it was). It will take a while, though,
> because I'm of very limited abilities. And automated garbage
> collection is not as trivial as I thought. But since the MIT
> guys and Symbolics have thrown in the towel, and since nobody
> else is doing it, I have to step in and create that world-dominating
> LispOS of the future. Wish me luck.
>
Mazel tov! Come on over to alt.os.development if you have any questions
or answers to share about OS development. There's also #osdev on
irc.wyldryde.org and www.mega-tokyo.com/osfaq2.
>>
>> I do agree, however, that certain tasks like abstracting machine
>> interrupts and I/O ports into Lisp objects should be the job of
>> software below what we would now call the OS. Most likely it would be
>> the bare-metal Lisp interpreter's job to perform the grunt
>> machine-talking work.
>
>
> This is not a matter of either/or. A reduced low-level lisp can be
> used to handle interrupts, memory segments and I/O-ports. An extreme
> case is Movitz which uses an x86 assembler with a sexp-syntax. This
> works very well, but it is conceivable to wrap a typeless, word-oriented
> langague like BCPL around a lisp-syntax. So the programmer of a lisp
> system has ample room for shuffling responsibilites between the
> macro-assembler, some Lisp/C/assembler-bastard, the VM, the high-level
> implementation and who bootstraps whom and who abstracts away what. In this
> sense, a LispOS resembles a ForthOS, Forth being the other unpopular
> syntaxless language with meta-programming facilities. The difference is
> that such Forth system have actually and routinely been built from
> scratch a thousand times, with varying degrees of virtualization
> of the hardware and varying priorities. In contrast to Forth, Lisp
> does not have such a deep tradition on this terrain.
Forth, however, looks nasty. At least it does in its Wikipedia entry,
which I suppose can be trusted as far as I can spit.
>
> As an aside, I believe that virtual machines and automated garbage
> collection will play an increasingly prominent role on all levels
> of computing. Eventually the microprocessor industry will adopt this
> trend and modify their architectures with GC and VMs in mind. This
> does not mean that Intel will start to make Lisp-Machine CPUs, but
> they will end up making something like Java-Machine CPUs or
> .NET-Machine CPUs. Today's microprocessors are more or less optimized
> for running something like a Unix-kernel (including various
> Windows-kernels), but this is a dead end. I'm afraid that a lot
> of interesting things will happen to address the shortcomings of
> today's "Dinosaurs are ruling the earth, and it sucks"-issues,
> but without lisp on the map. I mean, none of the more prominent
> vms (java, .net or parrot) knows how to cons or supports symbols, for
> example. And their take on implementing classes and object instances are
> not only incompatible with each other, but also totally inadequate to
> implement CLOS in an efficient
> way. It is still baffling that lisp knows a lot of answers, but
> nobody is asking, leave alone listens. Mention lisp and eyes start
> to roll up and you hear "oh no, one of THOSE guys". And then they
> continue to argue over how many XML-angels can dance on the "let's
> make a totally abstract programming language"-pin.
VMs and automated garbage collection becoming the norm? FMH! That
would be like an explicit ban on writing truly efficient code! Besides,
other than allowing bad programmers to forget what they did with memory
without penalty (and I don't mean a la Lisp where you ignore memory
entirely and deal with your actual data) and perhaps placing some .NET
or Java system calls at the CPU level, what would that do for anybody?
Eli Gottlieb wrote:
>> As an aside, I believe that virtual machines and automated garbage
>> collection will play an increasingly prominent role on all levels
>> of computing. Eventually the microprocessor industry will adopt this
>> trend and modify their architectures with GC and VMs in mind. This
>> does not mean that Intel will start to make Lisp-Machine CPUs, but
>> they will end up making something like Java-Machine CPUs or
>> .NET-Machine CPUs. Today's microprocessors are more or less optimized
>> for running something like a Unix-kernel (including various
>> Windows-kernels), but this is a dead end. I'm afraid that a lot
>> of interesting things will happen to address the shortcomings of
>> today's "Dinosaurs are ruling the earth, and it sucks"-issues,
>> but without lisp on the map. I mean, none of the more prominent
>> vms (java, .net or parrot) knows how to cons or supports symbols, for
>> example. And their take on implementing classes and object instances
>> are not only incompatible with each other, but also totally inadequate
>> to implement CLOS in an efficient
>> way. It is still baffling that lisp knows a lot of answers, but
>> nobody is asking, leave alone listens. Mention lisp and eyes start
>> to roll up and you hear "oh no, one of THOSE guys". And then they
>> continue to argue over how many XML-angels can dance on the "let's
>> make a totally abstract programming language"-pin.
>
> VMs and automated garbage collection becoming the norm? FMH! That
> would be like an explicit ban on writing truly efficient code!
Only if you grossly misinterpret what Tin wrote.
Firstly, Tin said that future CPUs will be like the virtual CPUs that
VMs have. These won't magically be inefficient, in fact they'll be more
efficient than present day CPUs.
We'll also see CPUs which are designed to make it easier to implement
highly efficient genuine virtual machines by making it possible to
virtualise the hardware without major performance penalties. These are
already on their way in the form of AMD's Pacifica and Intel's Silvervale.
Secondly, Tin said nothing about automated garbage collection: only
garbage collection. It stands to reason that the hardware won't be
taking it upon itself to perform garbage collection, it will merely
contain features which will make efficient garbage collection easier.
The CPU provides the mechanism, but the operating system provides the
policy. And if you don't like the operating system forcing automated
garbage collection upon you (and there is no evidence any operating
system will even do that), use another operating system.
> Besides, other than allowing bad programmers to forget what they did
> with memory without penalty (and I don't mean a la Lisp where you
> ignore memory entirely and deal with your actual data) and perhaps
> placing some .NET or Java system calls at the CPU level, what would
> that do for anybody?
Shocking. Why don't we just start programming in assembly again? I had
thought that the lessons of the past would have been learned by most
people by now.
Firstly, it isn't only bad programmers who forget what they did with
memory. Or are you claiming that you've _never_ lost a pointer in a
language which doesn't do automated garbage collection?
Secondly, you've completely overlooked the far more significant issue in
modern software design: that of security. A very small class of
exploits can be defeated by ensuring that memory is never both
executable and writable. But there are a great many exploits which do
not depend upon injecting executable code into an application -- and are
therefore generally immune to memory protection -- but would not be
immune to other security features.
It should be clear that present day hardware and software is not
sufficient for ensuring security. If it were, then exploits would be far
less common; limited to those using errors of logic and intentional back
doors (c.f. the WMF debacle).
Nathan Baum wrote:
> Shocking. Why don't we just start programming in assembly again? I had
> thought that the lessons of the past would have been learned by most
> people by now.
Why should we start programming in C# now?
>
> Firstly, it isn't only bad programmers who forget what they did with
> memory. Or are you claiming that you've _never_ lost a pointer in a
> language which doesn't do automated garbage collection?
I don't think I've done that much memory leaking in my time, but a lot
more writing to memory that isn't allocated by accident.
>
> Secondly, you've completely overlooked the far more significant issue in
> modern software design: that of security. A very small class of
> exploits can be defeated by ensuring that memory is never both
> executable and writable. But there are a great many exploits which do
> not depend upon injecting executable code into an application -- and are
> therefore generally immune to memory protection -- but would not be
> immune to other security features.
What do you want, the Trusted Computing Platform? Security can be had
by /writing secure software/. If you start putting in VM features to
check code or whatnot people just start writing exploits for those VM
features.
Eli Gottlieb wrote:
> What do you want, the Trusted Computing Platform? Security can be had
> by /writing secure software/. If you start putting in VM features to
> check code or whatnot people just start writing exploits for those VM
> features.
The crux of your argument is as follows:
neither 'system A' nor 'system B' is 100% secure against malicious
attack, therefore A is no more secure than B.
This is a false dilemma. There are more categories of security than
"100% secure" and "not 100% secure". TCPs, VMs and other architectures
could conceivably result in much more secure systems.
Heck, if all communications protocols (e.g. TCP/IP, pipes) and OS
daemons were written in a language that attempted to protect against
buffer overflow (either through runtime checking or static analysis)
the most common class of security exploit would be much less common.
--jfc
funkyj wrote:
> Eli Gottlieb wrote:
>
>
>>What do you want, the Trusted Computing Platform? Security can be had
>>by /writing secure software/. If you start putting in VM features to
>>check code or whatnot people just start writing exploits for those VM
>>features.
>
>
> The crux of your argument is as follows:
>
> neither 'system A' nor 'system B' is 100% secure against malicious
> attack, therefore A is no more secure than B.
>
> This is a false dilemma. There are more categories of security than
> "100% secure" and "not 100% secure". TCPs, VMs and other architectures
> could conceivably result in much more secure systems.
>
> Heck, if all communications protocols (e.g. TCP/IP, pipes) and OS
> daemons were written in a language that attempted to protect against
> buffer overflow (either through runtime checking or static analysis)
> the most common class of security exploit would be much less common.
>
> --jfc
>
Buffer overflow is mostly caused by C programmer's disease, allocating
memory for something before you know how much something you've got.
That can be fixed by automatically allocating off the heap and/or
checking amounts of things before allocating. Neither of those
practices requires a VM.
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <43ahmpF1mdcckU1@individual.net>
Eli Gottlieb wrote:
> Buffer overflow is mostly caused by C programmer's disease, allocating
> memory for something before you know how much something you've got. That
Not even that. I guess that more than 95% of all C buffer overflows
involve string handling, because C doesn't offer a standard string
library (at least none with decent functions in it).
> can be fixed by automatically allocating off the heap and/or checking
> amounts of things before allocating. Neither of those practices
> requires a VM.
Yep.
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
Ulrich Hobelmann wrote:
> Eli Gottlieb wrote:
>
>> Buffer overflow is mostly caused by C programmer's disease, allocating
>> memory for something before you know how much something you've got. That
>
>
> Not even that. I guess that more than 95% of all C buffer overflows
> involve string handling, because C doesn't offer a standard string
> library (at least none with decent functions in it).
>
>> can be fixed by automatically allocating off the heap and/or checking
>> amounts of things before allocating. Neither of those practices
>> requires a VM.
>
>
> Yep.
>
Funny, that you say most buffer overflows are caused by strings. I
usually use Object Pascal (including for my kernel) for precisely the
reason that dynamic arrays and strings are reference counted objects
which disappear if I forget about them. Now in most cases I don't, but
it's still damned useful to have the allocation go on in the language.
Eli Gottlieb wrote:
> Nathan Baum wrote:
> > Shocking. Why don't we just start programming in assembly again? I had
> > thought that the lessons of the past would have been learned by most
> > people by now.
>
> Why should we start programming in C# now?
I don't know. I didn't say we should.
> > Firstly, it isn't only bad programmers who forget what they did with
> > memory. Or are you claiming that you've _never_ lost a pointer in a
> > language which doesn't do automated garbage collection?
>
> I don't think I've done that much memory leaking in my time, but a lot
> more writing to memory that isn't allocated by accident.
But you would _still_ object if your language, environment and software
conspired to make it impossible for you to write to memory that isn't
allocated?
> > Secondly, you've completely overlooked the far more significant issue in
> > modern software design: that of security. A very small class of
> > exploits can be defeated by ensuring that memory is never both
> > executable and writable. But there are a great many exploits which do
> > not depend upon injecting executable code into an application -- and are
> > therefore generally immune to memory protection -- but would not be
> > immune to other security features.
>
> What do you want, the Trusted Computing Platform?
This appears to be an argument of the form "you want X, Y gives you X,
Y also gives you Z, you don't want Z, therefore you don't want X." In
this case X = security, Y = TCP and Z = draconian digital rights
management.
You're right in implying that I don't want TCP. But TCP isn't the only
hardware solution to security issues, so it's not really relevant, is
it?
> Security can be had by /writing secure software/.
If it was as simple as that, then all software would be secure. The
truth is that writing secure software is _hard_. Even people who _know_
people will try to find exploits in their software cannot always make
it secure.
Some kinds of security holes are errors of logic which no environment
could resolve. By demanding that programmers should deal with _both_
the problems the environment cannot _and_ the ones it can, you're
making programmers do extra work: extra work they shouldn't have to do.
> If you start putting in VM features to check code or whatnot people just
> start writing exploits for those VM features.
Of course they will. But the "VM" will be designed from the ground up
for security.
It isn't an software virtual machine in the way you're envisioning.
It's a physical architecture which provides sophisticated
virtualisation, protection and memory management facilities. Its design
will be _informed by_ existing emulated virtual machines.
Physical machines appear to have a good track record for security. I've
never heard of anybody exploiting a weakness in the IA-32 instruction
set to gain control over a computer. It seems reasonable to assume that
if such a weakness existed, then nobody would bother finding ways to
elevate their priviledges.
Even for a software virtual machine, there is the significant advantage
of the number of programmers available to debug it. A large company
might be able to assign hundreds of programmers to fixing bugs in the
SVM, and if the source code is available for public review, thousands
more could detect and fix bugs.
From: Tin Gherdanarra
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <439t2mF1l4d6oU1@individual.net>
>>
>
> Mazel tov! Come on over to alt.os.development if you have any questions
> or answers to share about OS development. There's also #osdev on
> irc.wyldryde.org and www.mega-tokyo.com/osfaq2.
You started it! But you are right, maybe we should continue this
discussion on alt.os.develoment... Some people get bored here.
>
>>>
>>> I do agree, however, that certain tasks like abstracting machine
>>> interrupts and I/O ports into Lisp objects should be the job of
>>> software below what we would now call the OS. Most likely it would
>>> be the bare-metal Lisp interpreter's job to perform the grunt
>>> machine-talking work.
>>
>>
>>
>
>
> Forth, however, looks nasty. At least it does in its Wikipedia entry,
> which I suppose can be trusted as far as I can spit.
Forth IS nasty in some ways, but it is also very flexible.
The Wikipedia entry on Forth is very good and really does
justice to the language and its spirit.
>
>
> VMs and automated garbage collection becoming the norm? FMH! That
> would be like an explicit ban on writing truly efficient code!
Efficient code is sohhhh 20th century! Who needs it, anyway? If
it is too slow, drop another bank of processors into the case.
> Besides,
> other than allowing bad programmers to forget what they did with memory
> without penalty (and I don't mean a la Lisp where you ignore memory
> entirely and deal with your actual data) and perhaps placing some .NET
> or Java system calls at the CPU level, what would that do for anybody?
Allowing bad programmers to forget as much as possible is what
OSes and languages are all about. And it is not the system calls that
will make these CPUs useful. It is more that they don't do in hardware
what the vm does in software anyway (like memory protection)
Anyways, see you at alt.os.development. Or not.
Tin Gherdanarra wrote:
>> Mazel tov! Come on over to alt.os.development if you have any
>> questions or answers to share about OS development. There's also
>> #osdev on irc.wyldryde.org and www.mega-tokyo.com/osfaq2.
>
>
> You started it! But you are right, maybe we should continue this
> discussion on alt.os.develoment... Some people get bored here.
>
What do you mean "You started it!"? I was /congratulating/ you and
telling you where to find OSdeving info.
> Efficient code is sohhhh 20th century! Who needs it, anyway? If
> it is too slow, drop another bank of processors into the case.
Or in other words processing power is growing cheaper than programmer
skill in writing efficient AND working code.
>
>> Besides, other than allowing bad programmers to forget what they did
>> with memory without penalty (and I don't mean a la Lisp where you
>> ignore memory entirely and deal with your actual data) and perhaps
>> placing some .NET or Java system calls at the CPU level, what would
>> that do for anybody?
>
>
> Allowing bad programmers to forget as much as possible is what
> OSes and languages are all about. And it is not the system calls that
> will make these CPUs useful. It is more that they don't do in hardware
> what the vm does in software anyway (like memory protection)
> Anyways, see you at alt.os.development. Or not.
I most definitely will see you on alt.os.development! If you show up
there, at least.
I still think that it's a bad idea to do things like memory protection
via VM software. However, why not provide some kind of programmable
microcode on the CPU? If the principle of basically programming a
hardware platform is good, why not move it down to actual hardware?
From: Ulrich Hobelmann
Subject: Re: Lisp and low-level operating system development
Date:
Message-ID: <439qe8F1lsssrU1@individual.net>
Tin Gherdanarra wrote:
> The difference is
> that such Forth system have actually and routinely been built from
> scratch a thousand times, with varying degrees of virtualization
> of the hardware and varying priorities. In contrast to Forth, Lisp
> does not have such a deep tradition on this terrain.
Another difference is that Forth is much lower level than Lisp, and that
I suppose most Forth kernels only do very limited computing at all,
often no preemptive multitasking etc.
It's embedded programming, and embedded people even use statecharts and
stateflow for modelling, so their stuff can't be very complicated to the
stuff people do in very-high-level languages.
This isn't a troll or a flame; Forth is cool, but you should keep in
mind that for a general purpose OS you need much more functionality and
flexibility than I guess most Forth systems have (at least I haven't
seen a GP-OS written in it, nor a normal application for desktop
systems). The downside of Lisp is that you have garbage-collection
inside the kernel, but as others said that needn't be a big problem.
Best of luck...
--
The problems of the real world are primarily those you are left with
when you refuse to apply their effective solutions.
Edsger W. Dijkstra
"ramza2" <············@gmail.com> writes:
> I have been kind of amazed at all the software that is written in C,
> especially for example on a unix or linux system.
Don't be amazed by the quantity of C sources. When you translate C
programs to lisp, you end with at least ten times less code, and often
with more features.
> I am curious. Do you think that a full operating system(meaning
> applications and possibly low-level drivers) could be written in lisp?
Yes.
> Take ls.c. Could that be written in Lisp.
Is it a question or an affirmation?
Please, let me introduce you my (ls):
[97]> (pwd)
#P"/local/users/pjb/"
[98]> (cd "src/lisp/encours/misc-fun")
#P"/local/users/pjb/src/lisp/encours/misc-fun/"
[99]> (ls)
./#graph-search.lisp#
./ackerman.fas
./ackerman.fasl
./ackerman.lib
./ackerman.lisp
./ackerman.lisp.~1~
...
[100]> (ls '-l)
- 5215 10-14 18:30 ./#graph-search.lisp#
- 1058 2005-07-11 ./ackerman.fas
- 4006 2005-07-11 ./ackerman.fasl
- 170 2005-07-11 ./ackerman.lib
- 175 2005-07-11 ./ackerman.lisp
- 175 2005-07-11 ./ackerman.lisp.~1~
- 365 2005-03-17 ./back-un-quote.lisp
...
[101]> (ls '-l "*.lisp")
- 175 2005-07-11 ./ackerman.lisp
- 365 2005-03-17 ./back-un-quote.lisp
- 7363 2005-03-17 ./benford.lisp
- 4517 08-15 21:11 ./catch-environment.lisp
- 3368 2005-03-17 ./characters.lisp
- 20693 2005-07-14 ./circle.lisp
- 429 2004-03-02 ./closure.lisp
...
You can fetch it from cvs:
http://www.informatimago.com/develop/lisp/index.html
cvs -z3 -d ··················@cvs.informatimago.com:/usr/local/cvs/public/chrooted-cvs/cvs co common/common-lisp/browser.lisp
> It seems like a good thing for software engineering?
Is it a question or an affirmation? What is "it"?
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.