On Fri, 11 Aug 2000 09:35:05 +0200, "Tobias Andersson"
<················@optosweden.se> wrote:
> Whatever happened to LISPOS?
Check:
http://www.hex.net/~cbbrowne/lisposes.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
> Check:
> http://www.hex.net/~cbbrowne/lisposes.html
One project I don't see lsted there is MzScheme. Maybe this doesn't qualify as
a ``Lisp OS,'' but quoting from the MzScheme Web page:
MzScheme is available in kernel form for x86 machines, which allows
MzScheme to boot without the aid of a separate operating system. The
MzScheme kernel is based on the OSKit.
Relevant URLs:
<http://www.cs.rice.edu/CS/PLT/packages/mzscheme/>
<http://www.cs.utah.edu/flux/oskit/>
Eric.
--
-------------------------------------------------------------------------------
Eric Eide <·····@cs.utah.edu> . University of Utah School of Computing
http://www.cs.utah.edu/~eeide/ . +1 (801) 585-5512 voice, +1 (801) 581-5843 FAX
Centuries ago, Nostradamus foresaw a time when Eric Eide would say:
>Paolo Amoroso <·······@mclink.it> writes:
>
> > Check:
> > http://www.hex.net/~cbbrowne/lisposes.html
>
>One project I don't see lsted there is MzScheme. Maybe this doesn't qualify as
>a ``Lisp OS,'' but quoting from the MzScheme Web page:
>
> MzScheme is available in kernel form for x86 machines, which allows
> MzScheme to boot without the aid of a separate operating system. The
> MzScheme kernel is based on the OSKit.
>
>Relevant URLs:
>
> <http://www.cs.rice.edu/CS/PLT/packages/mzscheme/>
> <http://www.cs.utah.edu/flux/oskit/>
Shriram pointed that out to me a few weeks ago, and the following,
transformed into HTML, _will_ be on that page the next time it gets
updated. (Which evidently should probably take place this weekend...
If this update hasn't gotten in, there's got to be lots of other
missing stuff by now...)
<ListItem><Para> <link linkend= "MZSCHEME">MzScheme </link> atop <link
linkend= "OSKIT"> Flux OSKit </link> is probably one of the more
"mature" options; it apparently took all of five hours to port
MzScheme to run "atop bare metal" using OSKit.
<Para> It initially lacked support for filesystems and TCP, which
means that it lacked the ability to save data or programs anywhere.
Even with these lacks, probably still remains more functional than
most of the other projects.
<LISTITEM><PARA><Ulink URL=
"http://lists.tunes.org/list/lispos/9812/msg00005.html"> New OSKit
0.96 released and a "Scheme machine"</Ulink>
--
(concatenate 'string "cbbrowne" ·@" "hex.net")
<http://www.ntlug.org/~cbbrowne/>
Babbage's Rule: "No man's cipher is worth looking at unless the
inventor has himself solved a very difficult cipher" (The Codebreakers
by Kahn, 2nd ed, pg 765)
* "Tobias Andersson" <················@optosweden.se>
| Whatever happened to LISPOS?
I don't know what happened to LISPOS, but the discussions turned
from useful talk about how to perform this daunting task to deeply
involved and completely irrelevant minutiae.
#:Erik
--
If this is not what you expected, please alter your expectations.
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
>* "Tobias Andersson" <················@optosweden.se>
>| Whatever happened to LISPOS?
>
> I don't know what happened to LISPOS, but the discussions turned
> from useful talk about how to perform this daunting task to deeply
> involved and completely irrelevant minutiae.
From there, those that wanted to actually build something went off
their separate ways to do "their things."
Several different approaches have been taken, most sitting as the most
extreme forms of "vaporware."
A couple decided to build kernels using Scheme, and use Unix-like
models of filesystems and security. There is, of course, the problem
that few Schemes generate native code; they usually are implemented
atop C. (I find it very irritating that there is _no_ form of Lisp
front end for GCC, and that TENDRA, which had a Common Lisp front end,
failed utterly. _THAT_ seems to me to be one of the biggest "missing
things.")
A couple took more radical approaches, eschewing filesystems in favor
of persistent data.
FunOS uses OCAML underneath, and then has a Lisp layer on top.
And the Rice folk have deployed MzScheme atop FluxOS, which may well
be the _least_ vaprous of the options...
--
(concatenate 'string "cbbrowne" ·@" "hex.net")
<http://www.hex.net/~cbbrowne/lisposes.html>
Rules of the Evil Overlord #82. "I will not shoot at any of my enemies
if they are standing in front of the crucial support beam to a heavy,
dangerous, unbalanced structure. <http://www.eviloverlord.com/>
"Christopher Browne" <········@news.hex.net> wrote in message
····························@news6.giganews.com...
> (I find it very irritating that there is _no_ form of Lisp
> front end for GCC, ...
Kawa:
http://www.gnu.org/software/kawa/
+
GCJ:
http://sources.redhat.com/java/
Or you're saying you want something with fewer passes? Probably more
trouble than it is worth. JVM oriented development and deployment is
far more adaptable and so supports a wide range of trade offs. Kawa for
example will happily compile and execute (all in memory) transparently
from the repl or compile to class or library files (from repl or command
line). With the JVM class files/libraries you then have many choices in
how it gets to native bits, including GCC. You can also easily
integrate JVM classes from 60 or so other languages as well as native
code via JNI, and there is CORBA, ILU, and ActiveX to boot.
There also is a JavaOS with a JVM that runs on bare metal. If you're
running Kawa with JavaOS, does that mean you have a LISPOS? SchemeOS?
jim
------------------------------------------------------------
James P. White Netscape DevEdge Champion for IFC
IFC Exchange - Insanely great Java - http://www.ifcx.org
Erik Naggum wrote:
>
> * "Tobias Andersson" <················@optosweden.se>
> | Whatever happened to LISPOS?
>
> I don't know what happened to LISPOS, but the discussions turned
> from useful talk about how to perform this daunting task to deeply
> involved and completely irrelevant minutiae.
Armchair thought, for what it's worth: I've seen people talk about
starting from bare metal and working up through a kernel. Seems to me
it would be a better approach to start from the other end, an existing
Lisp compiler, and work down? The end goal could be the same, but it
would avoid the problem of requiring several man-decades of work before
any practically useful result was achieved.
--
"To summarize the summary of the summary: people are a problem."
Russell Wallace
···············@esatclear.ie
http://www.esatclear.ie/~rwallace
Russell Wallace <········@esatclear.ie> writes:
>Erik Naggum wrote:
>>
>> * "Tobias Andersson" <················@optosweden.se>
>> | Whatever happened to LISPOS?
>>
>> I don't know what happened to LISPOS, but the discussions turned
>> from useful talk about how to perform this daunting task to deeply
>> involved and completely irrelevant minutiae.
>Armchair thought, for what it's worth: I've seen people talk about
>starting from bare metal and working up through a kernel. Seems to me
>it would be a better approach to start from the other end, an existing
>Lisp compiler, and work down? The end goal could be the same, but it
>would avoid the problem of requiring several man-decades of work before
>any practically useful result was achieved.
Anyone who ever saw the source the the Adaptec SCSI driver in Linux or
FreeBSD will immedeately dismiss the idea to do down-to-metal in Lisp.
Even Linux and FreeBSD share complicated drivers like these and they
have manpower no end.
Pushing the Lisp/Unix barrier in general is an entirely different
issue. I.e. TCP/IP. Let the Unix do the IP routing, but redirect
TCP, UDP and ICMP to Lisp. That way, you can do most cool hacks I saw
as an example why down-to-metal Genera was better than existing
Lisp's. The same applies to filesystems: Let the Unix do the SCSI
stuff up to the raw device, the cooked/buffered device is done in
Lisp. Insert persistence here.
I think the real reason why LispOS as such did not went anywhere is
that Lisp and Lispers are about doing *new* things. Plainly
reimplementing something that already exists does not attrack most
capable Lisp hackers.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> Anyone who ever saw the source the the Adaptec SCSI driver in Linux
> or FreeBSD will immedeately dismiss the idea to do down-to-metal in
> Lisp. Even Linux and FreeBSD share complicated drivers like these
> and they have manpower no end.
But then again, wouldn't some of the point of such an excercise be
that you'd have this wonderfully powerful language for implementing
such complex drivers? :-)
I wouldn't exactly claim that an Adaptec SCSI driver in the
hypothetical lispos would reduce to a ten-line lisp expression, but
the fact that something has a complex solution in C doesn't imply that
the problem is complex. And even if the problem _is_ complex, I'd bet
the lisp solution would be a lot simpler than the C solution.
(Especially if you had a specialized compiler and environment. But
these are many and big ifs, I know..)
And finally, a lispos that ignores badly-designed hardware (well,
except for the PC architecture itself, I guess..) would still be of
great value to many people, even if it doesn't necessarily run on each
and every run-of-the-mill PC and peripheral device out there. I don't
know much about Adaptec's SCSI hardware, but I _do_ know that some of
the high-end PC SCSI controllers provide hardware interfaces that are
quite simple to use (i.e. require very simple drivers).
..So I don't agree that the idea is that easily dismissable.
--
Frode Vatvedt Fjeld
In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
<······@acm.org> wrote:
> I wouldn't exactly claim that an Adaptec SCSI driver in the
> hypothetical lispos would reduce to a ten-line lisp expression, but
> the fact that something has a complex solution in C doesn't imply that
> the problem is complex. And even if the problem _is_ complex, I'd bet
> the lisp solution would be a lot simpler than the C solution.
> (Especially if you had a specialized compiler and environment. But
The problem is the Lisp implementation. It should support
interrupts, callbacks from the OS to Lisp and processes.
> these are many and big ifs, I know..)
Today I installed my Symbolics NXP1000 at home. This is
a real Lisp machine (not embedded and not an emulator)
with an Ivory processor and without
any graphics card - one just uses a X Windows server to
access the machine. There is only
Genera (the OS written in Lisp) and the hardware
(different from the MacIvory or the UX boards where Genera
uses the underlying Unix or MacOS). My machine has an internal
Seagate SCSI disk.
(sct:count-lines-in-system "SCSI") says:
192681 characters, 4905 lines and 242 definitions.
And this includes code for the ISO9660 file system.
Doesn't look that complicated.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
>Today I installed my Symbolics NXP1000 at home.
[...]
>(sct:count-lines-in-system "SCSI") says:
>192681 characters, 4905 lines and 242 definitions.
>And this includes code for the ISO9660 file system.
>Doesn't look that complicated.
You can build a simple driver for a simple SCSI chip is quite short
time. However, supporting the big chips, while having a call
structure that supports disconnect/reconnet and friends is an entirely
different experience. The same applies to IDE. The old wc drivers of
Linux and FreeBSD are a far cry from FreeBSD's ata and Linux newer wc
drivers. The old things would still work, but not fulfill the
expectations of the users.
I'd like to point one thing out: I don't think that it will be
impossible to have a PC running nothing than Lisp.
But if that happens, I bet hardware drivers will be reduced to network
drivers. You'd need a pair of machines: the Lisp one and a server
providing network filesystems and an X11 server. Networked
filesystems to a server with good hardware and decent drivers are much
faster than trivial drivers for local cheap SCSI chips, at least when
you take multiprocessing into account.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>,
········@counter.bik-gmbh.de (Martin Cracauer) wrote:
> But if that happens, I bet hardware drivers will be reduced to network
> drivers. You'd need a pair of machines: the Lisp one and a server
> providing network filesystems and an X11 server.
So the Lispm doesn't need to interface to SCSI, but to Gigabit
Ethernet.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
>In article <·············@counter.bik-gmbh.de>,
>········@counter.bik-gmbh.de (Martin Cracauer) wrote:
>> But if that happens, I bet hardware drivers will be reduced to network
>> drivers. You'd need a pair of machines: the Lisp one and a server
>> providing network filesystems and an X11 server.
>So the Lispm doesn't need to interface to SCSI, but to Gigabit
>Ethernet.
Good point, a Gigabit Ethernet driver is also complex. However, there
are important differences between SCSI and network interface card
(NIC) work:
- You can live without harddisk interface, but not without network
interface.
- People can more easily replace their NIC or add a second one just to
please OS XXX.
- Modern Ethernet drivers and NIC - while complex - are still much
simpler than the advanced SCSI stuff.[1]
- SCSI means several nontrivial levels of code. Device-specific,
controller-specific, common layer, API, userland tools. Network and
especially ethernet is a lot simpler. You need TCP/IP anyway (most
people really want this is Lisp), just throw in ARP and feeding the
NIC you are. Even when the chip-level driver for the NIC and the
SCSI card is equally complex, a SCSI subsystem is an order of
magnitude bigger than a framework that supports network or Ethernet
only.
- Error handling is more easy in the network and especially ethernet
case. A SCSI implementation that is robust against errors on one
device so that the others on the same bus are still working is a
real framework. On the NIC level just just throw away bad packets
(oversimplified).
Martin
[1] The discussion degenerated enough so that I might as well expand
on the Adaptec issue: A modern Adaptec SCSI card is really a computer
of its own. You download a program, written in a kind of assembler,
to the card. The program you run on the card must in every way match
the expactations of the OS driver you run on the other side of the PCI
bus. The program you download is complicated and as I said written in
its own language noone is familiar with and that has crappy
non-warnings tools. A NCR SCSI chip is similar, escept that the SCSI
chip's code lives in normal RAM, not on the card and - of course -
that the instruction set is entirly different.
To get an impressiom:
- see the history of the FreeBSD driver at
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/aic7xxx/
- especially the sequencer code at
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/aic7xxx/aic7xxx.seq
- Take into account the fact that FreeBSD and Linux share this driver
(at least they did, didn't look in the last months). Then take into
account how much else is being shared. It is pure pressure from the
complexity of this driver that these teams finally do something with
joined forces.
- See how long it takes Linux and FreeBSD on one hand and NetBSD and
OpenBSD on the other hand to get support for the newer Adaptec chips
(789x instead of 788x), since they are decoupled from FreeBSD due to
FreeBSD's reimplementation of the upper SCSI levels for FreeBSD-3.x.
- Look up the Web or discussion archives for terms like "original
adaptec sequence code linux freebsd". Recently, Adaptec released
their previously closed driver sources for their chips, amoung the
feed stuff way their "original" sequencer code, which was beleived
to be a reason why SCO and other OSes using their code were faster
than Linux and FreeBSD. The expectation was that their sequencer
could be used easily in the free OSes, but as it turned out the free
sequencers were not really worse, it is difficult to adjust the
Adaptec sequencer for the frameworks that Linux and FreeBSD put
around it and the performance of the free OSes was good at that time
anyway.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) writes:
You download a program, written in a kind of assembler,
> to the card. The program you run on the card must in every way match
> the expactations of the OS driver you run on the other side of the PCI
> bus. The program you download is complicated and as I said written in
> its own language noone is familiar with and that has crappy
> non-warnings tools. A NCR SCSI chip is similar, escept that the SCSI
> chip's code lives in normal RAM, not on the card and - of course -
> that the instruction set is entirly different.
Symbolics wrote such a driver for the NXP1000. That machine used an
NCR 53c7x0 (essentially a "bus-less" variant of the NCR PCI SCSI
chips) which features the hideous SCRIPTS language processor.
I am certain that anyone who has read the the source of both the
Symbolics NXP SCSI driver and the "ncr" driver found in the various
free unicies would be in agreement with me regarding which one is
conceptually simpler.
And for those of us who don't have access to the Symbolics source and are
too dense to infer? Can you give me a little more like rough LOC (I know it
can't give a real indication of complexity but I'm reaching)?
Carl Shapiro wrote:
> ········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
> You download a program, written in a kind of assembler,
> > to the card. The program you run on the card must in every way match
> > the expactations of the OS driver you run on the other side of the PCI
> > bus. The program you download is complicated and as I said written in
> > its own language noone is familiar with and that has crappy
> > non-warnings tools. A NCR SCSI chip is similar, escept that the SCSI
> > chip's code lives in normal RAM, not on the card and - of course -
> > that the instruction set is entirly different.
>
> Symbolics wrote such a driver for the NXP1000. That machine used an
> NCR 53c7x0 (essentially a "bus-less" variant of the NCR PCI SCSI
> chips) which features the hideous SCRIPTS language processor.
>
> I am certain that anyone who has read the the source of both the
> Symbolics NXP SCSI driver and the "ncr" driver found in the various
> free unicies would be in agreement with me regarding which one is
> conceptually simpler.
In article <················@pfizer.com>, Willy Heineman
<··················@pfizer.com> wrote:
> And for those of us who don't have access to the Symbolics source and are
> too dense to infer? Can you give me a little more like rough LOC (I know it
> can't give a real indication of complexity but I'm reaching)?
2389 LOCs including comments.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Frode Vatvedt Fjeld <······@acm.org> writes:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>> Anyone who ever saw the source the the Adaptec SCSI driver in Linux
>> or FreeBSD will immedeately dismiss the idea to do down-to-metal in
>> Lisp. Even Linux and FreeBSD share complicated drivers like these
>> and they have manpower no end.
>But then again, wouldn't some of the point of such an excercise be
>that you'd have this wonderfully powerful language for implementing
>such complex drivers? :-)
>I wouldn't exactly claim that an Adaptec SCSI driver in the
>hypothetical lispos would reduce to a ten-line lisp expression, but
>the fact that something has a complex solution in C doesn't imply that
>the problem is complex. And even if the problem _is_ complex, I'd bet
>the lisp solution would be a lot simpler than the C solution.
>(Especially if you had a specialized compiler and environment. But
>these are many and big ifs, I know..)
I'm sorry to say, but Christopher R. Barry comments from two posts
above apply here.
You have no idea how the 2940+ chips work and that the Lisp solution
may be more elegant doesn't change the fact that is has to be done.
By a dedicated, capable person. Sorry, but I'd rather see that person
hack CMUCL or free-clim. Especially the latter since - as Christopher
said - it gets the point of the LispM much better than a SCSI driver.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>,
········@counter.bik-gmbh.de (Martin Cracauer) wrote:
> You have no idea how the 2940+ chips work and that the Lisp solution
> may be more elegant doesn't change the fact that is has to be done.
> By a dedicated, capable person. Sorry, but I'd rather see that person
> hack CMUCL or free-clim. Especially the latter since - as Christopher
> said - it gets the point of the LispM much better than a SCSI driver.
Btw., there is progress in the Free-CLIM project.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> >I wouldn't exactly claim that an Adaptec SCSI driver in the
> >hypothetical lispos would reduce to a ten-line lisp expression, but
> >the fact that something has a complex solution in C doesn't imply that
> >the problem is complex. And even if the problem _is_ complex, I'd bet
> >the lisp solution would be a lot simpler than the C solution.
> >(Especially if you had a specialized compiler and environment. But
> >these are many and big ifs, I know..)
········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
> I'm sorry to say, but Christopher R. Barry comments from two posts
> above apply here.
No, they don't. You both seem to ignore my (main) argument that a
lispos doesn't have to support overly complicated hardware (like the
Adaptec 2940s appear to be, from your comments).
The relevant question is "where can I buy a machine that will run
lispos?", not "will lispos run on my old machine brand XX?".
So you'd start out building a _system_ (machine + lispos), where you
carefully pick hardware that provide the best hardware interfaces
(simple to use, fast, and cheap, in that order of preference). You'd
very much want to _avoid_ devices that require 10.000-line drivers
that are different for every BIOS or what have you. I think such a
system would be interesting to a lot of people, even if they'd have to
invest in new hardware.
And, if such a system was to attract any user-base at all, the
likelihood that some bright kid with too much free time (or someone
funded by a company with special needs) would write an Adaptec 2940
driver would not be negligible. Especially if the original system was
well designed. This should not be an unfamiliar development model.
Yes, it still needs to be done, and it's not "that easy". I'm just
saying that there _are_ other options than having 10 full-time
employed people working for X years and in the end come out with a
complete lispos kernel and environment that supports everything linux
or windows do.
> You have no idea how the 2940+ chips work and that the Lisp solution
> may be more elegant doesn't change the fact that is has to be done.
> By a dedicated, capable person. Sorry, but I'd rather see that
> person hack CMUCL or free-clim. Especially the latter since - as
> Christopher said - it gets the point of the LispM much better than a
> SCSI driver.
CMUCL and free-clim are nice, but they are not a lispos. People spend
their free time doing what they think is fun or interesting, and some
might find a lispos more fun than CMUCL/unix.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
>> Frode Vatvedt Fjeld <······@acm.org> writes:
>>
>> >I wouldn't exactly claim that an Adaptec SCSI driver in the
>> >hypothetical lispos would reduce to a ten-line lisp expression, but
>> >the fact that something has a complex solution in C doesn't imply that
>> >the problem is complex. And even if the problem _is_ complex, I'd bet
>> >the lisp solution would be a lot simpler than the C solution.
>> >(Especially if you had a specialized compiler and environment. But
>> >these are many and big ifs, I know..)
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>>
>> I'm sorry to say, but Christopher R. Barry comments from two posts
>> above apply here.
>No, they don't. You both seem to ignore my (main) argument that a
>lispos doesn't have to support overly complicated hardware (like the
>Adaptec 2940s appear to be, from your comments).
>The relevant question is "where can I buy a machine that will run
>lispos?", not "will lispos run on my old machine brand XX?".
>So you'd start out building a _system_ (machine + lispos), where you
>carefully pick hardware that provide the best hardware interfaces
>(simple to use, fast, and cheap, in that order of preference).
For SCSI, the fast (no, the non-crawling-slow) parts are all very
complicated, see my other post. And a SCSI subsystem with error
handling is even more, independent of the controller in use.
>You'd
>very much want to _avoid_ devices that require 10.000-line drivers
>that are different for every BIOS or what have you.
Uh, there is nothing about the BIOS versions that cause changes to the
drivers. It's the new revisions of the SCSI chips that cause
problems.
Comments like that are exactly what I'm meant: I have to assume that
you don't have a clue about what the BIOS does and where a driver
attaches to a SCSI card. You should not post about it unless you do,
otherwise the effect that Christopher saws in LispOS applies here as
well.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> For SCSI, the fast (no, the non-crawling-slow) parts are all very
> complicated, see my other post. And a SCSI subsystem with error
> handling is even more, independent of the controller in use.
Granted it is not trivial, but I fail to see what it is with a SCSI
subsystem that makes it next to impossible to implement with
reasonable efficiency and amounts of effort. I'm not sure which post
you are referring to, but none of those I've seen made strong
arguments to that effect.
Error handling in particular should be a lot easier if you have a
language with decent support for exceptional situations.
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> >You'd very much want to _avoid_ devices that require 10.000-line
> >drivers that are different for every BIOS or what have you.
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> Uh, there is nothing about the BIOS versions that cause changes to the
> drivers. It's the new revisions of the SCSI chips that cause
> problems.
I was repeating my recollection of someone else's decription of the
difficulties with some SCSI controllers, as an example of bad hardware
you'd want to avoid, <·······················@knuth.brownes.org>. I
figured he was talking about the "BIOS" (some sort of firmware, I
guess) that some SCSI controllers have. Anyways, this is all
completely besides the point of this discussion.
> Comments like that are exactly what I'm meant: I have to assume that
> you don't have a clue about what the BIOS does and where a driver
> attaches to a SCSI card.
Why do you feel compelled to assume such a thing?
> You should not post about it unless you do, otherwise the effect
> that Christopher saws in LispOS applies here as well.
Well, if it helps me qualify for further discussions, I can inform you
that I have written a SCSI driver or two, on architectures with and
without BIOSes (although I must confess to never actually having used
"the BIOS").
Incidently, one of the controllers for which I've written a driver
does indeed provide a very simple and fast hardware interface. So they
exist, and you can go buy them in the shop.
--
Frode Vatvedt Fjeld
>>>>> "Frode" == Frode Vatvedt Fjeld <······@acm.org> writes:
Frode> Granted it is not trivial, but I fail to see what it is
Frode> with a SCSI subsystem that makes it next to impossible to
Frode> implement with reasonable efficiency and amounts of
Frode> effort. I'm not sure which post you are referring to, but
Frode> none of those I've seen made strong arguments to that
Frode> effect.
Dear god man, have you ever even looked at the various operating
systems' source code that is floating about? Designing and
implementing operating system internals is not a trivial task. I
remember thinking as you did, "it's a video device driver, just a
frame buffer out in memory somewhere, piece of cake" and finding out
just exactly how difficult it is to code up a text-mode device driver
from scratch for the DEC TGA card. And that's nothing compared to the
SCSI subsystem, or the Networking subsystem, etc.
So here's the real reason LispOS has never really gotten of the floor:
1. It needs a combination garbage collector, virtual memory manager,
and run-time type system. No such thing currently exists as free
software and would have to be designed, implemented, and debugged
from scratch. Debugging garbage collectors is a notoriously
difficult task, according to the research I've done. Designing a
run-time type system has been done before, especially with GC
support (Dybvig, Eby, and Bruggeman wrote a very good paper on
BIBOPs), but again, no code (the described system is a part of
Cadence System's Chez Scheme).
2. Backing stores or object databases or persistent objects or
whatever they're called these days are still very much a "more
research needed" device. Hans Resier keeps saying he's doing
research on this, and I haven't managed to track down any papers
yet, so who knows.
And implementing Yet Another File System (or Rewriting Ext2/FFS in
LAP) is also a very non-trivial task. Take a gander through the
Berkeley FFS code and you'll very quickly see what I mean.
3. Do you know why people are so keen on the Berkeley IP stack?
Because it is (once again) very hard to write something that
correctly handles IP datagrams. It has taken some very talented
people working for some very large vendors (e.g. Microsoft) a long
time to even get the BSD stack working properly, and you think it's
trivially easy to re-write something from scratch just because you
have a decent macro system?
Et cetera. And I haven't even mentioned how you'll need to design and
build a compiler, an assembler, and a linker/loader (it's practically
impossible to re-use one of the freely-available compilers). Nor have
I mentioned how you will need to design and build, from scratch, some
kind of graphics sub-system on par with X (and lets see, how long have
the talented people at the Berlin project been working on that very
same thing, and how little do they have to show for it after years of
hacking and research?).
So are you beginning to see why people are saying "improve Free-CLIM"
and "improve CMUCL"? There's a lot more value in a better Lisp
run-time system on already-existing systems than there is in
re-inventing the wheel, yet again for the aleph-null time.
</rant>, Sorry. :(
--
> So Americans are either 'bible thumpers' or 'sheep'?
I, personally, am a 'sheep thumper.'
--Anonymous Coward in http://slashdot.org/article.pl?sid=00/07/21/1516215
> >>>>> "Frode" == Frode Vatvedt Fjeld <······@acm.org> writes:
>
>> Granted it is not trivial, but I fail to see what it is
>> with a SCSI subsystem that makes it next to impossible to
>> implement with reasonable efficiency and amounts of
>> effort.
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
>
> Dear god man, have you ever even looked at the various operating
> systems' source code that is floating about? Designing and
> implementing operating system internals is not a trivial task. I
> remember thinking as you did, [...]
Yes, I've looked at and generally messed about with some operating
system kernels' source code, and I belive I have a reasonable grasp of
what goes on. Which is why I stated -- as you quoted, but obviously
failed to read -- that it is not trivial. (Sorry, but I'm a bit
surprised by how difficult it is to come across with my message here.)
I believe there is a significant difference here between the
non-trivial and the next-to-impossible.
I appreciate your (all's) concern and words of advise to the rookie
that wants to whip together a flashy lisp-based desktop OS in a few
weeks time. That is not me, however.
> So here's the real reason LispOS has never really gotten of the floor:
>
> 1. It needs a combination garbage collector, virtual memory manager,
> and run-time type system.
I think a very reasonable design choice in this day and age would be
to dispense with the virtual memory (as in disk-paging), and assert
that there is enough real memory available. A lispos should also have
a reasonable chance of handling out-of-memory conditions gracefully.
> Designing a run-time type system has been done before, especially
> with GC support (Dybvig, Eby, and Bruggeman wrote a very good
> paper on BIBOPs), but again, no code (the described system is a
> part of Cadence System's Chez Scheme).
Do you have a more precise reference to this paper?
> 2. Backing stores or object databases or persistent objects or
> whatever they're called these days are still very much a "more
> research needed" device.
Persistent storage (OODB or FS) is I believe not a requirement for a
lispos to be useful. Provided, of course, that you have a network
stack. If you did have a lispos, you'd like to have persistent storage
for it, but first things first.
> 3. Do you know why people are so keen on the Berkeley IP stack?
> Because it is (once again) very hard to write something that
> correctly handles IP datagrams.
Yes, an IP stack is difficult. But there are in fact many other IP
stacks out there than the Berkeley one, and somebody has written those
too. I have watched as one person wrote an IP stack from scratch, in
C, and another person added IPv6 for that stack. It took them a few
monts (but considerably less than a year), and surely it's not as
perfect as the Berkeley/KAME stack, but I think it proves it's very
far from impossible.
> Et cetera. And I haven't even mentioned how you'll need to design
> and build a compiler, an assembler, and a linker/loader.
Yes, that would be a lot of work.
> Nor have I mentioned how you will need to design and build, from
> scratch, some kind of graphics sub-system on par with X.
I'd guess a reasonable route for a user interface would be to have
first a text-console (or several, like the virtual consoles of linux
and BSD), then CLX (or something to that effect) so you can use an X
terminal, and eventually a native X server or something even more
interesting. (As more empirical evidence that this is not completely
out of reach, we had a student here that developed a rather advanced
framebuffer device-driver for one of the newer Matrox graphics cards
over the course of a semester (or two, I'm not sure)).
Each subsystem is non-trivial, but doable, and it all adds up to a lot
of work.
But personally I'd find it much more fun and interesting to work on
this than working on CMUCL, especially when I can already go out and
buy excellent lisp environments for unix.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
>> 2. Backing stores or object databases or persistent objects or
>> whatever they're called these days are still very much a "more
>> research needed" device.
>Persistent storage (OODB or FS) is I believe not a requirement for a
>lispos to be useful. Provided, of course, that you have a network
>stack. If you did have a lispos, you'd like to have persistent storage
>for it, but first things first.
Argh!
Saying things like these is another nice way to break such a project's
neck: While noone is really against persistent storage instead of flat
files, the best design is not obvious.
If you start coding LispOS with that requirement, you will have to do
all the research people are putting into persistent languages first.
Otherwise, you will have nothing but fighting in the group and you
absolutely cannot succeed, since you are shooting an an unclear
target.
A friend of mine works on persistent Java for Sun. These folks have a
clear language and an existing environment, however the details of
persistence, both the surface and the implementation are subject to
serious reserach. What they do is a large piece of work - and if you
didn't hear of them lately it's the effect thereof - and you argue we
should plan to do that as a side-effect while building a SCSI
subsystem and an IP stack.[1]
Martin
[1] Speaking about IP stacks. Anyone following what Linux and the
BSDs have to do to protect against all those IP or TCP level
denial-of-service attacks? How long it takes to get each fix right?
How determined and experienced in the IP area these folks are compared
to use stupid Lispers doing the advanced search algorithms thing?
While I personally do not believe any of Frode's experiences anyway, I
may agree that a trivial IP stack may be build in a few months, but of
a production-quality one that is < 1%.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> Saying things like these is another nice way to break such a
> project's neck: While noone is really against persistent storage
> instead of flat files, the best design is not obvious.
To me, flat files (on hard-disks) are an instance of "persistent
storage". As opposed to volatile storage like RAM. If "persistent
storage" is well established in lisp circles to mean something
entirely different, please let me know.
> If you start coding LispOS with that requirement, you will have to
> do all the research people are putting into persistent languages
> first. Otherwise, you will have nothing but fighting in the group
> and you absolutely cannot succeed, since you are shooting an an
> unclear target.
I'm not quite able to convince myself of what you mean here, and I
don't really care to make guesses (since I really hate it when you
make guesses about me). What requirement? Why do I need to do loads of
research about something I'm not going to implement? (Because
otherwise it won't turn out to be _your_ perfect vision of a lispos?
(sorry, I guessed after all))
> While I personally do not believe any of Frode's experiences anyway,
Right, you got me there. I'm really just here squirting about devious
lies in order to lure innocent bystanders into putting manyears of
work into something I know is doomed to fail. (And please don't give
me any "but that's the net effect of what you're doing" crap. I
haven't asked anyone to do anything.)
--
Frode Vatvedt Fjeld
>>>>> "Frode" == Frode Vatvedt Fjeld <······@acm.org> writes:
Frode> Do you have a more precise reference to this paper?
@TechReport{dybvig94:tr400,
author = {R. Kent Dybvig and David Eby and Carl Bruggeman},
title = {Don't Stop the {BIBOP}: Flexible and Efficient
Storage Management for Dynamically-Typed Languages},
institution = {Indiana University Computer Science Department},
year = 1994,
number = 400,
note = {ftp://ftp.cs.indiana.edu/pub/techreports/TR400.ps.Z}
}
This is a great paper. It documents the storage management system in
Chez Scheme.
Several other good GC-related papers include:
@Misc{wilson94:bigsurv,
author = {Paul R. Wilson},
title = {Uniprocessor Garbage Collection Techniques},
year = 1994,
note = {ftp://ftp.cs.utexas.edu/pub/garbage/bigsurv.ps},
annote = {We survey basic garbage collection algorithms, and
variations such as incremental and generational
collection; we then discuss low-level implementation
considerations and the relationships between storage
management systems, languages, and compilers.
Throughout, we attempt to present a unified view
based on abstract traversal strategies, addressing
issues of conservatism, opportunism, and immediacy
of reclamation; we also point out a variety of
implementation details that are likely to have a
significant impact on performance.}
}
@TechReport{gudeman93:typeinfo,
author = {David Gudeman},
title = {Representing Type Information in Dynamically Typed
Languages},
institution = {Department of Computer Science, University of Arizona},
year = 1993,
number = {93-27},
address = {Gould-Simpson Building, Tuscon, AZ 85721, USA},
month = {October},
annote = {This report is a discussion of various techniques
for representing type information in dynamically
typed languages, as implemented on general-purpose
machines (and costs are discussed in terms of modern
RISC machines). It is intended to make readily
available a large body of knowledge that currently
has to be absorbed piecemeal from the literature or
re-invented by each language implementer. This
discussion covers not only tagging schemes but other
forms of representation as well, although the
discussion is strictly limited to the representation
of type information. It should also be noted that
this report does not purport to contain a survey of
the relevant literature. Instead, this report
gathers together a body of folklore, organizes it
into a logical structure, makes some
generalizations, and then discusses the results in
terms of modern hardware.}
}
I didn't record the URL for gudeman93:typeinfo, but it may be in the
GC archive on ftp://ftp.cs.utexas.edu/pub/garbage/ (or maybe I found
it on IU's CS Department FTP site). Another great resource the the
Memory Management Reference at
http://www.xanalys.com/software_tools/mm/index.html.
HTH
--
> So Americans are either 'bible thumpers' or 'sheep'?
I, personally, am a 'sheep thumper.'
--Anonymous Coward in http://slashdot.org/article.pl?sid=00/07/21/1516215
<········@irtnog.org> wrote:
+---------------
| author = {R. Kent Dybvig and David Eby and Carl Bruggeman},
| title = {Don't Stop the {BIBOP}: Flexible and Efficient
| Storage Management for Dynamically-Typed Languages},
...
| author = {Paul R. Wilson},
| title = {Uniprocessor Garbage Collection Techniques},
...
| author = {David Gudeman},
| title = {Representing Type Information in Dynamically Typed
| Languages},
+---------------
I agree, all these are great GC self-study materials!
+---------------
| I didn't record the URL for gudeman93:typeinfo, but it may be in the
| GC archive on ftp://ftp.cs.utexas.edu/pub/garbage/ ...
+---------------
Try the Indiana Scheme Repository instead:
<URL:ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/typeinfo.ps.gz>
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
>>>>> "Rob" == Rob Warnock <····@rigden.engr.sgi.com> writes:
Rob> I agree, all these are great GC self-study materials!
Not sure whether I should admit this, but the BibTeX file those
references come from is called "lispos.bib". Maybe it's a phase all
nacent Lisp hackers go through... ;)
--
> So Americans are either 'bible thumpers' or 'sheep'?
I, personally, am a 'sheep thumper.'
--Anonymous Coward in http://slashdot.org/article.pl?sid=00/07/21/1516215
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
> Not sure whether I should admit this, but the BibTeX file those
> references come from is called "lispos.bib". Maybe it's a phase all
> nacent Lisp hackers go through... ;)
I should expect so, as people are bound to think "there must be a
better way" when using typical computers today.
Either that, or they will try to figure out a way to use lisp without
all the parens :-)
Two different breeds of people, I think.
--
Frode Vatvedt Fjeld
········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
> >>>>> "Frode" == Frode Vatvedt Fjeld <······@acm.org> writes:
>
> Frode> Do you have a more precise reference to this paper?
>
> @TechReport{dybvig94:tr400,
> author = {R. Kent Dybvig and David Eby and Carl Bruggeman},
> title = {Don't Stop the {BIBOP}: Flexible and Efficient
> Storage Management for Dynamically-Typed Languages},
> institution = {Indiana University Computer Science Department},
> year = 1994,
> number = 400,
> note = {ftp://ftp.cs.indiana.edu/pub/techreports/TR400.ps.Z}
> }
>
> This is a great paper. It documents the storage management system
> in Chez Scheme.
I just read and thoroughly enjoyed this paper. Thanks for the tip.
Now, does somebody know where I might find this file "lispos.bib" that
somebody mentioned? (It didn't show up on AltaVista or FTPSearch.)
--
Frode Vatvedt Fjeld
>>>>> "Frode" == Frode Vatvedt Fjeld <······@acm.org> writes:
Frode> Now, does somebody know where I might find this file
Frode> "lispos.bib" that somebody mentioned? (It didn't show up on
Frode> AltaVista or FTPSearch.)
I am ashamed to admit to this, but "lispos.bib" is the BibTeX file for
a design document I started writing. I have not had time to finish it
because the more research I do, the more research I realize I have to
do. :(
"Don't Stop the BIBOP" was the first paper I read on garbage
collection and type management techniques, based on some
recommendations made by Joe Marshall and others earlier in the year
(search for my email address within comp.lang.lisp in Deja News and
you'll see a whole slew of LispOS-related questions within the past
year or so).
Since you're interested in systems programming, here are several other
interesting books:
@Book{levine00:linkers_loaders,
author = {John R. Levine},
title = {Linkers and loaders},
publisher = {Academic Press},
year = 2000,
address = {525 B Street, Suite 1900, San Diego, CA 92101-4495, USA},
note = {Assembing (Electronic computers); Linkers (Computer
programs); Loaders (Computer programs)},
annote = {QA76.76.A87 L48 2000}
}
(Note that John Levine is the moderator of comp.compilers.)
@Book{queinnec96:lisp,
author = {Christian Queinnec},
title = {LISP in small pieces},
publisher = {Press Syndicate of the University of Cambridge},
year = 1996,
address = {The Pitt Building, Trumpington Street, Cambridge CB2
1RP, UK},
edition = {English},
note = {LISP (Computer program language)},
annote = {QA76.73.L23 Q4613 1996}
}
@Book{friedman92:essentials_programming_lang,
author = {Daniel P. Friedman and Mitchell Wand and Christopher T. Haynes},
title = {Essentials of programming languages},
publisher = {MIT Press},
year = 1992,
address = {Cambridge, MA},
note = {Programming languages (Electronic computers)},
annote = {QA76.7 .F73 1992}
}
OK, so it's Scheme. Personally, I think it's a tad more approachable
than the SICP.
@Book{appel98:modern_compiler_implementation_java,
author = {Andrew W. Appel},
title = {Modern compiler implementation in Java},
publisher = {Press Syndicate of the University of Cambridge},
year = 1998,
address = {The Pitt Building, Trumpington Street, Cambridge CB2
1RP, UK},
note = {Java (Computer program language); Compilers (Computer programs)},
annote = {QA76.73.J38 A65 1998}
}
OK< so it's not the dragon book. Sue me. Appel did a good job with
it, and if you don't like Java, well, there's both a C and a SML
version.
Do not ask me for code or the address of the mailing list. I'm just
doing a little research, maybe for a survey paper or something.
--
> So Americans are either 'bible thumpers' or 'sheep'?
I, personally, am a 'sheep thumper.'
--Anonymous Coward in http://slashdot.org/article.pl?sid=00/07/21/1516215
Frode Vatvedt Fjeld <······@acm.org> writes:
> ········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
> > So here's the real reason LispOS has never really gotten of the floor:
> >
> > 1. It needs a combination garbage collector, virtual memory manager,
> > and run-time type system.
>
> I think a very reasonable design choice in this day and age would be
> to dispense with the virtual memory (as in disk-paging), and assert
> that there is enough real memory available. [ ... ]
Such an assertion would be wrong. There is never enough real memory.
In my college days, I was talking to the sysadmin in the computer lab
about how I was waiting to buy my first computer until they came up with
an affordable 64 Kbyte system. He laughed and said "What do you want
with 64 Kbytes? You'll never use all that memory."
Over the years since then, I've seen new lines drawn in the sand,
subltlely or overtly, and each time, someone finds a way to match
the need for memory to the memory available. As we enter the
new age of 64 bit virtual addresses (due to the fact that 2 to 4 Gb
is not enough for some problem sets), there will be some that say
that we will never use all of the memory addressible by 64 bits.
Don't believe them.
As for the issue of actually having enough real memory, I've seen systems
that have a huge amount of memory (some of our customers actually run with
2 or 3 Gb of real memory), and I'm sure that more can be stuffed into
a 64-bit machine. But I doubt that all (expt 2 64) bytes can be filled
out at the current time, for practical reasons such as power and cooling
constraints. So virtual memory is a must.
My response also does not cover the subltlety of why virtual memory
is _desireable_, such as separation of process spaces for programs,
but I'll leave that for another time.
If you want to design a lispos that lasts, leave virtual memory in there.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig <·····@franz.com> writes:
>Frode Vatvedt Fjeld <······@acm.org> writes:
>> ········@irtnog.org (Xenophon Fenderson the Carbon(d)ated) writes:
>> > So here's the real reason LispOS has never really gotten of the floor:
>> >
>> > 1. It needs a combination garbage collector, virtual memory manager,
>> > and run-time type system.
>>
>> I think a very reasonable design choice in this day and age would be
>> to dispense with the virtual memory (as in disk-paging), and assert
>> that there is enough real memory available. [ ... ]
>Such an assertion would be wrong. There is never enough real memory.
I didn't really care to answer that suggestion, but there is one thing
that could be considered: Doing the VM thing directly with the Lisp
system.
Page faults from the MMU are are delivered to the allocator/GC of the
Lisp system. Opportunities:
- improve the guesses what will be paged in next: not the physically
next page, but if one swapped in object is a collection, prepare to
load in the pages where the collections pointers point into.
- never swap out important objects (nil, t) or regions (stack).
- Before GC scanning, let the VM system know what will be read in what
sequence.
- When idleing, let the VM system prepare pages prefilled with often
used objects, like the NULLing of pages that happens in BSD
systems.
If the system has idle time or an extra CPU (interactive system, Web
server), you will for sure find interesting opportunities to prepare
stuff for the Lisp system. If the system heavily concurrent, ordering
of the disk requests is another opportunity.
Throw in weak references and things look even nicer, i.e. break the
weak reference instead of swapping that page out. Prefer to kick out
weak references over other objects.
None of these require a LispOS down to the MMU, however. A stupid
kernel module doing some communication between Linux or FreeBSD and
the Lisp system would be sufficient.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > I think a very reasonable design choice in this day and age would
> > be to dispense with the virtual memory (as in disk-paging), and
> > assert that there is enough real memory available. [ ... ]
Duane Rettig <·····@franz.com> writes:
>
> Such an assertion would be wrong. There is never enough real
> memory.
If you qualify that statement with "for every concievable program",
I'd agree. But if you start out any project with limited resources and
the requirement of being all things to everybody, things will appear
impossible.
Today, many users' response to seeing his machine swapping to disk is
to buy more real memory.
It's also interesting to see that many people who regularly run
machines with for example 64 MB real memory and 128 MB swap, 128+256
or whatever, will thing you're crazy for running 1GB without swap.
Finally, assuming a 4GB address-space (see below), implementing demand
paging today can only be justified by wanting to save money on
RAM. That's an easy choice in my book, especially if the alternatives
are a lispos without demand paging or nothing at all.
> As we enter the new age of 64 bit virtual addresses (due to the fact
> that 2 to 4 Gb is not enough for some problem sets), there will be
> some that say that we will never use all of the memory addressible
> by 64 bits. Don't believe them.
I do agree that for a 64-bit architecture, the question of having or
not having demand paging is rather different than for 32-bit
architectures. However (and I guess I should have mentioned this
before), I'm assuming a 32-bit architecture for "my" lispos. More
specifically, I'm assuming the "PC" architecture that is prevalent
today. I'm not talking about some generic kernel like NetBSD that
supports every device with an CPU there is. Quite the contrary, I'd
follow a trend that is popular in microkernel research these days,
which is to make kernels that are highly tuned to the architecture
they target. So I'm simply ignoring 64-bit architectures (for now).
> If you want to design a lispos that lasts, leave virtual memory in
> there.
What I'd want to last (i.e. outliving the PC architecture), if
anything, would be the upper-level abstractions that lispos provides
so that application compatibility is not lost. This is totally
othogonal to having or not having demand paging in a first
implementation.
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
> > Frode Vatvedt Fjeld <······@acm.org> writes:
> >
> > > I think a very reasonable design choice in this day and age would
> > > be to dispense with the virtual memory (as in disk-paging), and
> > > assert that there is enough real memory available. [ ... ]
>
> Duane Rettig <·····@franz.com> writes:
> >
> > Such an assertion would be wrong. There is never enough real
> > memory.
>
> If you qualify that statement with "for every concievable program",
> I'd agree. But if you start out any project with limited resources and
> the requirement of being all things to everybody, things will appear
> impossible.
You're talking about an operating system, so the qualification was
implicit; an operating system _must_ run every conceivable program
(or, at least, it must be willing to make promises to that effect :-)
in order to be successful. You don't need to be all things to
everybody out of the gate, but you must have a good plan to do so
eventually if you want to succeed long-term.
> Today, many users' response to seeing his machine swapping to disk is
> to buy more real memory.
Correct, although there are limits, both physical and address-wise,
as to how far one can go.
> It's also interesting to see that many people who regularly run
> machines with for example 64 MB real memory and 128 MB swap, 128+256
> or whatever, will thing you're crazy for running 1GB without swap.
I couldn't parse this statement (I assume you mean "think" instead of
"thing", but even then I don't know what you are saying). Could you
expand on this, or rephrase?
> Finally, assuming a 4GB address-space (see below),
Minor correction: most current 32-bit operating systems only give you
2 Gb of usable space, though a couple of them can give you 3 Gb.
> implementing demand
> paging today can only be justified by wanting to save money on
> RAM. That's an easy choice in my book, especially if the alternatives
> are a lispos without demand paging or nothing at all.
So what are you going to tell me when I try to run two copies of my
Huge-CAD-App concurrently on your operating system?
> > As we enter the new age of 64 bit virtual addresses (due to the fact
> > that 2 to 4 Gb is not enough for some problem sets), there will be
> > some that say that we will never use all of the memory addressible
> > by 64 bits. Don't believe them.
>
> I do agree that for a 64-bit architecture, the question of having or
> not having demand paging is rather different than for 32-bit
> architectures. However (and I guess I should have mentioned this
> before), I'm assuming a 32-bit architecture for "my" lispos. More
> specifically, I'm assuming the "PC" architecture that is prevalent
> today.
Let's go with that assumption for now. Let's say it takes you two
years to build your operating system, tuned for 32 bits, By the
time you get to the point where you are ready to introduce your
system to the world, even at worst case for the already late IA-64,
the new 64-bit operating systems will be out and will fast become
standard, and you will have latched on to the tail end of this
32-bit prevalence.
> I'm not talking about some generic kernel like NetBSD that
> supports every device with an CPU there is. Quite the contrary, I'd
> follow a trend that is popular in microkernel research these days,
> which is to make kernels that are highly tuned to the architecture
> they target. So I'm simply ignoring 64-bit architectures (for now).
I think that it would be a bad choice.
> > If you want to design a lispos that lasts, leave virtual memory in
> > there.
>
> What I'd want to last (i.e. outliving the PC architecture), if
> anything, would be the upper-level abstractions that lispos provides
> so that application compatibility is not lost.
This is precisely why I strongly suggest that you leave virtual memory
in.
> This is totally
> othogonal to having or not having demand paging in a first
> implementation.
I disagree with this statement. Demand paging vs non-virtual memory
management is a fundamental design decision in an operating system.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > If you qualify that statement with "for every concievable program",
> > I'd agree. But if you start out any project with limited resources and
> > the requirement of being all things to everybody, things will appear
> > impossible.
Duane Rettig <·····@franz.com> writes:
> You're talking about an operating system, so the qualification was
> implicit; an operating system _must_ run every conceivable program
> (or, at least, it must be willing to make promises to that effect
> :-) in order to be successful.
I'd have to disagree, as it is easy to concieve of some program that
linux or windows won't run.
> You don't need to be all things to everybody out of the gate, but
> you must have a good plan to do so eventually if you want to succeed
> long-term.
In fact, I already presented such a plan in my previous reply to you,
ableit somewhat vaguely. That plan was to implement a new, fresh
kernel for the 64-bit architecture when that is reasonably
available. This is in accord with the principle touted by leading
microkernel researchers like the L4 people, that kernels (specifically
microkernels) should not be portable programs, rather the opposite.
> > It's also interesting to see that many people who regularly run
> > machines with for example 64 MB real memory and 128 MB swap, 128+256
> > or whatever, will thing you're crazy for running 1GB without swap.
>
> [..] Could you expand on this, or rephrase?
It's not a terribly interesting point: People who happily run machines
with 128 MB real + 256 MB swap, for a total of 384 MB of accessible
memory, will think you crazy for running with 1GB of real memory
without swap. I find that strange.
> > Finally, assuming a 4GB address-space (see below),
>
> Minor correction: most current 32-bit operating systems only give
> you 2 Gb of usable space, though a couple of them can give you 3 Gb.
The _arcitecture_ provides 4 GB of address-space. The fact that
current operating system kernels only give user-space 2 or 3 GB is not
very relevant in this context.
> > implementing demand paging today can only be justified by wanting
> > to save money on RAM. That's an easy choice in my book, especially
> > if the alternatives are a lispos without demand paging or nothing
> > at all.
>
> So what are you going to tell me when I try to run two copies of my
> Huge-CAD-App concurrently on your operating system?
That one is easy: "Buy one more machine" :-) Seriously, "not all
things to all people" applies here. If somebody needs to run
applications that require more than ca. 2GB of memory, they should get
a 64-bit machine anyway. But don't blame _me_ if they don't find an
operating system for it.
Then again, if they _needed_ to run this stuff, they'd probably be
willing to pay for it, and so the likelihood that someone would
implement it would increase.
Now, If I was a company with such a "limited" lispos product, I would
surely try to convince everyone that the new lispos64 was just around
the corner, so if you need to run 10 huge-CAD-apps simultaneously --
no problem, buy my OS and you'll get an upgrade soon. I'm not,
however.
> Let's go with that assumption for now. Let's say it takes you two
> years to build your operating system, tuned for 32 bits, By the time
> you get to the point where you are ready to introduce your system to
> the world, even at worst case for the already late IA-64, the new
> 64-bit operating systems will be out and will fast become standard,
> and you will have latched on to the tail end of this 32-bit
> prevalence.
Maybe so. But it'd still be fun and interesting, and probably give
excellent experience and insight to those who afterwards wanted to
work with the new 64-bit architecture.
> > This is totally othogonal to having or not having demand paging in
> > a first implementation.
>
> I disagree with this statement. Demand paging vs non-virtual memory
> management is a fundamental design decision in an operating system.
I suspect we are somewhat disagreeing on the meaning of words
here. Anyways, what I'm arguing for leaving out of the lispos is
demand paging, where pages of memory are arbitrarily moved out of
frames in real memory to disk, and back into real memory (on "demand"
via page-faults).
Virtual memory on the other hand I consider to be the non-identity
mapping of user-space memory references to real memory, i.e. what you
use the MMU hardware for. This I do not want to leave out, as it
provides may benefits and does not add too much complexity to a
kernel. I suppose the presence of virtual memory will also have an
impact on the interface as seen by user-level applications.
Demand paging, on the other hand, is first of all supposed to be
totally transparent to user-level programs (at least in traditional
OSes). It increases the complexity of the kernel massively in that the
kernel must expect that any memory reference in user-space may
page-fault (and I wouldn't be surprised if there is a noticeable
performance-penalty here, too). And, again, assuming a 4 GB
address-space architecture and enough money to buy RAM, it provides
_no_ benefits.
So, providing user-level abstractions that don't scale up to 64-bit
architectures would be a bad design. But that doesn't imply that the
actual code I write for the current PC architecture should be directly
portable to anything else.
--
Frode Vatvedt Fjeld
Duane Rettig <·····@franz.com> wrote:
+---------------
| >Frode Vatvedt Fjeld <······@acm.org> writes:
| > Finally, assuming a 4GB address-space (see below),
|
| Minor correction: most current 32-bit operating systems only give you
| 2 Gb of usable space, though a couple of them can give you 3 Gb.
+---------------
Yup. For example, see <URL:http://oss.sgi.com/projects/bigmem/> for the
the SGI "bigmem" patch for Linux, which supports up to 3.8 GB physical
memory on IA-32, providing up to 3GB user space. [That URL also contains
a discussion of the performance costs of "bigmem" on IA32, including such
things as forcing drivers to use "bounce buffers" & bcopy'ing to access
certain areas of memory.]
+---------------
| > So I'm simply ignoring 64-bit architectures (for now).
|
| By the time you get to the point where you are ready to introduce
| your system to the world, even at worst case for the already late
| IA-64, the new 64-bit operating systems will be out and will fast
| become standard, and you will have latched on to the tail end of
| this 32-bit prevalence.
+---------------
Confirming signs:
1. We (and others) have already publicly demonstrated large applications
(e.g., clustered HPC codes) running under IA-64 Linux.
2. Porting of Linux to AMD's "Sledgehammer" (64-bit extension to Athlon)
has already started. <URL:http://www.x86-64.org/>
<URL:http://www.suse.com/suse/news/PressReleases/x86_64.html>
<URL:http://news.cnet.com/news/0-1003-200-2523097.html>
So from what I can see, we'll be starting down the "tail end" of IA-32
by next summer!
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
Centuries ago, Nostradamus foresaw a time when Duane Rettig would say:
>Frode Vatvedt Fjeld <······@acm.org> writes:
>
>> > Frode Vatvedt Fjeld <······@acm.org> writes:
>> >
>> > > I think a very reasonable design choice in this day and age would
>> > > be to dispense with the virtual memory (as in disk-paging), and
>> > > assert that there is enough real memory available. [ ... ]
>>
>> Duane Rettig <·····@franz.com> writes:
>> >
>> > Such an assertion would be wrong. There is never enough real
>> > memory.
>>
>> If you qualify that statement with "for every concievable program",
>> I'd agree. But if you start out any project with limited resources and
>> the requirement of being all things to everybody, things will appear
>> impossible.
>
>You're talking about an operating system, so the qualification was
>implicit; an operating system _must_ run every conceivable program
>(or, at least, it must be willing to make promises to that effect :-)
>in order to be successful. You don't need to be all things to
>everybody out of the gate, but you must have a good plan to do so
>eventually if you want to succeed long-term.
Indeed.
>> Today, many users' response to seeing his machine swapping to disk is
>> to buy more real memory.
>
>Correct, although there are limits, both physical and address-wise,
>as to how far one can go.
The folks that make QNX have gone reasonably far with the restriction
that "you have to have enough real memory."
>> Finally, assuming a 4GB address-space (see below),
>
>Minor correction: most current 32-bit operating systems only give you
>2 Gb of usable space, though a couple of them can give you 3 Gb.
I think there's a "hack" you can do with the Intel Xeon that provides
a way to get at 8GB of RAM.
Which is likely quite satisfactory for someone trying to do a
special-purpose thing like cacheing a relational database, where the
RAM would "basically" represent a Very Large RAMdisk.
Given an alternative between:
a) Buying a SCSI-based RAM drive with 8GB of RAM, and having to
write a memory manager to make use of it,
b) Putting 8GB of RAM on the main box, and having to write a memory
manager to make use of it,
where in either case, the "block of 8GB" costs around $30K, and needs
some custom drivers in order to support the application.
>> implementing demand
>> paging today can only be justified by wanting to save money on
>> RAM. That's an easy choice in my book, especially if the alternatives
>> are a lispos without demand paging or nothing at all.
>
>So what are you going to tell me when I try to run two copies of my
>Huge-CAD-App concurrently on your operating system?
I am not aware of any systems that implement shared libraries
_without_ supporting paged virtual memory; I'm don't think that it's
_not_ possible.
>> > As we enter the new age of 64 bit virtual addresses (due to the fact
>> > that 2 to 4 Gb is not enough for some problem sets), there will be
>> > some that say that we will never use all of the memory addressible
>> > by 64 bits. Don't believe them.
>>
>> I do agree that for a 64-bit architecture, the question of having or
>> not having demand paging is rather different than for 32-bit
>> architectures. However (and I guess I should have mentioned this
>> before), I'm assuming a 32-bit architecture for "my" lispos. More
>> specifically, I'm assuming the "PC" architecture that is prevalent
>> today.
>
>Let's go with that assumption for now. Let's say it takes you two
>years to build your operating system, tuned for 32 bits, By the
>time you get to the point where you are ready to introduce your
>system to the world, even at worst case for the already late IA-64,
>the new 64-bit operating systems will be out and will fast become
>standard, and you will have latched on to the tail end of this
>32-bit prevalence.
It would be as silly to say "2GB ought to be enough for anyone" as it
was for, um, others to say similar things about smaller numbers :-).
"640K ought to be enough for anybody" -- Bill Gates - 1981
_THAT_ seems to me to be the fundamental reason why few people are
likely to get too excited about the "Intel Xeon 8GB Hack;" anyone that
finds that amount of memory THAT necessary should _seriously_ consider
getting an Alpha box that requires _no_ addressing "hacks" to support
that much RAM.
>> I'm not talking about some generic kernel like NetBSD that
>> supports every device with an CPU there is. Quite the contrary, I'd
>> follow a trend that is popular in microkernel research these days,
>> which is to make kernels that are highly tuned to the architecture
>> they target. So I'm simply ignoring 64-bit architectures (for now).
>
>I think that it would be a bad choice.
Probably.
Mind you, IA-32 still has _some_ life left in it, and will continue to
get cheaper over time. I doubt Intel will invest _vastly_ in more
things like the "Xeon 8GB Hack;" they are more likely to start
spending _mucho_ bucks over the next couple of years to convince
everyone that "32 bits is pass\'e; 64 bits is the New Wave Of The
Future. If You Don't Catch The Wave, You'll Be Left Behind."
On the other hand, AMD is now working on a 64 bit version of the x86
architecture, which might let it survive longer than anyone would want
to think possible...
The point of the above is that it would be a little wise to be a
little cynical about the marketing taking place in both directions.
Assuming "32 bits forever" would be as dumb as believing in
"Apple ][ Forever." On the flip side, assuming that 32 bit systems
will be considered as "commercially pass\'e" as the Apple ][e three
years from now would _also_ be pretty dumb.
>> > If you want to design a lispos that lasts, leave virtual memory in
>> > there.
>>
>> What I'd want to last (i.e. outliving the PC architecture), if
>> anything, would be the upper-level abstractions that lispos provides
>> so that application compatibility is not lost.
>
>This is precisely why I strongly suggest that you leave virtual memory
>in.
Probably so.
>> This is totally othogonal to having or not having demand paging in
>> a first implementation.
>
>I disagree with this statement. Demand paging vs non-virtual memory
>management is a fundamental design decision in an operating system.
It's fundamental, but I'm not sure that there are only two choices.
--
(concatenate 'string "cbbrowne" ·@" "ntlug.org")
<http://www.hex.net/~cbbrowne/oses.html>
A Plateau is the highest form of flattery.
Christopher Browne wrote:
> It would be as silly to say "2GB ought to be enough for anyone" as it
> was for, um, others to say similar things about smaller numbers :-).
I personally don't think *I* will be able to live with
a 2 GB limit for much longer, in some Lisp applications.
I do hope we've got a Lisp with 48 or 64 bit pointers
coming along somewhere.
Paul
········@news.hex.net (Christopher Browne) writes:
> I am not aware of any systems that implement shared libraries
> _without_ supporting paged virtual memory; I'm don't think that it's
> _not_ possible.
I am. You are correct.
(The Amiga, circa 1985)
-dan
--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
* Frode Vatvedt Fjeld wrote:
> I do agree that for a 64-bit architecture, the question of having or
> not having demand paging is rather different than for 32-bit
> architectures. However (and I guess I should have mentioned this
> before), I'm assuming a 32-bit architecture for "my" lispos. More
> specifically, I'm assuming the "PC" architecture that is prevalent
> today. I'm not talking about some generic kernel like NetBSD that
> supports every device with an CPU there is. Quite the contrary, I'd
> follow a trend that is popular in microkernel research these days,
> which is to make kernels that are highly tuned to the architecture
> they target. So I'm simply ignoring 64-bit architectures (for now).
I think this would be a catastrophically bad decision. Apart from all
the obvious reasons (a LispOS which targets only small, semi-obsolete,
cheap machines, while at the same time demanding that the user stuff
them with memory because it can't even support the hardware they have?
hmmm...), it just ignores what Lisp has traditionally been good at:
solving large problems. Somewhere I have performance data gathered in
the late 80s showing that lisp machines won over stock-hardware boxes
exactly when the problem size was large enough to drive the machine
into heavy paging. *That's* where Lisp-based OS's won.
--tim
Tim Bradshaw <···@cley.com> writes:
> [..] (a LispOS which targets only small, semi-obsolete, cheap
> machines, while at the same time demanding that the user stuff them
> with memory because it can't even support the hardware they have?
> hmmm...) [..]
I think this is an instance of seeing the bottle as being half full or
half empty. Your choice, obviously.
--
Frode Vatvedt Fjeld
* Frode Vatvedt Fjeld wrote:
> I think a very reasonable design choice in this day and age would be
> to dispense with the virtual memory (as in disk-paging), and assert
> that there is enough real memory available. A lispos should also have
> a reasonable chance of handling out-of-memory conditions gracefully.
Absolutely not. You need VM in the remap-physical-memory sense in any
case, and you really want what mmap &c gives you so you can map random
files / devices into memory in flexible ways.
And since you will undoubtedly be targeting a 64bit machine, it's
really quite unlikely that there will be enough physical memory to
back an appreciable fraction of the address space in the near future.
And wanting to map a 10 or 100 Gb object into memory is not
unreasonable.
Of course, given how long it took the Unix people to get this vaguely
right, and that they now have, it might be a whole lot better to just
use Unix...
--tim
Tim Bradshaw <···@cley.com> writes:
> Absolutely not. You need VM in the remap-physical-memory sense in
> any case, and you really want what mmap &c gives you so you can map
> random files / devices into memory in flexible ways.
Mapping devices has nothing to do with demand paging, and mapping
files, while perhaps desirable, I don't consider a critical feature.
> And since you will undoubtedly be targeting a 64bit machine, [..]
Please read my response to Duane Rettig, where I answer this.
--
Frode Vatvedt Fjeld
* Frode Vatvedt Fjeld wrote:
> Mapping devices has nothing to do with demand paging, and mapping
> files, while perhaps desirable, I don't consider a critical feature.
Yes, it absolutely does have to do with paging. If you have the MMU
turned on so you can remap memory in interesting ways then you have to
be willing to handle page faults. So you have the whole page-fault
handler in the system *anyway*. The hard bit of paging is coping with
the fact that any memory reference can fault.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Frode Vatvedt Fjeld wrote:
>
> > Mapping devices has nothing to do with demand paging, and mapping
> > files, while perhaps desirable, I don't consider a critical
> > feature.
>
> Yes, it absolutely does have to do with paging. If you have the MMU
> turned on so you can remap memory in interesting ways then you have
> to be willing to handle page faults. So you have the whole
> page-fault handler in the system *anyway*.
No, in a system without demand paging, page faults should simply not
occur. That would be a kernel panic, if I ever saw one.
If you don't have demand paging, what do you foresee to be the cause
of a page fault?
> The hard bit of paging is coping with the fact that any memory
> reference can fault.
True, if you by "paging" mean "deman paging" as in "swapping" memory
to disk.
--
Frode Vatvedt Fjeld
>>>>> "FV" == Frode Vatvedt Fjeld <······@acm.org> writes:
FV> Tim Bradshaw <···@cley.com> writes:
[...]
>> ... If you have
>> the MMU turned on so you can remap memory in interesting ways
>> then you have to be willing to handle page faults. So you have
>> the whole page-fault handler in the system *anyway*.
FV> No, in a system without demand paging, page faults should
FV> simply not occur. That would be a kernel panic, if I ever saw
FV> one.
Tim's point, if I may jump in, is that the MMU mechanisms meant for
demand paging can be used for things _other than_ demand paging. One
such application I can think of would be read/write barriers for GC. If
you want to use stock hardware this way, then you will have to write
something that you could use in a VM subsystem. Then, the economy in
effort you gain by not-providing VM might be small enough that it
might be worthwhile to go the whole way anyway.
BM
Bulent Murtezaoglu <··@acm.org> writes:
> Tim's point, if I may jump in, is that the MMU mechanisms meant for
> demand paging can be used for things _other than_ demand paging.
> One such application I can think of would be read/write barriers for
> GC. If you want to use stock hardware this way, then you will have
> to write something that you could use in a VM subsystem. Then, the
> economy in effort you gain by not-providing VM might be small enough
> that it might be worthwhile to go the whole way anyway.
Yes, I agree this is a good point. It would make for a rather
different design decision than what has been discussed so far, however
(about the GC subsystem rather than memory "constraints").
I don't really know enough about GC to comment much (I'm trying to
read up on it, though), so let me just say this on general terms:
The real problem with demand paging is that any read into user-space
is a potentially blocking operation (since you may have to wait for
the disk to load the page). Since disks are so much slower than RAM,
performance requirements dictate that you must do something else while
waiting for the disk, and herein lies the complexity. It is not in the
act of setting up page-fault handlers.
Using paging hardware for GC read or write barriers, I _suspect_ that
memory references need not be considered blocking operations (because
there are no "slow" devices involved), hence the associated complexity
would also go away.
--
Frode Vatvedt Fjeld
* Frode Vatvedt Fjeld wrote:
> The real problem with demand paging is that any read into user-space
> is a potentially blocking operation (since you may have to wait for
> the disk to load the page). Since disks are so much slower than RAM,
> performance requirements dictate that you must do something else while
> waiting for the disk, and herein lies the complexity. It is not in the
> act of setting up page-fault handlers.
You just select another runnable process and carry on, until there is
no one runnable. At that point you probably run the GC a bit.
> Using paging hardware for GC read or write barriers, I _suspect_ that
> memory references need not be considered blocking operations (because
> there are no "slow" devices involved), hence the associated complexity
> would also go away.
Almost certainly you want to do the same trick here, except you let
the GC do work as soon as you hit a barrier.
--tim
> * Frode Vatvedt Fjeld wrote:
>
> > Since disks are so much slower than RAM, performance requirements
> > dictate that you must do something else while waiting for the
> > disk, and herein lies the complexity. It is not in the act of
> > setting up page-fault handlers.
Tim Bradshaw <···@cley.com> writes:
> You just select another runnable process and carry on, until there
> is no one runnable. At that point you probably run the GC a bit.
Right. And while we're at it, let me introduce the solution to the
travelling salesman problem: "just select the shortest path" :-)
Seriously, the problem is not so much page-faults that happen in the
context of user-level processes, but rather page-faults that happen in
the context of the kernel (for example when the IP stack in
kernel-space tries to access a buffer provided by user-space). Then
there is no "another runnable process". Unless, for example, you have
true kernel threads, in which case your whole programming model in the
kernel changes and you get new complexities and performance hits from
locking etc. It is not an unsolvable problem, obviously, just much
more difficult.
Hm.. come to think of it, maybe the problem could be neatly solved
with something akin to scheme continuations: When a pagefault occurs,
a continuation is returned by the faulting function and enqueued with
the page-fault handler, to be called when the page becomes
available.. This behavior could even be enforced by running every
kernel function that has the potential to cause page-faults with a
condition handler in place that handles any page-fault condition by
just returning a continuation for the faulting function. This way, the
actual function doesn't even have to make explicit checks for
page-faults, meaning less complicated code (only minor parts of the
kernel needs to know wheter there is demand paging or not) and less
performance overhead.. Comments, anyone?
If this scheme was to work, it should also be rather easy to retro-fit
over a kernel that was originally designed without thought for demand
paging :-) Assuming, of course, you have continuations, which I have a
hunch can be rather problematic beasts. Maybe some sort of lightweight
continuations would be more feasible.
--
Frode Vatvedt Fjeld
* Frode Vatvedt Fjeld wrote:
> Seriously, the problem is not so much page-faults that happen in the
> context of user-level processes, but rather page-faults that happen in
> the context of the kernel (for example when the IP stack in
> kernel-space tries to access a buffer provided by user-space). Then
> there is no "another runnable process". Unless, for example, you have
> true kernel threads, in which case your whole programming model in the
> kernel changes and you get new complexities and performance hits from
> locking etc. It is not an unsolvable problem, obviously, just much
> more difficult.
Well, Unix kernels do have real kernel threads nowadays (at least,
many do, certainly all the serious multiprocessor systems!). On a
traditional Lisp-based `OS' there was no distinct kernel of course, so
user-level threads/processes just work all the way down.
--tim
Frode Vatvedt Fjeld <······@acm.org> writes:
> Bulent Murtezaoglu <··@acm.org> writes:
>
> > Tim's point, if I may jump in, is that the MMU mechanisms meant for
> > demand paging can be used for things _other than_ demand paging.
> > One such application I can think of would be read/write barriers for
> > GC. If you want to use stock hardware this way, then you will have
> > to write something that you could use in a VM subsystem. Then, the
> > economy in effort you gain by not-providing VM might be small enough
> > that it might be worthwhile to go the whole way anyway.
>
> Yes, I agree this is a good point. It would make for a rather
> different design decision than what has been discussed so far, however
> (about the GC subsystem rather than memory "constraints").
>
> I don't really know enough about GC to comment much (I'm trying to
> read up on it, though), so let me just say this on general terms:
>
> The real problem with demand paging is that any read into user-space
> is a potentially blocking operation (since you may have to wait for
> the disk to load the page). Since disks are so much slower than RAM,
> performance requirements dictate that you must do something else while
> waiting for the disk, and herein lies the complexity. It is not in the
> act of setting up page-fault handlers.
>
> Using paging hardware for GC read or write barriers, I _suspect_ that
> memory references need not be considered blocking operations (because
> there are no "slow" devices involved), hence the associated complexity
> would also go away.
imho the system to beat is a stripped down unix (general sense so
linux or whatever is ok) with a decent common lisp running. the linux
kernel would do its thing, e.g., drive disks, virtual memory,
networking &c. keep X for driving the screen. start writing enough
stuff in lisp so that you don't have to ever interact with the
lowlevel guts.
what would a lisp system have that the above would not? i think that
for a lispos to be a viable thing you have to beat the current
solution.
perhaps i am na�f but the first thing i would want is some sort of
smart combination of virtual memory and garbage collection. am i
wrong here?
what are the compelling features of a lisp os?
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
sysengr
Johan Kullstam <········@ne.mediaone.net> writes:
> what are the compelling features of a lisp os?
That it would be fun and interesting. I wouldn't expect it to be the
most economically rational thing to do.
--
Frode Vatvedt Fjeld
In article <··············@dslab7.cs.uit.no>, Frode Vatvedt Fjeld
<······@acm.org> wrote:
>Bulent Murtezaoglu <··@acm.org> writes:
>
>> Tim's point, if I may jump in, is that the MMU mechanisms meant for
>> demand paging can be used for things _other than_ demand paging.
>> One such application I can think of would be read/write barriers for
>> GC. If you want to use stock hardware this way, then you will have
>> to write something that you could use in a VM subsystem. Then, the
>> economy in effort you gain by not-providing VM might be small enough
>> that it might be worthwhile to go the whole way anyway.
>
>Yes, I agree this is a good point. It would make for a rather
>different design decision than what has been discussed so far, however
>(about the GC subsystem rather than memory "constraints").
>
>I don't really know enough about GC to comment much (I'm trying to
>read up on it, though), so let me just say this on general terms:
>
>The real problem with demand paging is that any read into user-space
>is a potentially blocking operation (since you may have to wait for
>the disk to load the page). Since disks are so much slower than RAM,
>performance requirements dictate that you must do something else while
>waiting for the disk, and herein lies the complexity. It is not in the
>act of setting up page-fault handlers.
>
>Using paging hardware for GC read or write barriers, I _suspect_ that
>memory references need not be considered blocking operations (because
>there are no "slow" devices involved), hence the associated complexity
>would also go away.
Maybe I'm just a naif here, but isn't the whole notion of "demand paging"
in the context of a lispos a really stupid idea? Why would you ever want to
bring some fixed number (power of 2) contiguous bytes in from disk or swap
them out, in the hope that doing so will bring in most or all of the data
object(s) you want?
Or did I miss the part where "paging" was appropriately redefined?
paul
··@panix.com (Paul Wallich) writes:
> Maybe I'm just a naif here, but isn't the whole notion of "demand
> paging" in the context of a lispos a really stupid idea?
Well, in a lispos you'd certainly want to have some sort of
cooperation between the GC and demand pager subsystems, so that the
demand pager doesn't just load random pages from disk, but rather is
more or less guided by the GC. I believe there has been done a quite a
bit of research on this subject.
--
Frode Vatvedt Fjeld
* Paul Wallich wrote:
> Maybe I'm just a naif here, but isn't the whole notion of "demand
> paging" in the context of a lispos a really stupid idea? Why would
> you ever want to bring some fixed number (power of 2) contiguous
> bytes in from disk or swap them out, in the hope that doing so will
> bring in most or all of the data object(s) you want?
Well, you know that it will bring in at least *one* object you want
because you wouldn't have got the fault otherwise. If you have a
copying GC then you also likely have contiguously-allocated memory, so
it's likely that it will bring in more than one. Generally, achieving
good data locality is one of the tricks you need to work at since
even `real memory' no longer has anything like uniform-access time.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* Paul Wallich wrote:
>> Maybe I'm just a naif here, but isn't the whole notion of "demand
>> paging" in the context of a lispos a really stupid idea? Why would
>> you ever want to bring some fixed number (power of 2) contiguous
>> bytes in from disk or swap them out, in the hope that doing so will
>> bring in most or all of the data object(s) you want?
>
>Well, you know that it will bring in at least *one* object you want
>because you wouldn't have got the fault otherwise. If you have a
>copying GC then you also likely have contiguously-allocated memory, so
>it's likely that it will bring in more than one. Generally, achieving
>good data locality is one of the tricks you need to work at since
>even `real memory' no longer has anything like uniform-access time.
As long as your object and your page boundaries aren't aligned, however,
you're pretty much guaranteeing that you will fault again either in the
object you just brough in (if it's big) or in an adjacent one (if you've got
good locality). It seems to me that that assumption of "contiguously
allocated memory = good cache behavior" is not necessarily going to hold
here. Even, perhaps, to the point that some kind of sparse allocation
(depending on your associativity) might work better
paul
* Frode Vatvedt Fjeld wrote:
> No, in a system without demand paging, page faults should simply not
> occur. That would be a kernel panic, if I ever saw one.
Did you ever use a lisp OS? Half the point was that they didn't throw
up their hands in horror when getting some error. That was Unix's
fort\'e.
> If you don't have demand paging, what do you foresee to be the cause
> of a page fault?
Running out of memory? Hitting a write barrier? Trying to reuse a
buffer the disk subsystem hasn't flushed to disk yet?
--tim
Tim Bradshaw <···@cley.com> writes:
> * Frode Vatvedt Fjeld wrote:
>
> > No, in a system without demand paging, page faults should simply not
> > occur. That would be a kernel panic, if I ever saw one.
>
> Did you ever use a lisp OS? Half the point was that they didn't throw
> up their hands in horror when getting some error. That was Unix's
> fort\'e.
>
> > If you don't have demand paging, what do you foresee to be the cause
> > of a page fault?
>
> Running out of memory? Hitting a write barrier? Trying to reuse a
> buffer the disk subsystem hasn't flushed to disk yet?
Surely I'm no master in the art of writing english, but hopefully you
are able to put a little more effort than this into understanding what
I say.
Your comments make no sense, whatsoever.
--
Frode Vatvedt Fjeld
* Frode Vatvedt Fjeld wrote:
> Tim Bradshaw <···@cley.com> writes:
>> * Frode Vatvedt Fjeld wrote:
>> > If you don't have demand paging, what do you foresee to be the cause
>> > of a page fault?
>>
>> Running out of memory? Hitting a write barrier? Trying to reuse a
>> buffer the disk subsystem hasn't flushed to disk yet?
> Surely I'm no master in the art of writing english, but hopefully you
> are able to put a little more effort than this into understanding what
> I say.
If I don't have demand paging, I foresee the things I mention above as
being causes of page faults. Makes sense to me. Perhaps not to you,
I guess.
--tim
Tim Bradshaw <···@cley.com> writes:
> > I think a very reasonable design choice in this day and age would be
> > to dispense with the virtual memory (as in disk-paging), and assert
> > that there is enough real memory available. A lispos should also have
> > a reasonable chance of handling out-of-memory conditions gracefully.
>
> Absolutely not. You need VM in the remap-physical-memory sense in any
> case, and you really want what mmap &c gives you so you can map random
> files / devices into memory in flexible ways.
Alternatively, why not make _everything_ VM (i.e. your virtual memory
space is the size of your hard disk, and the real RAM is used as a
"cache") and forget about having a filesystem?
--
Adam Sampson
···@gnu.org
Adam Sampson <···@gnu.org> wrote:
>Alternatively, why not make _everything_ VM (i.e. your virtual memory
>space is the size of your hard disk, and the real RAM is used as a
>"cache") and forget about having a filesystem?
I've been championing that idea for a while now. I believe
it's called "Single-Address Space Operating System" and it
often extends beyond local storage. The idea is to use one
address space for all data, regardless of which physical
medium it is stored in. Memory hierarchy is used only for
performance and persistence requirements.
Dan.
FM (·····@dartmouth.edu) wrote:
: Adam Sampson <···@gnu.org> wrote:
: >Alternatively, why not make _everything_ VM (i.e. your virtual memory
: >space is the size of your hard disk, and the real RAM is used as a
: >"cache") and forget about having a filesystem?
: I've been championing that idea for a while now. I believe
: it's called "Single-Address Space Operating System" and it
: often extends beyond local storage. The idea is to use one
: address space for all data, regardless of which physical
: medium it is stored in. Memory hierarchy is used only for
: performance and persistence requirements.
This was implemented in Multics.
: Dan.
john casu <·····@world.std.com> wrote:
>FM (·····@dartmouth.edu) wrote:
>: Adam Sampson <···@gnu.org> wrote:
>: >Alternatively, why not make _everything_ VM (i.e. your virtual memory
>: >space is the size of your hard disk, and the real RAM is used as a
>: >"cache") and forget about having a filesystem?
>: I've been championing that idea for a while now. I believe
>: it's called "Single-Address Space Operating System" and it
>: often extends beyond local storage. The idea is to use one
>: address space for all data, regardless of which physical
>: medium it is stored in. Memory hierarchy is used only for
>: performance and persistence requirements.
>
>This was implemented in Multics.
Interesting. My knowledge of old Operating Systems
is admittedly short, but I didn't quite remember
Multics in that sense. I think all file access was
memory-mapped through segments but I'm not sure of
much else. Care to elaborate?
Dan.
>>>>> On 28 Aug 2000 08:53:47 GMT, FM ("FM") writes:
FM> john casu <·····@world.std.com> wrote:
>> FM (·····@dartmouth.edu) wrote:
>> : Adam Sampson <···@gnu.org> wrote:
>> : >Alternatively, why not make _everything_ VM (i.e. your virtual memory
>> : >space is the size of your hard disk, and the real RAM is used as a
>> : >"cache") and forget about having a filesystem?
>> : I've been championing that idea for a while now. I believe
>> : it's called "Single-Address Space Operating System" and it
>> : often extends beyond local storage. The idea is to use one
>> : address space for all data, regardless of which physical
>> : medium it is stored in. Memory hierarchy is used only for
>> : performance and persistence requirements.
>>
>> This was implemented in Multics.
FM> Interesting. My knowledge of old Operating Systems
FM> is admittedly short, but I didn't quite remember
FM> Multics in that sense. I think all file access was
FM> memory-mapped through segments but I'm not sure of
FM> much else. Care to elaborate?
Each process was a single address space that included the operating system,
the user program, and the data. (The address space was divided into segments,
which are the unit of memory protection and memory persistence.)
Read any operating systems textbook that explains Multics; you could
start at <http://www.multicians.org> which has some online materials,
and bibliography references to 159 papers and books, 7 magazine articles,
44 published reports from the project, and about 150 Multics manuals.
Christopher C Stacy <······@world.std.com> wrote:
> >> This was implemented in Multics.
> FM> Interesting. My knowledge of old Operating Systems
> FM> is admittedly short, but I didn't quite remember
> FM> Multics in that sense. I think all file access was
> FM> memory-mapped through segments but I'm not sure of
> FM> much else. Care to elaborate?
>Each process was a single address space that included the operating system,
>the user program, and the data. (The address space was divided into segments,
>which are the unit of memory protection and memory persistence.)
Interesting. But the file system existed independently
of the virtual memory and files had to be mapped into
user segments before used, right? The way I understand
is that the file system wasn't part of the virtual
address space of the program. In other words, the
virtual memory depended on the file system but not the
other way around? Am I on the right track here?
>Read any operating systems textbook that explains Multics; you could
>start at <http://www.multicians.org> which has some online materials,
>and bibliography references to 159 papers and books, 7 magazine articles,
>44 published reports from the project, and about 150 Multics manuals.
Thanks.
Dan.
·····@dartmouth.edu (FM) writes:
[about Multics]
> Interesting. But the file system existed independently
> of the virtual memory and files had to be mapped into
> user segments before used, right? The way I understand
> is that the file system wasn't part of the virtual
> address space of the program. In other words, the
> virtual memory depended on the file system but not the
> other way around? Am I on the right track here?
Not quite. The concept of sequential files was built on top of the
virtual memory system. The normal way of accessing data was not
through the file system, but by using a segment. A segment was a
persistent fixed-size table of data that was automatically mapped into
the address space when used.
Segments did not have unique addresses, though. Each process had its
own address space in which addresses were pairs <segment-number,
offset>. This was transparent to the user and the programmer,
however, who used only symbolic addresses of the form
segment-name$symbol. The dynamic linker automatically mapped symbolic
addresses to pairs the first time a process used a segment.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
As well as IBM's AS/400 series.
faa
"Christopher C Stacy" <······@world.std.com> wrote in message
····················@world.std.com...
> This is also how the Lisp Machine worked.
Christopher C Stacy wrote:
>
> This is also how the Lisp Machine worked.
Huh? None of the LispMs used memory-mapped I/O for filesystem access, nor were
the filesystem partitions mapped into the address space. The machine was quite
conventional in this respect -- to my disappointment, I must say, as I was
hoping for a persistent Lisp even back then. (In fairness, how to build one
remains an open research problem.)
Greenblatt's Moby Memory project would have changed this, IIRC, with a 48-bit
global address space shared among machines (!), but I don't think he got very
far on it.
-- Scott
On Mon, 28 Aug 2000 21:36:07 -0700, "Scott L. Burson"
<·······@my-dejanews.com> wrote:
> the filesystem partitions mapped into the address space. The machine was quite
> conventional in this respect -- to my disappointment, I must say, as I was
> hoping for a persistent Lisp even back then. (In fairness, how to build one
Wasn't Symbolics Statice a persistent database for LispMs?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso <·······@mclink.it> writes:
>On Mon, 28 Aug 2000 21:36:07 -0700, "Scott L. Burson"
><·······@my-dejanews.com> wrote:
>> the filesystem partitions mapped into the address space. The machine was quite
>> conventional in this respect -- to my disappointment, I must say, as I was
>> hoping for a persistent Lisp even back then. (In fairness, how to build one
>Wasn't Symbolics Statice a persistent database for LispMs?
AFAIK, it was more of a relational database (means: explicit storage
and retrieval instead of "automatic" persistence for data). The point
was that it did use neither embedded SQL nor SQL statements in
strings, but instead defined a relational syntax in Lisp. So that
indenting and otehr source tools worked and at the same time
compile-time checking was possible (instead of runtime lookup of SQL
statements in strings).
I would be happy to see a manual of Statice on the Web, but last time
I looked, I didn't find one.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
>>>>> On Mon, 28 Aug 2000 21:36:07 -0700, Scott L Burson ("Scott") writes:
Scott> Christopher C Stacy wrote:
>>
>> This is also how the Lisp Machine worked.
Scott> Huh? None of the LispMs used memory-mapped I/O for filesystem access, nor were
Scott> the filesystem partitions mapped into the address space. The machine was quite
Scott> conventional in this respect -- to my disappointment, I must say, as I was
Scott> hoping for a persistent Lisp even back then. (In fairness, how to build one
Scott> remains an open research problem.)
Scott> Greenblatt's Moby Memory project would have changed this, IIRC, with a 48-bit
Scott> global address space shared among machines (!), but I don't think he got very
Scott> far on it.
Scott> -- Scott
You are correct: I was referring only to the idea that there was a
single address space shared by both the user and operating systems.
Of course, data was persistent across boots by manually saving a
"world load" disk image - that's how the system worked, and this was
used for system configuration. But programs normally read and write
data using conventional files and network streams and so forth.
Later, the Symbolics operating system did provide an object
database ststem called "Statice", which provided object persistence.
Adam Sampson <···@gnu.org> writes:
>Tim Bradshaw <···@cley.com> writes:
>> > I think a very reasonable design choice in this day and age would be
>> > to dispense with the virtual memory (as in disk-paging), and assert
>> > that there is enough real memory available. A lispos should also have
>> > a reasonable chance of handling out-of-memory conditions gracefully.
>>
>> Absolutely not. You need VM in the remap-physical-memory sense in any
>> case, and you really want what mmap &c gives you so you can map random
>> files / devices into memory in flexible ways.
>Alternatively, why not make _everything_ VM (i.e. your virtual memory
>space is the size of your hard disk, and the real RAM is used as a
>"cache") and forget about having a filesystem?
One basic problem is "when to synchronize". If everything is mmap'ed
(Unix term) to file's, things will be transparently persistent and
cached. But if the system or process crashes, the mmap'ed region may
be in an incomplete state, with no inherited method of even telling
that it is "dirty".
One detail problem with current hardware is that a system with many
processes, each using memory mapping instead of read/write to open
files is very costly. Each individual memory mapping increases the
number of map regions that must be stored and restored at task
switches. Even the basic cost of creating one new mapping is very
high. This is, BTW, a common problem with Unix applications: people
benchmark their individual application and find it to be faster with
mmap than with rwad/write. Once they go into production with many
users and possibly other mapping-intensive applications on the same
machine, the whole thing gets slow.
Another problem with that is about resizing a file. Where the write()
system call does it automatically for you, resizing a mmap'ed region
is inefficient and subject to synchronization problems if not on a
page boundary. Cost is enourmous if N(writes) approaches N(resizes).
If you say, OK, but read/write applications have their share of
problems with reliablity and finding a suitable synchronisatioon API
and you need transactions anyway, things switch again. But serious
stores with transactions usually interface to the OS on a
array-of-blocks basis, using neither filesystems nor MMU-supported
memory mapping. Transaction-based storage also pushes flexibility
back an order of magnitude. Few Lisp folks may want to live under the
constraints of currently well-researched transaction-based stores.
If you plan to go into research, my formerly expressed opion applies
again: You cannot implement a complex project intended for production
use while at the same time doing serious research on fundamental
design issues. Especially not in a volunteer project where you cannot
enforce a barrier between the two groups.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Centuries ago, Nostradamus foresaw a time when Frode Vatvedt Fjeld would say:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
>> For SCSI, the fast (no, the non-crawling-slow) parts are all very
>> complicated, see my other post. And a SCSI subsystem with error
>> handling is even more, independent of the controller in use.
>
>Granted it is not trivial, but I fail to see what it is with a SCSI
>subsystem that makes it next to impossible to implement with
>reasonable efficiency and amounts of effort. I'm not sure which post
>you are referring to, but none of those I've seen made strong
>arguments to that effect.
The problem is that it's not two extremes that one must jump to,
but rather a more complex continuum.
>Error handling in particular should be a lot easier if you have a
>language with decent support for exceptional situations.
Having better exception support helps with one part of the process
of getting an OS to support SCSI hardware.
But that's only one part of the process.
Another lavish portion of why SCSI drivers are regarded as "fairly
complex" is that the SCSI hardware is fairly complex, often a little bit
buggy, as well as "pretty variable." Adaptec hardware has been known
to have significant variations between one month and the next on the
_same model of board_.
Someone has got to become Reasonably Expert at understanding how a
particular SCSI host adaptor works before a single line of code is
written in _ANY_ computer language. Understanding the hardware is the
big barrier, not the language.
Making up numbers, the process of producing a SCSI driver
in C might take 6 months.
Of that 6 months, the first two months might be spent reading the
hardware manuals and constructing a mental model of How It Works.
Then two months is spent coding. And two months is spent testing.
Supposing Lisp made coding ten times more productive, that would drop the
amount of time from 6 months to a little over 4. It wouldn't diminish
the initial two months of "reading specs" one iota.
--
········@acm.org - <http://www.ntlug.org/~cbbrowne/>
"...Roxanne falls in love with Christian, a chevalier in Cyrano's
regiment who hasn't got the brains God gave an eclair..."
-- reviewer on NPR
Centuries ago, Nostradamus foresaw a time when Frode Vatvedt Fjeld would say:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
>> For SCSI, the fast (no, the non-crawling-slow) parts are all very
>> complicated, see my other post. And a SCSI subsystem with error
>> handling is even more, independent of the controller in use.
>
>Granted it is not trivial, but I fail to see what it is with a SCSI
>subsystem that makes it next to impossible to implement with
>reasonable efficiency and amounts of effort. I'm not sure which post
>you are referring to, but none of those I've seen made strong
>arguments to that effect.
>
>Error handling in particular should be a lot easier if you have a
>language with decent support for exceptional situations.
>
>> Frode Vatvedt Fjeld <······@acm.org> writes:
>>
>> >You'd very much want to _avoid_ devices that require 10.000-line
>> >drivers that are different for every BIOS or what have you.
>
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
>> Uh, there is nothing about the BIOS versions that cause changes to
>> the drivers. It's the new revisions of the SCSI chips that cause
>> problems.
>
>I was repeating my recollection of someone else's decription of the
>difficulties with some SCSI controllers, as an example of bad hardware
>you'd want to avoid, <·······················@knuth.brownes.org>. I
>figured he was talking about the "BIOS" (some sort of firmware, I
>guess) that some SCSI controllers have. Anyways, this is all
>completely besides the point of this discussion.
BIOSes are an issue at boot time; they tend to be used to negotiate
what capabilities the hardware has, and how they are to be interfaced
to.
Analogy with Linux is pretty apropos here:
- Once the system has booted up, Linux makes _ZERO_ use of BIOS, as
the capabilities that it directly uses, whether of video cards or
SCSI controllers, are internal to the kernel. Thus, once the system
is up and running, BIOS issues are of little relevance. Although if
BIOS differences result from actual hardware differences between one
card revision to another, those hardware differences _ARE_ relevant.
- However, _at_ boot time, Linux isn't running yet. Some form of
"boot process" is running, whether:
a) BIOS ROMs on the PC motherboard,
b) A boot loader like LILO, MILO, SILO, OpenBoot, or Grub.
THOSE subsystems need to be somewhat aware of the BIOS.
In a LispOS, there needs to be a bootloader, ideally one that can
interoperate with things like LILO and Grub, so as to take advantage
of what hardware advances they get. But all of this is pretty much an
aside.
A change of BIOS may demonstrate merely that the vendor has tweaked
the BIOS in some way; that may be of some relevance to the boot
process, but if BIOS is not used at runtime, this is not of great
relevance. On the other hand, a change of BIOS may result from a
change in the other hardware, and require that you modify the SCSI
driver in the kernel correspondingly.
The major point I was trying to make was that a significant amount of
ongoing effort would need to go into addressing the _hardware_ issues
surrounding different versions of SCSI hardware. A BIOS change _may_
indicate a hardware change; that must be investigated _every time_.
>> Comments like that are exactly what I'm meant: I have to assume that
>> you don't have a clue about what the BIOS does and where a driver
>> attaches to a SCSI card.
>
>Why do you feel compelled to assume such a thing?
>
>> You should not post about it unless you do, otherwise the effect
>> that Christopher saws in LispOS applies here as well.
>
>Well, if it helps me qualify for further discussions, I can inform you
>that I have written a SCSI driver or two, on architectures with and
>without BIOSes (although I must confess to never actually having used
>"the BIOS").
>
>Incidently, one of the controllers for which I've written a driver
>does indeed provide a very simple and fast hardware interface. So they
>exist, and you can go buy them in the shop.
That's well and good; that is suggestive that you could be a good
candidate to be the "SCSI guy" in a LispOS project. [Note that this
means I'm doing the classic thing of assigning work to _someone
else_.]
For a LispOS to actually work, there needs to be the "SCSI Guy," as
well as the "Motherboard Guy," and the "Video Guy," and the "Boot
Guy," the "Memory Management Guy," the "Network Guy," the "CPU Guy,"
and probably some other roles of "_SOMETHING_ Guy."
Note that all of the above merely outlines the "near-to-the-hardware"
roles; none of it directly provides any "cool Lisp stuff."
The _point_ is that to have a LispOS, there needs to be a group of
these people doing "gritty low level stuff."
The _nasty_ part is that this stuff all interacts with the higher
level stuff; _ideally_, the Lisp environment should support writing
good physical driver code as well as the CLOS implementation, which
means that the high level parts of the implementation determine lots
of stuff about the bowels of the system, and vice-versa.
For instance, if the system provides a visible machine language
interface, that will be useful both for implementing hardware drivers
as well as for implementing efficient data and control structures.
Right away, you need to have a dozen clever people willing to devote a
lot of time to hardware issues and to compiler issues and to building
front ends. _THAT_ is what's daunting about the project.
--
(concatenate 'string "aa454" ·@" "freenet.carleton.ca")
<http://www.hex.net/~cbbrowne/lisposes.html>
"Just because it's free doesn't mean you can afford it." -- Unknown
Centuries ago, Nostradamus foresaw a time when Frode Vatvedt Fjeld would say:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
>> For SCSI, the fast (no, the non-crawling-slow) parts are all very
>> complicated, see my other post. And a SCSI subsystem with error
>> handling is even more, independent of the controller in use.
>
>Granted it is not trivial, but I fail to see what it is with a SCSI
>subsystem that makes it next to impossible to implement with
>reasonable efficiency and amounts of effort. I'm not sure which post
>you are referring to, but none of those I've seen made strong
>arguments to that effect.
>
>Error handling in particular should be a lot easier if you have a
>language with decent support for exceptional situations.
>
>> Frode Vatvedt Fjeld <······@acm.org> writes:
>>
>> >You'd very much want to _avoid_ devices that require 10.000-line
>> >drivers that are different for every BIOS or what have you.
>
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
>> Uh, there is nothing about the BIOS versions that cause changes to
>> the drivers. It's the new revisions of the SCSI chips that cause
>> problems.
>
>I was repeating my recollection of someone else's decription of the
>difficulties with some SCSI controllers, as an example of bad hardware
>you'd want to avoid, <·······················@knuth.brownes.org>. I
>figured he was talking about the "BIOS" (some sort of firmware, I
>guess) that some SCSI controllers have. Anyways, this is all
>completely besides the point of this discussion.
BIOSes are an issue at boot time; they tend to be used to negotiate
what capabilities the hardware has, and how they are to be interfaced
to.
Analogy with Linux is pretty apropos here:
- Once the system has booted up, Linux makes _ZERO_ use of BIOS, as
the capabilities that it directly uses, whether of video cards or
SCSI controllers, are internal to the kernel. Thus, once the system
is up and running, BIOS issues are of little relevance. Although if
BIOS differences result from actual hardware differences between one
card revision to another, those hardware differences _ARE_ relevant.
- However, _at_ boot time, Linux isn't running yet. Some form of
"boot process" is running, whether:
a) BIOS ROMs on the PC motherboard,
b) A boot loader like LILO, MILO, SILO, OpenBoot, or Grub.
THOSE subsystems need to be somewhat aware of the BIOS.
In a LispOS, there needs to be a bootloader, ideally one that can
interoperate with things like LILO and Grub, so as to take advantage
of what hardware advances they get. But all of this is pretty much an
aside.
A change of BIOS may demonstrate merely that the vendor has tweaked
the BIOS in some way; that may be of some relevance to the boot
process, but if BIOS is not used at runtime, this is not of great
relevance. On the other hand, a change of BIOS may result from a
change in the other hardware, and require that you modify the SCSI
driver in the kernel correspondingly.
The major point I was trying to make was that a significant amount of
ongoing effort would need to go into addressing the _hardware_ issues
surrounding different versions of SCSI hardware. A BIOS change _may_
indicate a hardware change; that must be investigated _every time_.
>> Comments like that are exactly what I'm meant: I have to assume that
>> you don't have a clue about what the BIOS does and where a driver
>> attaches to a SCSI card.
>
>Why do you feel compelled to assume such a thing?
>
>> You should not post about it unless you do, otherwise the effect
>> that Christopher saws in LispOS applies here as well.
>
>Well, if it helps me qualify for further discussions, I can inform you
>that I have written a SCSI driver or two, on architectures with and
>without BIOSes (although I must confess to never actually having used
>"the BIOS").
>
>Incidently, one of the controllers for which I've written a driver
>does indeed provide a very simple and fast hardware interface. So they
>exist, and you can go buy them in the shop.
That's well and good; that is suggestive that you could be a good
candidate to be the "SCSI guy" in a LispOS project. [Note that this
means I'm doing the classic thing of assigning work to _someone
else_.]
For a LispOS to actually work, there needs to be the "SCSI Guy," as
well as the "Motherboard Guy," and the "Video Guy," and the "Boot
Guy," the "Memory Management Guy," the "Network Guy," the "CPU Guy,"
and probably some other roles of "_SOMETHING_ Guy."
Note that all of the above merely outlines the "near-to-the-hardware"
roles; none of it directly provides any "cool Lisp stuff."
The _point_ is that to have a LispOS, there needs to be a group of
these people doing "gritty low level stuff."
The _nasty_ part is that this stuff all interacts with the higher
level stuff; _ideally_, the Lisp environment should support writing
good physical driver code as well as the CLOS implementation, which
means that the high level parts of the implementation determine lots
of stuff about the bowels of the system, and vice-versa.
For instance, if the system provides a visible machine language
interface, that will be useful both for implementing hardware drivers
as well as for implementing efficient data and control structures.
Right away, you need to have a dozen clever people willing to devote a
lot of time to hardware issues and to compiler issues and to building
front ends. _THAT_ is what's daunting about the project.
--
(concatenate 'string "aa454" ·@" "freenet.carleton.ca")
<http://www.hex.net/~cbbrowne/lisposes.html>
"Just because it's free doesn't mean you can afford it." -- Unknown
* Martin Cracauer wrote:
> For SCSI, the fast (no, the non-crawling-slow) parts are all very
> complicated, see my other post. And a SCSI subsystem with error
> handling is even more, independent of the controller in use.
Exactly. You do need to support reasonably well-performing hardware in
a reasonably well-performing way, and that stuff is just complicated.
It would be nice to think that Lisp can radically simplify it, but I
don't believe that's true: I'm sure it's *simpler*, but there is a
certain inherent complexity to this stuff.
--tim
Frode,
I think a lot of people agree generally on the "fun and interesting"
aspects of some kind of Lisp-based OS. I certainly do, from purely
personal viewpoints.
As you know, this Lisp OS thing was thoroughly discussed, chewed, summed
up, split up, camps formed, etc, earlier, and all of that is available
for reading, on the net. With this in mind, could you perhaps expand
your ideas a bit? I am not being devious, only interested.
Frode Vatvedt Fjeld wrote:
>
> The relevant question is "where can I buy a machine that will run
> lispos?", not "will lispos run on my old machine brand XX?".
>
Well yes, but to begin, you would have to define the hardware to be used
in the development stage. And if people are to collaborate, what are the
minimum common requirements?
> So you'd start out building a _system_ (machine + lispos), where you
> carefully pick hardware that provide the best hardware interfaces
> (simple to use, fast, and cheap, in that order of preference). You'd
> very much want to _avoid_ devices that require 10.000-line drivers
> that are different for every BIOS or what have you. I think such a
> system would be interesting to a lot of people, even if they'd have to
> invest in new hardware.
>
See above. What is a reasonable starting level for the software to be
written? What kind of development environment? Programming language?
> Yes, it still needs to be done, and it's not "that easy". I'm just
> saying that there _are_ other options than having 10 full-time
> employed people working for X years and in the end come out with a
> complete lispos kernel and environment that supports everything linux
> or windows do.
At least there would be stated objectives, an end goal to go for, with
milestones in between, that the team can plan against. Have you any
ideas on how to deal with this in a non-personal project (assuming you
have one in mind)? What time-scale do you foresee? Required level of
expertise?
> CMUCL and free-clim are nice, but they are not a lispos. People spend
> their free time doing what they think is fun or interesting, and some
> might find a lispos more fun than CMUCL/unix.
Well, I might agree, but what kind of OS and what kind of application
programs do you have in mind?
Any Lisp-based OS, beyond one for a strictly personal use, must
necessarily take into account those factors that Duane, Tim and others
now point out (again). There is simply too much work to do, even if you
set aside programming and testing the thing, unless proven code modules
are reused.
Lars
Lars Lundback <·············@era.ericsson.se> writes:
> As you know, this Lisp OS thing was thoroughly discussed, chewed,
> summed up, split up, camps formed, etc, earlier, and all of that is
> available for reading, on the net. With this in mind, could you
> perhaps expand your ideas a bit? I am not being devious, only
> interested.
Well, I've tried to look at the ongoing (?) lispos efforts, but quite
frankly I didn't find too much there that I found very interesting.
Suffice it to say I would describe myself as an OS kind of person that
has taken a liking to (common) lisp and all its ways, so I guess I'm
sort of doubly attracted to this lispos thing. I've recently become
confident enough with lisp that I feel that I have a reasonable grasp
of the complexities involved in making a lisp system.
My idea (to the extent I have one) would be to write both of a
language/compiler and a kernel, both highly tuned to the PC x86
architecture (which, by the way, I don't think will be obsolete any
time very soon). The language/compiler would be strictly for writing
the kernel in, and so should be considered a part of the kernel source
code, and nothing like a competitor to CMUCL (i.e. not meant for
applications).
By the way, the x86 architecture, for all its weird and admittedly
ugly stuff forced in there by the quest for backwards compatibility,
is actually rather interesting from an OS designer's perspective, if
one just removes the traditional unix portable OS straight-jacket :-)
> Well yes, but to begin, you would have to define the hardware to be
> used in the development stage. And if people are to collaborate,
> what are the minimum common requirements?
Well, I'd say "a PC". Or make that "a PC with memory", the more the
better, obviously. Hm.. make that a "pentium or later generation CPU
PC with memory", as writing a compiler today I wouldn't bother with
supporting 386s and such.
Then of course, if you want networking, someone must write a NIC
driver, and you either need to get that card that someone else wrote a
driver for, or you must write a driver for your card. And so on. When
there is at least one NIC driver, one SCSI driver etc. you'll have a
rather complete lisp system. The choice of which particular device to
support would be up to whoever writes the driver to
decide. Personally, I'd happily pay some extra bucks for the device if
it saves me months of work on the device driver.
> See above. What is a reasonable starting level for the software to
> be written? What kind of development environment? Programming
> language?
If I had any say at all, the development environment would be Common
Lisp. Plus the new (in CL written) kernel-lisp, obviously.
> At least there would be stated objectives, an end goal to go for,
> with milestones in between, that the team can plan against. Have you
> any ideas on how to deal with this in a non-personal project
> (assuming you have one in mind)? What time-scale do you foresee?
> Required level of expertise?
I don't know about these things. Maybe the most viable option is to
have the most basic ground-work[1] laid down by a very small group of
people, and then let it (hopefully) grow like cancer, but as
controlled as possible.
> Well, I might agree, but what kind of OS and what kind of
> application programs do you have in mind?
For applications, a Common Lisp environment would rank high on my
list of things I'd like to have running on the lispos.
[1] The skeleton of a language/compiler, the beginnings of a dynamic
typing/GC subsystem, and most importantly a floppy image one can boot
and let you do this:
? (loop (write "Hello World!"))
...
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
> By the way, the x86 architecture, for all its weird and admittedly
> ugly stuff forced in there by the quest for backwards compatibility,
> is actually rather interesting from an OS designer's perspective, if
> one just removes the traditional unix portable OS straight-jacket :-)
History seems to be going against you. Linus Torvalds started Linux as
a way to familiarize himself more with his new 386 and the first
versions of Linux were full of x86 weirdness. 0.12 upto 0.99 and
perhaps beyond used x86 TSS's and a lot of the other weird and ugly
stuff. Almost all of this later turned out to be a mistake and has
been removed from the kernel.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
> History seems to be going against you. Linus Torvalds started Linux as
> a way to familiarize himself more with his new 386 and the first
> versions of Linux were full of x86 weirdness. 0.12 upto 0.99 and
> perhaps beyond used x86 TSS's and a lot of the other weird and ugly
> stuff. Almost all of this later turned out to be a mistake and has
> been removed from the kernel.
The key word here being "later". If he'd set out _at the beginning_
to write a fully portable system, do you think the project would have
survived to the stage where such introspection was viable?
Incremental development is probably what made Linux so much fun.
Hey, if Frode wants to write a LispOS, let him get on with it. My
prediction is that it will be as doomed to failure as the last two
efforts were, given that his plan seems to involve starting by writing
a Lisp compiler (Linux at least had GCC to start with) but I'd be
really happy to be proved wrong. "Show us the code".
(For my money I'd rather have a nice free lisp development environment
atop of Linux, and replace bits of Linux infrastructure incrementally
-- System V runlevels will be the first against the wall -- as
the need arises. For example, you could do TCP in CL with
SOCK_PACKET. You could probably help GC a lot by appropriate use of
madvise() and mincore(). If the interface they give you is
insufficient, talk to the Linux developers, and they'll probably be
happy to extend it. Or at least, to accept patches ...)
-dan
--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
Daniel Barlow <···@telent.net> writes:
[...]
> Hey, if Frode wants to write a LispOS, let him get on with it. My
> prediction is that it will be as doomed to failure as the last two
> efforts were,
I'd like to reiterate something I earlier wrote.
I claim that for any Lisp OS effort in general to succeed it is
necessary (though not sufficient) for there to exist individuals that
(i) have the proper highly specialized education and expertise AND
(ii) are brilliant AND
(iii) are motivated and willing to commit the man-years necessary.
To get the project off to a decent start, I claim there must exist at
least one individual satisfying (i)-(iii).
Christopher
Daniel Barlow <···@telent.net> writes:
> Hey, if Frode wants to write a LispOS, let him get on with it. My
> prediction is that it will be as doomed to failure as the last two
> efforts were, given that his plan seems to involve starting by writing
> a Lisp compiler (Linux at least had GCC to start with) but I'd be
> really happy to be proved wrong. "Show us the code".
>
Absolutely. Those who say it's impossible should in no way be allowed
to stand in the way of those who are doing it ;-)
> (For my money I'd rather have a nice free lisp development environment
> atop of Linux, and replace bits of Linux infrastructure incrementally
> -- System V runlevels will be the first against the wall -- as
> the need arises. For example, you could do TCP in CL with
> SOCK_PACKET. You could probably help GC a lot by appropriate use of
> madvise() and mincore(). If the interface they give you is
> insufficient, talk to the Linux developers, and they'll probably be
> happy to extend it. Or at least, to accept patches ...)
IIRC, madvise isn't yet implemented in Linux.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
Lieven Marchand <···@bewoner.dma.be> writes:
> IIRC, madvise isn't yet implemented in Linux.
Hmm. You're correct wrt 2.2. I'm assured that it will be in 2.4,
though (the 2.3.99pre9 that I have the source tree for but am not actually
running seems to have superficially plausible code in it)
-dan
--
http://ww.telent.net/cliki/ - CLiki: CL/Unix free software link farm
Lieven Marchand <···@bewoner.dma.be> writes:
> History seems to be going against you. Linus Torvalds started Linux
> as a way to familiarize himself more with his new 386 and the first
> versions of Linux were full of x86 weirdness. 0.12 upto 0.99 and
> perhaps beyond used x86 TSS's and a lot of the other weird and ugly
> stuff. Almost all of this later turned out to be a mistake and has
> been removed from the kernel.
Perhaps, but to my knowledge the goal of linux was quite early to
become a "unix clone".
--
Frode Vatvedt Fjeld
Frode Vatvedt Fjeld <······@acm.org> writes:
> Lieven Marchand <···@bewoner.dma.be> writes:
>
> > History seems to be going against you. Linus Torvalds started Linux
> > as a way to familiarize himself more with his new 386 and the first
> > versions of Linux were full of x86 weirdness. 0.12 upto 0.99 and
> > perhaps beyond used x86 TSS's and a lot of the other weird and ugly
> > stuff. Almost all of this later turned out to be a mistake and has
> > been removed from the kernel.
>
> Perhaps, but to my knowledge the goal of linux was quite early to
> become a "unix clone".
True, but not very relevant. The low level x86 stuff turned out not to
advantageuous to implement the kernel servives layer and I bet you'd
find out the same thing for your kernel lisp.
--
Lieven Marchand <···@bewoner.dma.be>
Lambda calculus - Call us a mad club
> Frode Vatvedt Fjeld <······@acm.org> writes:
>
> > Perhaps, but to my knowledge the goal of linux was quite early to
> > become a "unix clone".
Lieven Marchand <···@bewoner.dma.be> writes:
> True, but not very relevant. The low level x86 stuff turned out not
> to advantageuous to implement the kernel servives layer and I bet
> you'd find out the same thing for your kernel lisp.
When sombody find some means not to be advantageous to their cause, I
find the nature of that cause to be extremely relevant as to wether
those means are advantageous for something else. That something isn't
good for implementing unix doesn't mean it's not good for implementing
something else. I've seen a couple of interesting OS designs based on
the x86 "weirdness".
--
Frode Vatvedt Fjeld
On 18 Aug 2000 21:47:34 +0200, Frode Vatvedt Fjeld <······@acm.org> wrote:
> Well, I've tried to look at the ongoing (?) lispos efforts, but quite
> frankly I didn't find too much there that I found very interesting.
Some time ago the archive of the latest LispOS mailing list was online, but
now it is no longer available.
> Suffice it to say I would describe myself as an OS kind of person that
> has taken a liking to (common) lisp and all its ways, so I guess I'm
> sort of doubly attracted to this lispos thing. I've recently become
I suggest that you have a look at Ralf Moeller's Symbolics museum:
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics.html
It also includes a good bibliography, and most of the publications it lists
should be available at every reasonably well stuffed computer
science/engineering department's library.
Have (de)fun,
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Frode Vatvedt Fjeld wrote:
> Well, I've tried to look at the ongoing (?) lispos efforts, but quite
> frankly I didn't find too much there that I found very interesting.
I suspect that few want to hang out their linen before it has been
washed at least, and that takes _time_. I think that even fewer would
boldly announce a purely-experimental, Lisp-on-the-metal project.
> Suffice it to say I would describe myself as an OS kind of person that
> has taken a liking to (common) lisp and all its ways, so I guess I'm
> sort of doubly attracted to this lispos thing. I've recently become
> confident enough with lisp that I feel that I have a reasonable grasp
> of the complexities involved in making a lisp system.
You have two of the most important qualifications already. The third
requirement is perseverance, I think
> My idea (to the extent I have one) would be to write both of a
> language/compiler and a kernel, both highly tuned to the PC x86
> architecture (which, by the way, I don't think will be obsolete any
> time very soon). The language/compiler would be strictly for writing
> the kernel in, and so should be considered a part of the kernel source
> code, and nothing like a competitor to CMUCL (i.e. not meant for
> applications).
That seems perfectly reasonable.
> Well, I'd say "a PC". Or make that "a PC with memory", the more the
> better, obviously. Hm.. make that a "pentium or later generation CPU
> PC with memory", as writing a compiler today I wouldn't bother with
> supporting 386s and such.
OK.
> Then of course, if you want networking, someone must write a NIC
> driver, and you either need to get that card that someone else wrote a
> driver for, or you must write a driver for your card. And so on. When
> there is at least one NIC driver, one SCSI driver etc.
Re NIC: John Morrison announced the availability of a basic development
environment, which he called "a tool-chain". It used two
network-connected PC:s, one host and one target machine, and was written
for JOS (the Java OS/VM project). John is probably at ··@mak.com
Re SCSI: I think a standard IDE disk driver should also be included (and
of course bitmap display, keyboard, mouse and floppy drivers)
> If I had any say at all, the development environment would be Common
> Lisp. Plus the new (in CL written) kernel-lisp, obviously.
> > At least there would be stated objectives, an end goal to go for,
> > with milestones in between, that the team can plan against. Have you
> > any ideas on how to deal with this in a non-personal project
> > (assuming you have one in mind)? What time-scale do you foresee?
> > Required level of expertise?
>
> I don't know about these things. Maybe the most viable option is to
> have the most basic ground-work[1] laid down by a very small group of
> people, and then let it (hopefully) grow like cancer, but as
> controlled as possible.
I think I know a bit about them (things). Especially that one tends to
underestimate the effort needed on "unnecessary" work completely.
Look at the number of might-have-been OS'es, which is already high, and
add the number of attempts at "writing my own OS", that can be found on
the net.
Very small group, yes. A lot of work, just to get a few primary goals,
and a common terminology straightened out, yes.
I'm not saying that it cannot be done, only that it's obviously
difficult to have the right kind of people to join in such an effort.
> [1] The skeleton of a language/compiler, the beginnings of a dynamic
> typing/GC subsystem, and most importantly a floppy image one can boot
> and let you do this:
>
> ? (loop (write "Hello World!"))
> ...
>
Hm. I know of at least one such skeleton. You really should plan how to
roll out your own system, along the lines you describe. (Some people in
the LispOS mailing list were confident that CMUCL/Linux was the quick
way to go, but that was 2 (?) years ago, and there are no hoorays yet to
be heard ...)
Lars
Centuries ago, Nostradamus foresaw a time when Frode Vatvedt Fjeld would say:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>
>> Anyone who ever saw the source the the Adaptec SCSI driver in Linux
>> or FreeBSD will immedeately dismiss the idea to do down-to-metal in
>> Lisp. Even Linux and FreeBSD share complicated drivers like these
>> and they have manpower no end.
>
>But then again, wouldn't some of the point of such an excercise be
>that you'd have this wonderfully powerful language for implementing
>such complex drivers? :-)
>
>I wouldn't exactly claim that an Adaptec SCSI driver in the
>hypothetical lispos would reduce to a ten-line lisp expression, but
>the fact that something has a complex solution in C doesn't imply that
>the problem is complex. And even if the problem _is_ complex, I'd bet
>the lisp solution would be a lot simpler than the C solution.
>(Especially if you had a specialized compiler and environment. But
>these are many and big ifs, I know..)
>
>And finally, a lispos that ignores badly-designed hardware (well,
>except for the PC architecture itself, I guess..) would still be of
>great value to many people, even if it doesn't necessarily run on each
>and every run-of-the-mill PC and peripheral device out there. I don't
>know much about Adaptec's SCSI hardware, but I _do_ know that some of
>the high-end PC SCSI controllers provide hardware interfaces that are
>quite simple to use (i.e. require very simple drivers).
>
>..So I don't agree that the idea is that easily dismissable.
The problem is that even if things are amenable to hardware drivers
being significantly easier to implement in Lisp, it is _still_ a
lot of work, and that's a "bunch of work" that someone needs to do
for every distinct version of each device.
That is, if the Adaptec host adaptor driver had to be modified for
each distinct BIOS version (as seems not unusual), someone does
need to do this for the Lisp versions.
Ditto for each relevant Symbios host adaptor. And each relevant
Mylex host adaptor.
The _BIG_ point is that this adds up, and you need to have enough "staff"
that you have someone competent to update the SCSI drivers regularly as
new products come out.
And that speaks only for SCSI support.
- IDE is on top of that.
- PCI motherboards are another thing.
- USB devices add to this.
- How about video support?
This can readily add up to needing a fair bunch of people that are
interested in spending their time doing gritty low level driver
development.
On what basis are you planning to assign a good half dozen people
with this task?
- Do you have the $500K/year to pay these people?
- Are you prepared to volunteer to be one of these people?
- The other option is essentially the "wishful thinking" of
wanting someone else to take up the task.
--
·····@freenet.carleton.ca - <http://www.hex.net/~cbbrowne/lisp.html>
"You think you know when you can learn, are more sure when you can
write, even more when you can teach, but certain when you can
program." -- Alan Perlis
Martin Cracauer wrote:
> I think the real reason why LispOS as such did not went anywhere is
> that Lisp and Lispers are about doing *new* things. Plainly
> reimplementing something that already exists does not attrack most
> capable Lisp hackers.
I think the problem for non-students is that it doesn't attract VCs.
Imagine that was not a problem
Question: What would you prefer?
a. Make a good living building a dream that didn't work out the first
time.
b. Take a shot at a good number in the dotcom lottery. Postpone dream
as a hobby until retired.
SPACE LISPERS??
--
Fernando D. Mato Mira Phone : +41 (78) 778 FDMM
E-mail : matomira AT acm DOT org
* Martin Cracauer
| I think the real reason why LispOS as such did not went anywhere is
| that Lisp and Lispers are about doing *new* things. Plainly
| reimplementing something that already exists does not attrack most
| capable Lisp hackers.
Well, I disagree. If you can do something right that has been done
wrong umpteen times before, you will find few programmers more
willing to seize the opportunity do it right than Lisp programmers.
I think that's why designing a LispOS has an appeal to begin with.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.net> wrote in message
·····················@naggum.net...
> * Martin Cracauer
> | I think the real reason why LispOS as such did not went anywhere is
> | that Lisp and Lispers are about doing *new* things. Plainly
> | reimplementing something that already exists does not attrack most
> | capable Lisp hackers.
>
> Well, I disagree. If you can do something right that has been done
> wrong umpteen times before, you will find few programmers more
> willing to seize the opportunity do it right than Lisp programmers.
> I think that's why designing a LispOS has an appeal to begin with.
Actually, there is another issue that I've yet seen resolved.
Essentially the issue is what are the tangible benefits of Lisp OS built on
commondity hardware from the ground up compared to a robust Lisp environment
built on top of an existing OS from the top down?
If the development environment of a Genera were to be built on top of a
current CL (like CMU or even ACL), would that fill the need presumed to be
filled by a LispOS?
Or are there significant performance enhancements that can be gained on
commodity hardware that are being held back purely because of the
architecture of the hosting OS?
This is where part of the disparity of the "Start from the top down" vs
"Start from the bottom up" camps comes from, I think.
Where do the current OS's "get in the way" of a modern CL implemented on top
of them performing at top speed?
I know there are issues with Lisp threads on top of OS threads and
processes. What about GC? What does a modern Lisp need that today's kernels
aren't providing?
With LispMs, you had both. Tangible performance increases with the aid of
custom hardware, and a robust, advanced development environment.
Anyway, I'm just interested in the gains of a new LispOS beyond the pure
hackery of it all.
Regards,
Will Hartung
(······@home.com)
In article <······················@news1.alsv1.occa.home.com>, "Will
Hartung" <······@home.com> wrote:
> Essentially the issue is what are the tangible benefits of Lisp OS built on
> commondity hardware from the ground up compared to a robust Lisp environment
> built on top of an existing OS from the top down?
Most Lisp systems don't have a really robust interface to the OS.
For example few do really check the data they hand over
to the OS when doing FFI calls. This means, that in an
interactive application you easily can give invalid/wrong
data to the OS or other processes.
> If the development environment of a Genera were to be built on top of a
> current CL (like CMU or even ACL), would that fill the need presumed to be
> filled by a LispOS?
You can run an advanced development environment on top of
a current CL - but a Lisp OS might be more difficult.
There are "drawbacks" of a mixed approach:
- there is a "debugging border". Debugging in Lisp is relatively easy
at runtime. Debugging the underlying foreign code at runtime
is harder.
- additionally to Lisp datataypes there would be a whole range
of other datatypes with the necessary infrastructure
(own memory management, own data layout for records, ->
another runtime system).
Conversion to and from these data types slows things down.
Lisp needs to be aware of these datatypes when doing
high-performance stuff (direct access to disk or network
buffers, ...). Lisp datastructures need to keep
track of the underlying datastructures and their memory
management - you have another level of indirection.
You can not use structures or CLOS classes for low-level
datastructures.
On the other hand the advantages of a mixed approach have
been mentioned already.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
>* Martin Cracauer
>| I think the real reason why LispOS as such did not went anywhere is
>| that Lisp and Lispers are about doing *new* things. Plainly
>| reimplementing something that already exists does not attrack most
>| capable Lisp hackers.
>
> Well, I disagree. If you can do something right that has been done
> wrong umpteen times before, you will find few programmers more
> willing to seize the opportunity do it right than Lisp programmers.
> I think that's why designing a LispOS has an appeal to begin with.
The problem is that the appeal has been quite "academic," unfortunately
in the perjorative sense of the term.
People are interested in the _idea_ of it, but it is not evident that
the interest is in the "gritty" reality of the building of it. There
is lots of interest in armchair design work, but actual implementation
is Somebody Else's Problem.
One scenario I'd see as _vaguely_ plausible for implementation would
involve someone like Jamie Zawinski. I expect he's somewhat flush with
cash as a result of his involvement with Netscape, and has a long history
of interest in Common Lisp. It would be a plausible thing for him to
sponsor building a LispOS; hiring a group of half a dozen developers for
a couple of years would _not_ be out of reach.
Is that realistically enough people to build something Genera-like?
Dunno. The point is that that's one of the faintly plausible scenarios,
namely the "Angel investor who could want this to happen and invest on
that basis" scenario.
The "Vulture Capitalists Willing to Put $20M In On The Basis of Later
Sales" seems unrealistic; I don't see the likelihood of there being
$50M in sales thereafter to make for hefty profitability.
The "Academics Build Some Cool Code And Make Good" apparently worked for
Paul Graham's group in providing a catalog system for Yahoo!, but the
only group I see working on something resembling a LispOS is the Rice
University group that built MzScheme atop FluxOS. And unfortunately a
main "boast" to that is that it only took a few hours to do the port.
I don't see them working to turn this into 'Genera ][.'
The other possibility is "Some guys work on the weekends and recreate
Genera" atop Ocelot/NASOS/SilkOS/FunOS/Vapour. About all that I can
say in favor of this is that it may keep the _idea_ alive... It seems
about as likely as Tunes turning into something useful any time soon...
--
·····@freenet.carleton.ca - <http://www.ntlug.org/~cbbrowne/lisposes.html>
Rules of the Evil Overlord #95. "My dungeon will have its own
qualified medical staff complete with bodyguards. That way if a
prisoner becomes sick and his cellmate tells the guard it's an
emergency, the guard will fetch a trauma team instead of opening up
the cell for a look." <http://www.eviloverlord.com/>
CB> [...] I expect he's
CB> somewhat flush with cash as a result of his involvement with
CB> Netscape, and has a long history of interest in Common Lisp.
CB> It would be a plausible thing for him to sponsor building a
CB> LispOS; hiring a group of half a dozen developers for a couple
CB> of years would _not_ be out of reach. [...]
In that case, buying the rights to Sybolics' Open Genera and opening
it up might also be feasible. Someone with reach might even persuade
Compaq and/or Alpha vendors to sponsor a port to Linux/Alpha.
BM
Centuries ago, Nostradamus foresaw a time when Bulent Murtezaoglu would say:
> CB> [...] I expect he's
> CB> somewhat flush with cash as a result of his involvement with
> CB> Netscape, and has a long history of interest in Common Lisp.
> CB> It would be a plausible thing for him to sponsor building a
> CB> LispOS; hiring a group of half a dozen developers for a couple
> CB> of years would _not_ be out of reach. [...]
>
>In that case, buying the rights to Sybolics' Open Genera and opening
>it up might also be feasible. Someone with reach might even persuade
>Compaq and/or Alpha vendors to sponsor a port to Linux/Alpha.
Both good thoughts. The "port to Linux/Alpha" being a pretty good
idea, regardless of any changes in "business strategy."
--
(concatenate 'string "cbbrowne" ·@" "ntlug.org")
<http://www.ntlug.org/~cbbrowne/alpha.html>
``Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of our
most gifted fellow humans in thinking previously impossible thoughts.''
-- "The Humble Programmer", E. Dijkstra, CACM, vol. 15, n. 10, 1972
"Christopher Browne" <········@knuth.brownes.org> escribi� en el mensaje
····························@knuth.brownes.org...
> Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
> >* Martin Cracauer
> Is that realistically enough people to build something Genera-like?
Why not porting Genera to intel? O:-)
------------------------------------
Fernando Rodriguez
Fernando wrote:
>
> Why not porting Genera to intel? O:-)
Well, first off, it pretty much requires a 64-bit machine. A port to a 32-bit
machine might be possible, but it would be a lot of extra work, and you'd be
left with a limited amount of address space. Genera is worse in this regard
than the familiar 32-bit Common Lisp implementations because it requires more
type bits on each word to implement things like invisible pointers; thus the
number of bits available for address is reduced. This is why Symbolics very
early went from 32-bit machines to 36, and later to 40. Since building a custom
40- or 48-bit machine is not an option here, one pretty much has to go to 64.
Secondly, the Alpha architecture is nearly ideal for running the Open Genera
virtual machine. Performance is likely to suffer on another architecture.
That said, a port to the new AMD x86-64 architecture might be worthwhile. My
guess is that the Intel iTanium is not interesting because (1) I'm not sure the
chip will be successful in the first place and (2) I'm not sure how well suited
the architecture is for running the Open Genera VM.
There's also the UltraSPARC.
-- Scott
In article <·················@my-dejanews.com>, "Scott L. Burson"
<·······@my-dejanews.com> wrote:
> Fernando wrote:
> >
> > Why not porting Genera to intel? O:-)
>
> Well, first off, it pretty much requires a 64-bit machine. A port to a 32-bit
> machine might be possible, but it would be a lot of extra work, and you'd be
> left with a limited amount of address space. Genera is worse in this regard
> than the familiar 32-bit Common Lisp implementations because it requires more
> type bits on each word to implement things like invisible pointers; thus the
> number of bits available for address is reduced. This is why Symbolics very
> early went from 32-bit machines to 36, and later to 40. Since building a custom
> 40- or 48-bit machine is not an option here,
FPGAs might be an answer.
> one pretty much has to go to 64.
How about emulating a 40 (or 36) Bit architecture with a 32 Bit CPU?
> Secondly, the Alpha architecture is nearly ideal for running the Open Genera
> virtual machine. Performance is likely to suffer on another architecture.
Sure, but with 1 Ghz or even 2 Ghz processors from Intel and AMD
I would not see a problem here.
> That said, a port to the new AMD x86-64 architecture might be worthwhile. My
> guess is that the Intel iTanium is not interesting because (1) I'm not sure the
> chip will be successful in the first place
Some people call it "tiTanium". ;-)
> There's also the UltraSPARC.
And IBM's POWER architecture.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig wrote:
>
> How about emulating a 40 (or 36) Bit architecture with a 32 Bit CPU?
How are you going to do that with reasonable efficiency? You could load
tags separately, referencing another page, but that sounds to me like it will
make everything run 1/2 as fast.
dave
In article <·················@ncgr.org>, David Hanley <···@ncgr.org>
wrote:
> Rainer Joswig wrote:
>
> >
> > How about emulating a 40 (or 36) Bit architecture with a 32 Bit CPU?
>
> How are you going to do that with reasonable efficiency? You could load
> tags separately, referencing another page, but that sounds to me like it will
> make everything run 1/2 as fast.
Sure, 1/2 fast is still faster than not at all.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig wrote:
> In article <·················@ncgr.org>, David Hanley <···@ncgr.org>
> wrote:
>
> > Rainer Joswig wrote:
> >
> > >
> > > How about emulating a 40 (or 36) Bit architecture with a 32 Bit CPU?
> >
> > How are you going to do that with reasonable efficiency? You could load
> > tags separately, referencing another page, but that sounds to me like it will
> > make everything run 1/2 as fast.
>
> Sure, 1/2 fast is still faster than not at all.
Why not just use one of the many 64-bit CPU's in existence, or
coming really soon? And I think 1/2 may even be optimistic.
dave
David Hanley <···@ncgr.org> writes:
> tags separately, referencing another page, but that sounds to me
> like it will make everything run 1/2 as fast.
Well, it would still be several times faster than java, so why not?
--
(espen)
Espen Vestre wrote:
> David Hanley <···@ncgr.org> writes:
>
> > tags separately, referencing another page, but that sounds to me
> > like it will make everything run 1/2 as fast.
>
> Well, it would still be several times faster than java, so why not?
OOh. Several times better, maybe. Several times faster, i severely
doubt.
dave
Centuries ago, Nostradamus foresaw a time when Rainer Joswig would say:
>In article <·················@my-dejanews.com>, "Scott L. Burson"
><·······@my-dejanews.com> wrote:
>> Fernando wrote:
>> > Why not porting Genera to intel? O:-)
>>
>> Well, first off, it pretty much requires a 64-bit machine. A port to a 32-bit
>> machine might be possible, but it would be a lot of extra work, and you'd be
>> left with a limited amount of address space. Genera is worse in this regard
>> than the familiar 32-bit Common Lisp implementations because it requires more
>> type bits on each word to implement things like invisible pointers; thus the
>> number of bits available for address is reduced. This is why Symbolics very
>> early went from 32-bit machines to 36, and later to 40. Since
>> building a custom 40- or 48-bit machine is not an option here,
>
>FPGAs might be an answer.
>
>> one pretty much has to go to 64.
>
>How about emulating a 40 (or 36) Bit architecture with a 32 Bit CPU?
With the availability of 64 bit SPARC, MIPS, Alpha, and PPC CPUs, and
the impending availability of IA-64, and possibly even "x86-64," I
don't see very much value in trying to catch the tail end of the 32
bit era just as it is starting to end.
Consider that there's not _all_ that much savings available by doing
this. There are new Alpha machines priced at around $3000 USD; that's
only around half the price of Open Genera. The "savings" that come
from hacking this to run on IA-32 might be around $1000 USD, which is
only about 1/8th the cost of such a system.
(let* ((alphaprice 3000)
(ia32price 2000)
(generaprice 5000)
(ia32syscost (+ ia32price generaprice))
(alphasyscost (+ alphaprice generaprice))
(rawsavings (- alphasyscost ia32syscost)))
(defvar savingsratio (/ rawsavings alphasyscost)))
(format t "Savings: ~A~%" savingsratio)
Savings: 1/8
I think it begs the question just how important this kind of savings
really is. If Open Genera is regarded as "too expensive" due to
running only on Alpha, I would think that moving to IA-32 Won't Help
Enough.
>> Secondly, the Alpha architecture is nearly ideal for running the Open Genera
>> virtual machine. Performance is likely to suffer on another architecture.
>
>Sure, but with 1 Ghz or even 2 Ghz processors from Intel and AMD
>I would not see a problem here.
Sure, and with 500MHz SPARC or PPC or IA-64 or x86-64 processors,
there would be no need to make 32 bit compromises.
>> That said, a port to the new AMD x86-64 architecture might be worthwhile. My
>> guess is that the Intel iTanium is not interesting because (1) I'm not sure the
>> chip will be successful in the first place
>
>Some people call it "tiTanium". ;-)
Which offers rich opportunities when someone asks how the server's
doing to say,
"iT's up!"
[And if you go with the "tiTanium" naming scheme, that transforms to
something that means exactly the opposite to what is usually
expected... :-)]
>> There's also the UltraSPARC.
>
>And IBM's POWER architecture.
And MIPS.
I don't see any real benefit to an IA-32 port; with the degree to
which the benefits disappear against the ~$8000 USD that a system
running Open Genera will cost, it just doesn't seem like a
_worthwhile_ benefit.
Anybody that is so price-sensitive that they would find the $1K of
savings to be vastly worthwhile would find the $5K that Open Genera
costs to be so outrageously excessive that the $1K wouldn't _help_.
--
(concatenate 'string "cbbrowne" ·@" "acm.org")
<http://www.hex.net/~cbbrowne/alpha.html>
Rules of the Evil Overlord #55. "The deformed mutants and odd-ball
psychotics will have their place in my Legions of Terror. However
before I send them out on important covert missions that require tact
and subtlety, I will first see if there is anyone else equally
qualified who would attract less attention."
<http://www.eviloverlord.com/>
In article <························@news4.giganews.com>,
········@hex.net wrote:
> >How about emulating a 40 (or 36) Bit architecture with a 32 Bit CPU?
>
> With the availability of 64 bit SPARC, MIPS, Alpha, and PPC CPUs, and
> the impending availability of IA-64, and possibly even "x86-64," I
> don't see very much value in trying to catch the tail end of the 32
> bit era just as it is starting to end.
- speed is improving rapidly
- the hardware is available just everywhere
- systems coming in different shapes: from laptops to servers
etc.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
On Tue, 15 Aug 2000 18:43:25 GMT, "Fernando" <···@mindless.com> wrote:
> Why not porting Genera to intel? O:-)
This paper deals with the difficulties of porting Genera:
The Symbolics Virtual Lisp Machine
http://pt.withington.org/VLM.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Erik Naggum <····@naggum.net> writes:
>* Martin Cracauer
>| I think the real reason why LispOS as such did not went anywhere is
>| that Lisp and Lispers are about doing *new* things. Plainly
>| reimplementing something that already exists does not attrack most
>| capable Lisp hackers.
> Well, I disagree.
No :-), since...
> If you can do something right that has been done
> wrong umpteen times before, you will find few programmers more
> willing to seize the opportunity do it right than Lisp programmers.
> I think that's why designing a LispOS has an appeal to begin with.
... I didn't say anything against this claim. The problem here is
that has been done quite right before. From the standpoint of the Lisp
programming, not the choice of hardware, business model or such. And
correcting these non-Lisp mistakes is what Lisper's are not about,
IMHO.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Russell Wallace <········@esatclear.ie> writes:
> Erik Naggum wrote:
> >
> > * "Tobias Andersson" <················@optosweden.se>
> > | Whatever happened to LISPOS?
> >
> > I don't know what happened to LISPOS, but the discussions turned
> > from useful talk about how to perform this daunting task to deeply
> > involved and completely irrelevant minutiae.
>
> Armchair thought, for what it's worth: [...]
The main problem I could see with the LispOS discussions (and in fact
various internet "Foo-OS Lists" in general) are that the typical posts
were written by someone exemplified by the following:
"My name is Joe List Subscriber. If I ever studied CS at a
university or even got a degree, then I might have managed to pass
the required courses in computer architecture, compiler
implementation, and operating systems, but I'm certainly no expert
at any of these things. I've written several (possibly trivial)
applications in Lisp (or Scheme) and thought it was kinda cool, so
now I think a Lisp OS is kewl. I read something on Slashdot once
about something called the Flux OSKit and that it was good for
rolling yer own OS, so it follows that it must be good for rolling
yer own Lisp OS, so I thought I'd post this brilliant flash of
insight to the Lisp OS discussion list. While I'm at it, I think I
should mention my idea of making a Lisp OS by adding a Lisp server
to the GNU Hurd. I have no sort of detailed technical understanding
of any part of the Hurd whatsoever, but I have this sort of
intuitive view of the Hurd architecture that is not inconsistent
with the idea of implementing a Lisp OS as Hurd server processes, so
I also thought I'd share this wonderful idea. I think we should also
discuss the pros and cons of a Lisp OS vs. a Scheme OS. I don't
really have the time or the expertise to code anything for the Lisp
OS project, but I'm happy architect the project. Blah blah...."
I claim that for any Lisp OS effort in general to succeed it is
necessary (though not sufficient) for there to exist individuals that
(i) have the proper highly specialized education and expertise AND
(ii) are brilliant AND
(iii) are motivated and willing to commit the man-years necessary.
To get the project off to a decent start, I claim there must exist at
least one individual satisfying (i)-(iii). [A la Linux.]
NOT HAPPENING.
On the bright side, it seems there has been some traffic recently on
the free-clim discussion list and some real work getting done.
Also, anyone can download a trial edition of Allegro CL (or LispWorks)
and install its Emacs Lisp Interface and have an outstanding Lisp
environment right this very day, if they'd only put in the months to
read the documentation and learn to use it proficiently, which they'd
have to do with a real Lisp OS anyways. [Of course, nothing yet is
really comparable to how fast and fun you can learn to do things on a
Symbolics. I don't see this as an argument supporting a Lisp OS per
se, but rather as an argument supporting a Lisp environment exploiting
the relevant concepts of the Genera user interface.]
Christopher
"Christopher R. Barry" wrote:
> I claim that for any Lisp OS effort in general to succeed it is
> necessary (though not sufficient) for there to exist individuals that
>
> (i) have the proper highly specialized education and expertise AND
> (ii) are brilliant AND
> (iii) are motivated and willing to commit the man-years necessary.
>
> To get the project off to a decent start, I claim there must exist at
> least one individual satisfying (i)-(iii). [A la Linux.]
and (iv) spending his days at a university
--
Fernando D. Mato Mira Phone : +41 (78) 778 FDMM
E-mail : matomira AT acm DOT org
>>>>> "Christopher" == Christopher R Barry <······@2xtreme.net> writes:
Christopher> The main problem I could see with the LispOS discussions
Christopher> (and in fact various internet "Foo-OS Lists" in general)
Christopher> are that the typical posts were written by someone
Christopher> exemplified by the following:
Christopher> "My name is Joe List Subscriber. If I ever studied CS
Christopher> at a university or even got a degree, then I might have
Christopher> managed to pass the required courses in computer
Christopher> architecture, compiler implementation, and operating
Christopher> systems, ...
I think this is somewhat unfair. I do not know about other OS lists,
but in my recollection there was very little of that on the lispOS
list.
One of the serious problems in the discussions as I recall it, was a
clash between to rather different view on what would be good to
chase. One camp wanted to start out atop some existing OS (such as
linux) in order to get going quickly, while the other camp wanted to
do the entire OS from the bottom up in order to avoid the mistakes
made in UNIX and others.
The discussions, fueled by an incredible amount of enthutiasm,
eventually spawned into too many directions to keep any real focus,
with the result that the activity slowly died out with everybody
waiting for the Flux Toolkit to come out.
My own conclusion is that it is extremely difficult to get something
(at least something as complicated as an OS) started on the idea
itself. What you need is code. This allows you to establish project
management and proper design activities and some sort of arbitration
in conflicts.
This is also how Linus Torvalds did it. He did not call together a
community, he started hacking it himself and only then did he attract
people. The same could be said for the GNU project. There need to be
something holding the project focused.
---------------------------+--------------------------------------------------
Christian Lynbech | Ericsson Telebit, Fabrikvej 11, DK-8260 Viby J
Fax: +45 8675 6881 | email: ···@ericssontelebit.com
Phone: +45 8675 6828 | web: www.ericssontelebit.com
---------------------------+--------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
Tobias Andersson wrote:
>
> Hello, All
>
> Whatever happened to LISPOS?
Count 10 years taking a backseat to Linux + 10 years development and
you're right in the window of opportunity for NeXT Paradigm Shift [WOW!
I wrote *NeXT*! ], 10 years after Haskell-derived Stuff from Redmond
[Funny, I wanted to write "Clean Stuff", but then it gets confusing ;)]
--
Fernando D. Mato Mira Phone : +41 (78) 778 FDMM
E-mail : matomira AT acm DOT org
"Fernando D. Mato Mira" wrote:
>
> Tobias Andersson wrote:
> > Whatever happened to LISPOS?
>
> Count 10 years taking a backseat to Linux + 10 years development and
> you're right in the window of opportunity for NeXT Paradigm Shift [WOW!
> I wrote *NeXT*! ], 10 years after Haskell-derived Stuff from Redmond
It's critical to get real work done towards purely functional
programming
support. This would be an ideal mission for Xah, because he's not
interested
in spending any more time with legacy libraries or implementing
applications with what's there today. [At least we've got the syntax
Right.]
--
Fernando D. Mato Mira Phone : +41 (78) 778 FDMM
E-mail : matomira AT acm DOT org
Centuries ago, Nostradamus foresaw a time when Fernando D. Mato Mira
would say:
>Tobias Andersson wrote:
>> Whatever happened to LISPOS?
>
>Count 10 years taking a backseat to Linux + 10 years development and
>you're right in the window of opportunity for NeXT Paradigm Shift [WOW!
>I wrote *NeXT*! ], 10 years after Haskell-derived Stuff from Redmond
>[Funny, I wanted to write "Clean Stuff", but then it gets confusing ;)]
The problem is that to have a _proper_ LispOS, you need a bunch of
components:
--> A kernel
--> Physical device drivers
--> Logical device drivers for such things as graphics, networking,
data storage, ...
--> A compiler that can generate that kernel
--> Some form of "user space shell"
--> A higher level graphical infrastructure
--> Some quantity of applications. Text editors, email client, web
client, and such.
The fact that there are so many components involved means that it's
pretty easy to get side-tracked on details. And it's not too likely
that one individual can be involved with all these pieces.
The "second best" option looks to be to use one of the Unix-like
systems to provide kernel, device access, and a chunk of the graphical
infrastructure, and basically concentrate on having "Lisp stuff" sit
in "user space."
An _interesting_ third option would be to take Linux or FreeBSD, thus
having hardware and filesystem support, and then basically put in a
Lisp-oriented shell to replace the traditional Unix "init." That
would mean that everything above the kernel would be "Lisp stuff."
--
(concatenate 'string "cbbrowne" ·@" "hex.net")
<http://www.ntlug.org/~cbbrowne/>
Babbage's Rule: "No man's cipher is worth looking at unless the
inventor has himself solved a very difficult cipher" (The Codebreakers
by Kahn, 2nd ed, pg 765)
Speaking of Lisp OSes: why not get the real thing? Maybe few noticed, but
the Symbolics Technology, Inc. home page:
http://www.symbolics.com/
solicits suggestions for possible ports of Genera to other platforms. It
may be worth letting them know one own's ideas, and maybe contributing some
money or resources to the project.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <····························@4ax.com>,
Paolo Amoroso <·······@mclink.it> writes:
> Speaking of Lisp OSes: why not get the real thing? Maybe few noticed, but
> the Symbolics Technology, Inc. home page:
>
> http://www.symbolics.com/
>
> solicits suggestions for possible ports of Genera to other platforms. It
> may be worth letting them know one own's ideas, and maybe contributing some
> money or resources to the project.
>
>
> Paolo
Suggestions have been made to Symbolics many times over the last ten years
or so. They seem intent on pursuing the closed source model all the way into
oblivion.
Waiting for Genera 8.5, RSN!
Mike McDonald
·······@mikemac.com
In article <···················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> Suggestions have been made to Symbolics many times over the last ten years
> or so. They seem intent on pursuing the closed source model all the way into
> oblivion.
>
> Waiting for Genera 8.5, RSN!
Isn't Genera 8.5 part of Open Genera 2.0 - which
is already available?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···················@typhoon.aracnet.com>,
> ·······@mikemac.com wrote:
>
>> Suggestions have been made to Symbolics many times over the last ten years
>> or so. They seem intent on pursuing the closed source model all the way into
>> oblivion.
>>
>> Waiting for Genera 8.5, RSN!
>
> Isn't Genera 8.5 part of Open Genera 2.0 - which
> is already available?
>
No. Open Genera 2.0 is the DEC Alpha port. Genera 8.5 would be for Ivorys
and 36XXs. I've been waiting for four years for Genera 8.5 for my XL1201.
Mike McDonald
·······@mikemac.com
In article <···················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> In article <····························@news.is-europe.net>,
> Rainer Joswig <······@corporate-world.lisp.de> writes:
> > In article <···················@typhoon.aracnet.com>,
> > ·······@mikemac.com wrote:
> >
> >> Suggestions have been made to Symbolics many times over the last ten years
> >> or so. They seem intent on pursuing the closed source model all the way into
> >> oblivion.
> >>
> >> Waiting for Genera 8.5, RSN!
> >
> > Isn't Genera 8.5 part of Open Genera 2.0 - which
> > is already available?
> >
>
> No. Open Genera 2.0 is the DEC Alpha port. Genera 8.5 would be for Ivorys
> and 36XXs.
See this screen: http://stony-brook.scrc.symbolics.com/www/og2r.gif
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···················@typhoon.aracnet.com>,
> ·······@mikemac.com wrote:
>
>> In article <····························@news.is-europe.net>,
>> Rainer Joswig <······@corporate-world.lisp.de> writes:
>> > In article <···················@typhoon.aracnet.com>,
>> > ·······@mikemac.com wrote:
>> >
>> >> Suggestions have been made to Symbolics many times over the last ten years
>> >> or so. They seem intent on pursuing the closed source model all the way into
>> >> oblivion.
>> >>
>> >> Waiting for Genera 8.5, RSN!
>> >
>> > Isn't Genera 8.5 part of Open Genera 2.0 - which
>> > is already available?
>> >
>>
>> No. Open Genera 2.0 is the DEC Alpha port. Genera 8.5 would be for Ivorys
>> and 36XXs.
>
> See this screen: http://stony-brook.scrc.symbolics.com/www/og2r.gif
>
Yah, what of it? (It clearly says "DEC OSF/1" right in the middle.) There's
also http://stony-brook.scrc.symbolics.com/www/8-5-screen-image.gif which
shows a Genera 8.5 screenshot. It's been on the Symbolics site for most of
those four years. Doesn't mean I can get a copy though.
Mike McDonald
·······@mikemac.com