From: Svein Ove Aas
Subject: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca52qj$as0$1@services.kq.no>
This autumn I'll be taking a course in my university that, among other
things, involves writing a simple OS from scratch.
The usual plan seems to be to write it in C, but I haven't been able to
find any restrictions other than "it must work". Obviously, you need a
lot more groundwork to run Lisp code than you do to run C code, but is it
feasible to write a simple Lisp (interpreter?) in C and use that?
I won't have time to reimplement all of Common Lisp, but some useful
subset should be possible.
It doesn't need to be self-hosting, but it isn't prohibited either, so I
was thinking - maybe a C bootstrapper that takes care of the lowest-level
details including a Lisp VM, and a self-hosting compiler on top of that.
Ideally, the drivers - network, console, etc. - should be written in Lisp
as well. Would this be fast enough? (How fast *is* CLISP anyway? Would a
tenth of that do?) I'm not sure about the GC, but that's a detail.
Having a decent REPL would help with debugging, but is it at all possible
to complete something like this in one semester, or am I smoking crack?
I won't have much of anything else to do, so let's say ~3 months to be on
the safe side.
From: Joe Marshall
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <3c55ye0e.fsf@ccs.neu.edu>
Svein Ove Aas <··············@brage.info> writes:
> This autumn I'll be taking a course in my university that, among other
> things, involves writing a simple OS from scratch.
>
> The usual plan seems to be to write it in C, but I haven't been able to
> find any restrictions other than "it must work". Obviously, you need a
> lot more groundwork to run Lisp code than you do to run C code, but is it
> feasible to write a simple Lisp (interpreter?) in C and use that?
Possibly.
> Ideally, the drivers - network, console, etc. - should be written in Lisp
> as well. Would this be fast enough? (How fast *is* CLISP anyway? Would a
> tenth of that do?)
It should be possible. These days, peripherals are glacially slow
compared to the processor.
> I'm not sure about the GC, but that's a detail.
You may wish to reconsider this statement.
> Having a decent REPL would help with debugging, but is it at all possible
> to complete something like this in one semester, or am I smoking crack?
> I won't have much of anything else to do, so let's say ~3 months to be on
> the safe side.
You will need to be smoking crack by the end of the semester. I
suggest amphetamines as well. It's a lot of work. You will really
need to discuss this with your professor. Your end result will be
*nothing* like the half-assed unix clones that everyone else will be
writing, so this may or may not be satisfactory for the course. If
your prof agrees with the plan, though, I expect that you'd easily
learn as much.
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca5b0h$gnh$1@services.kq.no>
Joe Marshall wrote:
> Svein Ove Aas <··············@brage.info> writes:
>> Ideally, the drivers - network, console, etc. - should be written in
>> Lisp as well. Would this be fast enough? (How fast *is* CLISP anyway?
>> Would a tenth of that do?)
>
> It should be possible. These days, peripherals are glacially slow
> compared to the processor.
>
>> I'm not sure about the GC, but that's a detail.
>
> You may wish to reconsider this statement.
>
By "detail", I meant "implementation detail". Not "simple", more like
"unknowable at the moment".
>> Having a decent REPL would help with debugging, but is it at all
>> possible to complete something like this in one semester, or am I
>> smoking crack? I won't have much of anything else to do, so let's say
>> ~3 months to be on the safe side.
>
> You will need to be smoking crack by the end of the semester. I
> suggest amphetamines as well. It's a lot of work. You will really
> need to discuss this with your professor. Your end result will be
> *nothing* like the half-assed unix clones that everyone else will be
> writing, so this may or may not be satisfactory for the course. If
> your prof agrees with the plan, though, I expect that you'd easily
> learn as much.
>
We'll see.
If a VM for CLISP is allowable, along with CLISP, then that takes care of
most of it and I'll get a high-level language almost for free. (Well, in
comparison...)
I might end up doing something totally different; I just don't want to
write another half-assed unix clone, as you so perceptively noted.
The neat thing about Lisp is that it's a great language to build other
languages on. You want to write a very simple OS in Lisp, so why not
make a Lisp that is the perfect language for writing very simple OS's
in? I wrote a Lisp-subset interpreter during finals week instead of
studying one time, and I've since expanded it greatly and it is a
language for controlling space ships in a simulation I'm writing (in C).
My recommendation is to create your own dialect of Lisp and write an
interpreter for it. But write the interpreter first, and then add
operators as you go; it worked for me and I was running Towers of Hanoi
on it in less than 5 days.
For a simple OS of the type you're going to write in an OS course, the
speed of interpreted Lisp will be more than enough. You may want to
perform tail recursion elimination, but other than that you should be
able to get by just fine, and you'll be the first one done with any
enhancements that are assigned through the course of the course (of
course, of course? ;-D).
How I started was by reading the notes on how data types are implemented
in GNU Guile. I follow a very similar pattern, and it saved me lots of
time figuring out how to do it without any inspiration.
If you want to see my code, feel free to e-mail me. I don't like
spreading it around too much, mostly out of modesty, but it works and
would be pretty easy to embed (the main thing is that you'd have to
change how it allocates memory; but how I do it would be very easy to
change; or you could just implement malloc() and free() at the kernel
level and let it use those).
Ari
Ari Johnson wrote:
Of course, my offer of sharing code is made under the stipulation that I
get to see your project as it progresses from first boot through
post-grading enhancements (if you're using Lisp in an OS project in
college, you're most likely like me and add features after you hand it
in, purely for posterity).
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca6c3d$h4n$1@services.kq.no>
Ari Johnson wrote:
> Ari Johnson wrote:
>
> Of course, my offer of sharing code is made under the stipulation that I
> get to see your project as it progresses from first boot through
> post-grading enhancements (if you're using Lisp in an OS project in
> college, you're most likely like me and add features after you hand it
> in, purely for posterity).
>
If I *do* use Lisp in an OS project, I'm going to put the result on my
website *after the exams*.
I won't use your code, though; as I've been repeating all day, I'm not
allowed to - using Lisp at all is a stretch.
Svein Ove Aas wrote:
> Ari Johnson wrote:
>
>
>>Ari Johnson wrote:
>>
>>Of course, my offer of sharing code is made under the stipulation that I
>>get to see your project as it progresses from first boot through
>>post-grading enhancements (if you're using Lisp in an OS project in
>>college, you're most likely like me and add features after you hand it
>>in, purely for posterity).
>>
>
> If I *do* use Lisp in an OS project, I'm going to put the result on my
> website *after the exams*.
>
> I won't use your code, though; as I've been repeating all day, I'm not
> allowed to - using Lisp at all is a stretch.
I'm hardly suggesting you use my code. Trust me, it's a language for
spaceship automation, not OS development. However, it may prove
inspirational in some small way, seeing how easy it is to write your own
Lisp interpreter that you as an individual can fully understand and
rapidly extend into the perfect language for your application. Let me
know if you want it. It's about 3500 lines of C, including a really
good 22-line comment describing how I deal with data types.
If not, my feelings won't be hurt. I'm just trying to facilitate in any
way I can your use of Lisp in this project. :)
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca6d48$lhg$1@services.kq.no>
Ari Johnson wrote:
> Svein Ove Aas wrote:
>> Ari Johnson wrote:
>>
>>
>>>Ari Johnson wrote:
>>>
>>>Of course, my offer of sharing code is made under the stipulation that
>>>I get to see your project as it progresses from first boot through
>>>post-grading enhancements (if you're using Lisp in an OS project in
>>>college, you're most likely like me and add features after you hand it
>>>in, purely for posterity).
>>>
>>
>> If I *do* use Lisp in an OS project, I'm going to put the result on my
>> website *after the exams*.
>>
>> I won't use your code, though; as I've been repeating all day, I'm not
>> allowed to - using Lisp at all is a stretch.
>
> I'm hardly suggesting you use my code. Trust me, it's a language for
> spaceship automation, not OS development. However, it may prove
> inspirational in some small way, seeing how easy it is to write your own
> Lisp interpreter that you as an individual can fully understand and
> rapidly extend into the perfect language for your application. Let me
> know if you want it. It's about 3500 lines of C, including a really
> good 22-line comment describing how I deal with data types.
>
> If not, my feelings won't be hurt. I'm just trying to facilitate in any
> way I can your use of Lisp in this project. :)
Well, all right.
You're welcome to send a copy, although I'm going to warn you - I'm not
sure I'll be allowed to share my progress.
You'll get my notes (and source) once I've turned it in, sure.
Am Tue, 08 Jun 2004 22:10:12 +0200 schrieb Svein Ove Aas:
Have you looked at Movitz? From http://www.common-lisp.net/project/movitz/ :
>
The Movitz system aspires to be an implementation of ANSI Common Lisp that
targets the ubiquitous x86 PC architecture "on the metal". That is,
running without any operating system or other form of software
environment. Movitz is a development platform for operating system
kernels, embedded, and single-purpose applications. There can potentially
be several completely different operating systems built using Movitz.
<
Simon
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca54n2$k78$1@services.kq.no>
Simon Adameit wrote:
> Am Tue, 08 Jun 2004 22:10:12 +0200 schrieb Svein Ove Aas:
>
> Have you looked at Movitz? From
> http://www.common-lisp.net/project/movitz/ :
>
Yes, I've looked; in fact, one of my teachers is the guy *writing* it.
it doesn't fit the bit at all, though. For one thing, I'm supposed to
start from scratch; Movitz already includes everything that I'd write and
then some.
For another, it's taken him four years so far. I don't have that much
time, which is why I suggested I'd be doing something a lot simpler. I
don't need all of Common Lisp when the primary goal is to write something
friendlier than C.
Hopefully what I'd write would be a proper subset so I could complete it
at need, but that's not really an issue either.
Simon Adameit wrote:
>> Have you looked at Movitz? From
>> http://www.common-lisp.net/project/movitz/ :
Svein Ove Aas <··············@brage.info> writes:
> it doesn't fit the bit at all, though. For one thing, I'm supposed
> to start from scratch; Movitz already includes everything that I'd
> write and then some.
This isn't entirely accurate. One aspect of Movitz is to be an
absolutely minimal run-time environment for Common Lisp, in much the
same way that e.g. GCC provides a minimal run-time environment for
C. (Of course, C being what it is, the C version is going to be a lot
smaller.) So in this sense, GCC also includes everything you'd write
in an OS course the form of Linux or NetBSD or what have you.
Also, it is actually not true that Movitz includes everything you'd
do in an OS course. In Movitz there are no processes, no address-space
protection, paging, no nothing, really. Again, much like GCC out of
the box.
I seem to remember that one of the early exercies in the OS course is
to implement printf. You could easily implement your own format in
Movitz, if you wanted.
> For another, it's taken him four years so far. I don't have that
> much time, which is why I suggested I'd be doing something a lot
> simpler. I don't need all of Common Lisp when the primary goal is to
> write something friendlier than C.
>
> Hopefully what I'd write would be a proper subset so I could
> complete it at need, but that's not really an issue either.
You should compare my work to that of implementing GCC, libc,
etc. Don't confuse the compiler and run-time with the OS as such.
Then again, you should remember that the OS course is most likely an
course in how C-based OS'es work. There are many similarities with
some Lispish OS, but also differences.
--
Frode Vatvedt Fjeld
Svein Ove Aas wrote:
> This autumn I'll be taking a course in my university that, among other
> things, involves writing a simple OS from scratch.
>
> The usual plan seems to be to write it in C, but I haven't been able to
> find any restrictions other than "it must work". Obviously, you need a
> lot more groundwork to run Lisp code than you do to run C code, but is it
> feasible to write a simple Lisp (interpreter?) in C and use that?
>
> I won't have time to reimplement all of Common Lisp, but some useful
> subset should be possible.
I have heard that lots of Scheme implementations get written as course
tasks, so you might get some more useful information at
comp.lang.scheme. If you don't want to implement the whole of Common
Lisp but don't want to switch to Scheme either, ISLISP provides a pretty
useful subset of CL. Restrict it further by removing classes and generic
functions, and you have a pretty core Lisp IIRC.
Another option would be to write an interpreter for some bytecode
format. For example, I think that CLISP has a well-documented bytecode.
This gives you more options in the long run to actually improve
performance by compiling the bytecode. Other CL implementations use
bytecodes as well.
Just brainstorming...
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca55vs$qgu$1@services.kq.no>
Pascal Costanza wrote:
> I have heard that lots of Scheme implementations get written as course
> tasks, so you might get some more useful information at
> comp.lang.scheme. If you don't want to implement the whole of Common
> Lisp but don't want to switch to Scheme either, ISLISP provides a pretty
> useful subset of CL. Restrict it further by removing classes and generic
> functions, and you have a pretty core Lisp IIRC.
>
I'll take a look; thanks.
I'm *not* switching to Scheme; I /like/ multi-paradigm languages, which
Scheme is not. Well, not to the same degree.
> Another option would be to write an interpreter for some bytecode
> format. For example, I think that CLISP has a well-documented bytecode.
> This gives you more options in the long run to actually improve
> performance by compiling the bytecode. Other CL implementations use
> bytecodes as well.
>
Yes, I thought about that.
I could definitely do it; however, I'd like the system to be self-hosting
from the Lisp source and up, which means I'd also need to copy CLISP
itself... I'm pretty sure I'm not allowed to copy code like that, but
when it comes to compilers... would the CLISP compiler run with just the
VM - is it self-hosting, I mean?
If so, I'd just need the VM and a REPL. That would be nice.
I'm allowed to use any compiler I feel like on the development machine, so
copying the *compiler* shouldn't be much of a stretch.
I'll go read their documentation now, I think.
From: André Thieme
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca5ho7$d3p$1@ulric.tng.de>
Svein Ove Aas schrieb:
> I'm *not* switching to Scheme; I /like/ multi-paradigm languages, which
> Scheme is not. Well, not to the same degree.
In what way isn't scheme a multi-paradigm language?
Scheme is lisp, isn't it?
Andr�
--
On Wed, 09 Jun 2004 01:25:14 +0200, Andr� Thieme wrote:
> Svein Ove Aas schrieb:
>
>> I'm *not* switching to Scheme; I /like/ multi-paradigm languages, which
>> Scheme is not. Well, not to the same degree.
>
> In what way isn't scheme a multi-paradigm language?
> Scheme is lisp, isn't it?
>
>
> Andr�
Scheme is in the Lisp *family*. I think Scheme is multi-paradigm, but it
is true that it has a stronger bias towards functional style than Common
Lisp does.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
William Bland wrote:
> On Wed, 09 Jun 2004 01:25:14 +0200, Andr� Thieme wrote:
>
>
>>Svein Ove Aas schrieb:
>>
>>
>>>I'm *not* switching to Scheme; I /like/ multi-paradigm languages, which
>>>Scheme is not. Well, not to the same degree.
>>
>>In what way isn't scheme a multi-paradigm language?
>>Scheme is lisp, isn't it?
>>
>>
>>Andr�
>
>
> Scheme is in the Lisp *family*. I think Scheme is multi-paradigm,
Scheme does not have multidimensional arrays, structures and objects,
therefore it is multi-incompatible-paradigm-implementations.
Cheers
--
Marco
In article <················@typhoon.nyu.edu>,
Marco Antoniotti <·······@cs.nyu.edu> wrote:
> William Bland wrote:
>
> > On Wed, 09 Jun 2004 01:25:14 +0200, Andr� Thieme wrote:
> >
> >
> >>Svein Ove Aas schrieb:
> >>
> >>
> >>>I'm *not* switching to Scheme; I /like/ multi-paradigm languages, which
> >>>Scheme is not. Well, not to the same degree.
> >>
> >>In what way isn't scheme a multi-paradigm language?
> >>Scheme is lisp, isn't it?
> >>
> >>
> >>Andr�
> >
> >
> > Scheme is in the Lisp *family*. I think Scheme is multi-paradigm,
>
> Scheme does not have multidimensional arrays, structures and objects,
> therefore it is multi-incompatible-paradigm-implementations.
>
> Cheers
> --
> Marco
But you are aware of the following SRFIs?
http://srfi.schemers.org/srfi-25/
http://srfi.schemers.org/srfi-9/
Objects are still a research topic. ;-)
Svein Ove Aas <··············@brage.info> wrote:
+---------------
| ...writing a simple OS from scratch.
...
| It doesn't need to be self-hosting, but it isn't prohibited either, so I
| was thinking - maybe a C bootstrapper that takes care of the lowest-level
| details including a Lisp VM, and a self-hosting compiler on top of that.
|
| Ideally, the drivers - network, console, etc. - should be written in Lisp
| as well. Would this be fast enough?
+---------------
Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
But seriously, coding up drivers (except perhaps a few simple ones,
as proofs-of-concept), not to mention filesystems, is a *LOT* of work.
It would probably be better to spend your time on the "middle" layers
of the operating system: process scheduler, memory management, etc.
For the low-level driver stuff, may I suggest using the Utah OSkit
(part of the Flux Project)?
<http://www.cs.utah.edu/flux/oskit/>
The OSKit is a framework and a set of 34 component libraries
oriented to operating systems, together with extensive documentation.
By providing in a modular way not only most of the infrastructure
"grunge" needed by an OS, but also many higher-level components,
the OSKit's goal is to lower the barrier to entry to OS R&D and
to lower its costs. The OSKit makes it vastly easier to create a
new OS, port an existing OS to the x86 (or in the future, to other
architectures supported by the OSkit), or enhance an OS to support
a wider range of devices, file system formats, executable formats,
or network services. The OSKit also works well for constructing
OS-related programs, such as boot loaders or OS-level servers atop
a microkernel.
For language researchers and enthusiasts, the OSKit lets them
concentrate on the real issues raised by using advanced languages
inside operating systems, such as Java, Lisp, Scheme, or ML---
instead of spending six months or years groveling inside ugly code
and hardware. ...
The PLT guys used this to make MzScheme[1] run on "bare iron":
<http://download.plt-scheme.org/mzscheme/mz-103p1-bin-i386-kernel-tgz.html>
[Note: I'm not suggesting using Scheme, only that they successfully
used the Flux OSkit to host MzScheme as an "operating system", so you
could presumably do something similar...]
-Rob
[1] Though only for version up through versions 103p1. AFAICT,
versions 200+ no longer support the "bare iron" configuration.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca6bv5$fv5$1@services.kq.no>
Rob Warnock wrote:
> Svein Ove Aas <··············@brage.info> wrote:
> +---------------
> | ...writing a simple OS from scratch.
> ...
> | It doesn't need to be self-hosting, but it isn't prohibited either, so
> | I was thinking - maybe a C bootstrapper that takes care of the
> | lowest-level details including a Lisp VM, and a self-hosting compiler
> | on top of that.
> |
> | Ideally, the drivers - network, console, etc. - should be written in
> | Lisp as well. Would this be fast enough?
> +---------------
>
> Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
>
The Lisp machines used compiled code, though; I'm likely to use bytecode.
Probably works out to sufficient speed on today's hardware anyway.
> But seriously, coding up drivers (except perhaps a few simple ones,
> as proofs-of-concept), not to mention filesystems, is a *LOT* of work.
> It would probably be better to spend your time on the "middle" layers
> of the operating system: process scheduler, memory management, etc.
>
> For the low-level driver stuff, may I suggest using the Utah OSkit
You certainly could, except for the whole "university project" thing. I'm
not allowed to use it.
Svein Ove Aas <··············@brage.info> wrote:
+---------------
| Rob Warnock wrote:
| > Svein Ove Aas <··············@brage.info> wrote:
| > +---------------
| > | ...writing a simple OS from scratch.
...
| > But seriously, coding up drivers (except perhaps a few simple ones,
| > as proofs-of-concept), not to mention filesystems, is a *LOT* of work.
| > It would probably be better to spend your time on the "middle" layers
| > of the operating system: process scheduler, memory management, etc.
| >
| > For the low-level driver stuff, may I suggest using the Utah OSkit
|
| You certainly could, except for the whole "university project" thing.
| I'm not allowed to use it.
+---------------
That's idiotic on the part of your instructors, then!! Modern hardware
is *complex*! (...unless you're going to restrict yourself to 80x86
"real mode" and a serial port for I/O.) You're going to *have* to look
at *some* existing source code, if only to get the register definitions
and the algorithms for how to talk to the hardware.[1] (...unless you work
only from chip manufacturers' data sheets, which are nearly impossible
for end-users to obtain!!!) Hand-translating all that crap into Lisp
just because your O/S is to be "from scratch" is like taking a chemistry
practicum where you're not permitted to use commercially-available
glassware, reagents, or test strips!! (*Sheesh!*)
Why not at least take a brief look at what OSkit[2] gives you in the
way of the lowest-level drivers, and consider how you might build the
infrastructure those drivers depend on in Lisp [so that the "operating
system" -- which manages all of that -- is at least all yours], then
go ask your instructors if using *just* the lowest-level driver code
(and supporting headers!) would be considered "fair"...
-Rob
[1] If you're planning on running on any fairly recent Intel-based
platforms (e.g., any current laptop), you may *have* to look at
somebody's ACPI implementation [such as the Intel reference code],
or you might never be able to get the machine to boot at all!!
[2] Or perhaps the directories /usr/src/sys/i386/{acpica,apm,i386,isa}/
plus /usr/src/sys/contrib/dev/acpica/ from a FreeBSD distribution,
as an alternative.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Joe Marshall
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <d648wz16.fsf@ccs.neu.edu>
····@rpw3.org (Rob Warnock) writes:
> Modern hardware
> is *complex*! (...unless you're going to restrict yourself to 80x86
> "real mode" and a serial port for I/O.) You're going to *have* to look
> at *some* existing source code, if only to get the register definitions
> and the algorithms for how to talk to the hardware.
> [1] If you're planning on running on any fairly recent Intel-based
> platforms (e.g., any current laptop), you may *have* to look at
> somebody's ACPI implementation [such as the Intel reference code],
> or you might never be able to get the machine to boot at all!!
If you are willing to restrict yourself to BIOS functions, there
should be no problem getting the machine to boot and run in 16 bit
mode with 640 K.
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca7a32$mth$1@services.kq.no>
Joe Marshall wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
>> Modern hardware
>> is *complex*! (...unless you're going to restrict yourself to 80x86
>> "real mode" and a serial port for I/O.) You're going to *have* to look
>> at *some* existing source code, if only to get the register definitions
>> and the algorithms for how to talk to the hardware.
>
>> [1] If you're planning on running on any fairly recent Intel-based
>> platforms (e.g., any current laptop), you may *have* to look at
>> somebody's ACPI implementation [such as the Intel reference code],
>> or you might never be able to get the machine to boot at all!!
>
> If you are willing to restrict yourself to BIOS functions, there
> should be no problem getting the machine to boot and run in 16 bit
> mode with 640 K.
>
640K should be enough for everyone, eh?
Actually, according to one of the people who took it last year, the BIOS
on the machines we'll be getting is broken in many non-obvious ways,
specifically the edge cases.
Joe Marshall <···@ccs.neu.edu> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > Modern hardware is *complex*! (...unless you're going to restrict
| > yourself to 80x86 "real mode" and a serial port for I/O.)
| > [1] If you're planning on running on any fairly recent Intel-based
| > platforms (e.g., any current laptop), you may *have* to look at
| > somebody's ACPI implementation [such as the Intel reference code],
| > or you might never be able to get the machine to boot at all!!
|
| If you are willing to restrict yourself to BIOS functions, there
| should be no problem getting the machine to boot and run in 16 bit
| mode with 640 K.
+---------------
Yeah, right. (As if that's enough these days...)
But seriously, the rush to ACPI-only BIOSes is accelerating -- my new
laptop doesn't even *have* any APM BIOS functions, so without ACPI
enabled[1] I couldn't adjust the display brightness, or get the PCMCIA
slot to work, or several oter (to me) essentials. Fortunately Intel
open-sourced a reference implementation[2] that all the BSDs and Linux
use, else we'd all be SOL, but I'd hate to have to recode all that C
code in Lisp just to get a functional base platform for a "Lisp OS".
-Rob
[1] I run FreeBSD 4.9 on my H-P ze4560, and had to fix a couple of
small bugs in the ACPI code before I could boot it with ACPI
enabled without crashing with a kernel panic.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Joe Marshall
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <y8mvtqch.fsf@ccs.neu.edu>
····@rpw3.org (Rob Warnock) writes:
> I'd hate to have to recode all that C
> code in Lisp just to get a functional base platform for a "Lisp OS".
I wouldn't recommend *that*! It is easy enough to write a few lines
of code that can handle the transition from Lisp to C (a very
primitive FFI).
From: Svein Ove Aas
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ca6qq5$bm0$1@services.kq.no>
Rob Warnock wrote:
> Svein Ove Aas <··············@brage.info> wrote:
> +---------------
> | Rob Warnock wrote:
> | > Svein Ove Aas <··············@brage.info> wrote:
> | > +---------------
> | > | ...writing a simple OS from scratch.
> ...
> | > But seriously, coding up drivers (except perhaps a few simple ones,
> | > as proofs-of-concept), not to mention filesystems, is a *LOT* of
> | > work. It would probably be better to spend your time on the "middle"
> | > layers of the operating system: process scheduler, memory
> | > management, etc.
> | >
> | > For the low-level driver stuff, may I suggest using the Utah OSkit
> |
> | You certainly could, except for the whole "university project" thing.
> | I'm not allowed to use it.
> +---------------
>
> That's idiotic on the part of your instructors, then!! Modern hardware
> is *complex*! (...unless you're going to restrict yourself to 80x86
> "real mode" and a serial port for I/O.) You're going to *have* to look
Why, yes. How'd you guess? ;)
Protected mode is nifty, but I'm not sure I'd get enough code/data to have
any use for it. Not that I know what it's for, really, except for the MMU
bits.
Text-mode console support isn't too complex either, apparently.
> at *some* existing source code, if only to get the register definitions
> and the algorithms for how to talk to the hardware.[1] (...unless you
> work only from chip manufacturers' data sheets, which are nearly
> impossible for end-users to obtain!!!) Hand-translating all that crap
> into Lisp just because your O/S is to be "from scratch" is like taking a
> chemistry practicum where you're not permitted to use
> commercially-available glassware, reagents, or test strips!! (*Sheesh!*)
>
You may have a point.
I don't really know what we'll do, having never taken the course before.
I'll find out.
> Why not at least take a brief look at what OSkit[2] gives you in the
> way of the lowest-level drivers, and consider how you might build the
> infrastructure those drivers depend on in Lisp [so that the "operating
> system" -- which manages all of that -- is at least all yours], then
> go ask your instructors if using *just* the lowest-level driver code
> (and supporting headers!) would be considered "fair"...
>
Oh, I'll take a look, all right.
I don't think I'll be allowed to use any code, is all.
>
> -Rob
>
> [1] If you're planning on running on any fairly recent Intel-based
> platforms (e.g., any current laptop), you may *have* to look at
> somebody's ACPI implementation [such as the Intel reference code],
> or you might never be able to get the machine to boot at all!!
>
It's worse than that; it's a modern laptop.
No, it's even worse: It's a HP-branded laptop. (I think? Some brand,
anyway). I've had enough trouble getting my own (generic) laptop to work
in Linux, and mine doesn't have any weird proprietary interfaces.
I'm pretty sure it doesn't have a serial port either... we'll be getting
handouts of a bootloader that prints to the parallell port, though. Not
much of a bootloader; it doesn't "load" anything.
On Wed, 09 Jun 2004 13:05:44 +0200, Svein Ove Aas
<··············@brage.info> wrote:
>Text-mode console support isn't too complex either, apparently.
You really should look at some code if you think this is true.
If your OS is meant to be multitasking in any meaningful way (and if
not it's just a glorifed program loader) then the code for your "text
mode console" will end up being far more complex than the whole of the
multitasking kernel. And that will be just the basic I/O driver
without implementing "curses".
For a sense of the relative complexity involved in various OS modules,
I have always recommended reading Comer's (XINU) and/or Tanenbaum's
(MINIX) books. Both describe, in detail and with full examples, real
(though simplified) Unix-like multitasking OSes explicitly designed
for student implementation and experimentation.
George
--
Send real email to GNEUNER2 at COMCAST o NET
From: Joe Marshall
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <hdtkwz4l.fsf@ccs.neu.edu>
Svein Ove Aas <··············@brage.info> writes:
> Rob Warnock wrote:
>
>> Svein Ove Aas <··············@brage.info> wrote:
>> +---------------
>> | ...writing a simple OS from scratch.
>> ...
>> | It doesn't need to be self-hosting, but it isn't prohibited either, so
>> | I was thinking - maybe a C bootstrapper that takes care of the
>> | lowest-level details including a Lisp VM, and a self-hosting compiler
>> | on top of that.
>> |
>> | Ideally, the drivers - network, console, etc. - should be written in
>> | Lisp as well. Would this be fast enough?
>> +---------------
>>
>> Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
>>
> The Lisp machines used compiled code, though; I'm likely to use bytecode.
> Probably works out to sufficient speed on today's hardware anyway.
The compiled lisp on the Lisp Machine *was* bytecode. The real low
level drivers were written in microcode, though.
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <uzn7c6npx.fsf@news.dtpq.com>
>>>>> On Wed, 09 Jun 2004 11:05:14 -0400, Joe Marshall ("Joe") writes:
Joe> Svein Ove Aas <··············@brage.info> writes:
>> Rob Warnock wrote:
>>
>>> Svein Ove Aas <··············@brage.info> wrote:
>>> +---------------
>>> | ...writing a simple OS from scratch.
>>> ...
>>> | It doesn't need to be self-hosting, but it isn't prohibited either, so
>>> | I was thinking - maybe a C bootstrapper that takes care of the
>>> | lowest-level details including a Lisp VM, and a self-hosting compiler
>>> | on top of that.
>>> |
>>> | Ideally, the drivers - network, console, etc. - should be written in
>>> | Lisp as well. Would this be fast enough?
>>> +---------------
>>>
>>> Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
>>>
>> The Lisp machines used compiled code, though; I'm likely to use bytecode.
>> Probably works out to sufficient speed on today's hardware anyway.
Joe> The compiled lisp on the Lisp Machine *was* bytecode. The real low
Joe> level drivers were written in microcode, though.
Well, on the PDP-10 KL machines, for that matter.
(And on all IBM mainframes, I think.)
And the DEC Alpha.
In article <······················@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Svein Ove Aas <··············@brage.info> wrote:
> +---------------
> | ...writing a simple OS from scratch.
> ...
> | It doesn't need to be self-hosting, but it isn't prohibited either, so I
> | was thinking - maybe a C bootstrapper that takes care of the lowest-level
> | details including a Lisp VM, and a self-hosting compiler on top of that.
> |
> | Ideally, the drivers - network, console, etc. - should be written in Lisp
> | as well. Would this be fast enough?
> +---------------
>
> Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
That is not at all clear.
E.
Erann Gat <·········@flownet.com> writes:
> That is not at all clear.
I think it is all that clear. Disk I/O is reasonably fast if you do
not pass your data through an overly generic stream. There is
anecdotal evidence that network I/O was also quite good on later
machines.
In article <···············@panix3.panix.com>,
Carl Shapiro <·············@panix.com> wrote:
> Erann Gat <·········@flownet.com> writes:
>
> > That is not at all clear.
>
> I think it is all that clear.
Let us remind ourselves what "it" is:
* Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
> Disk I/O is reasonably fast if you do
> not pass your data through an overly generic stream. There is
> anecdotal evidence that network I/O was also quite good on later
> machines.
"Reasonably fast", "quite good", "fast enough" and "clearly fast enough"
are four very distinct concepts.
My personal recollection of LispMs was that they were slower than
molasses in February. Whether this was due to I/O or something else is,
perhaps, debatable, but given that not a single Lisp machine vendor is
in business today I'd say there's a case to be made against the
proposition that anything on the LispM was "clearly fast enough."
E.
In article <·······························@nntp1.jpl.nasa.gov>,
Erann Gat <·········@flownet.com> wrote:
> My personal recollection of LispMs was that they were slower than
> molasses in February. Whether this was due to I/O or something else is,
> perhaps, debatable, but given that not a single Lisp machine vendor is
> in business today I'd say there's a case to be made against the
> proposition that anything on the LispM was "clearly fast enough."
Performance was not the main reason that Lisp Machine vendors went out
of business. It was simply too hard for niche machines to compete with
commodity systems. Take a look at how hard Apple has had to work to
survive against the Wintel market, and multiply the problem by an order
of magnitude.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <uvfi06lup.fsf@news.dtpq.com>
>>>>> On Wed, 09 Jun 2004 20:23:35 -0400, Barry Margolin ("Barry") writes:
Barry> In article <·······························@nntp1.jpl.nasa.gov>,
Barry> Erann Gat <·········@flownet.com> wrote:
>> My personal recollection of LispMs was that they were slower than
>> molasses in February. Whether this was due to I/O or something else is,
>> perhaps, debatable, but given that not a single Lisp machine vendor is
>> in business today I'd say there's a case to be made against the
>> proposition that anything on the LispM was "clearly fast enough."
Barry> Performance was not the main reason that Lisp Machine vendors
Barry> went out of business. It was simply too hard for niche
Barry> machines to compete with commodity systems. Take a look at
Barry> how hard Apple has had to work to survive against the Wintel
Barry> market, and multiply the problem by an order of magnitude.
The reason the Lisp Machine vendors went out of business varies
by vendor. In the case of Symbolics, it had mostly to do with
business issues (eg. real estate deals) rather than Lisp Machines.
I think that in an analysis of the failure of the company, the
impact of any performance issues (or any technical issues) were
totally in the noise. But all the vendors were devastated by the
"AI Winter" in which anything with the words "AI" or "Lisp" was anathama.
Shortly before Symbolics finally went under for the last time,
it had new RISC chips that were going to blow the socks off the
latest SPARC chips. This was the "S" Machine aka the "SUN killer",
but it never saw the light of day. Technical issues, including
competing in the CPU market against the big boys, was not the problem.
Another unfortunate casualty of the culmination of a bad business situation.
The last thing I worked on for Symbolics was an embedded real-time
packaging of the current Ivory chip, and that Lisp Machine was plenty
"fast enough" for that, featuring impressive guaranteed response times.
(This was not Genera - it was a new extended-ANSI-CL operating system.)
The customer was very happy with the product, but it was killed for
enirely political reasons. (And the company was already almost
entirely down the tubes by that point.)
The last ditch effort was to make an all-software port of Genera,
running on a virtual Lisp Machine - an Ivory byte-code interpreter
for the DEC Alpha running under Unix. Because it all fit in the
cache, this ran like a bat out of hell. It was competitive with
(eg. could beat) native Alpha implementations of Lisp, and was
about an order of magnitude faster than the Ivory hardware.
(This was on the fastest hardware of the day, much faster than the
SPARC chips, with Intel computers were even worth mentioning.)
Again, performance was not the issue.
Symbolics could have been a viable niche vendor, if they had been
able to stay in business long enough. They could also have been
a commodity player, but corporate and technical stragegies would
have had to have been different from a much earlier timepoint.
Maybe they could have survived "AI Winter", but that would have
only been possible with some amazing foresight.
Anyone who thinks that the failure of Symbolics was due to hardware
of software performance issues must have never studied the company's
financials or done much historical analysis of the market.
It's just another version of the "Lisp is slow" myth.
Too bad that a quarter of a century ago we Lisp Machine guys were
naive technocrats who didn't know anything fundamental about business,
I think we all know by now that business success has practically
nothing to do with technical product quality. However, I don't imagine
that this obvious fact is taught in engineering schools today, either.
It's not something that scientists and engineers like to hear.
"Christopher C. Stacy" <······@news.dtpq.com> wrote in message
··················@news.dtpq.com...
> I think we all know by now that business success has practically
> nothing to do with technical product quality. However, I don't imagine
> that this obvious fact is taught in engineering schools today, either.
> It's not something that scientists and engineers like to hear.
And they still don't. Consarn it, I go to this newsgroup to participate in a
fantasy world where technical superiority wins the day. Stop interfering
with the suspension of reality! Next you'll be reminding me that everyone
else is using C++.
Christopher C. Stacy wrote:
> Too bad that a quarter of a century ago we Lisp Machine guys were
> naive technocrats who didn't know anything fundamental about business,
> I think we all know by now that business success has practically
> nothing to do with technical product quality. However, I don't imagine
> that this obvious fact is taught in engineering schools today, either.
> It's not something that scientists and engineers like to hear.
It might be a slight overstatement. I've been around from the start on
what I would regard as technically good products, both successes and
failures. I think it's not that technical quality is irrelevant, but
that it's only one of several important factors, and may be overwhelmed
by others. To take a recent example, in an emerging market with perhaps
a half dozen serious competitors I've seen the two best technologies win
largely on technical merit, but compete against one another on the basis
of customer relationship issues. I think it may be common that once
products reach a certain minimum threshold of technical merit, technical
differences become overwhelmed by other considerations. In part this may
be because past that minimum threshold, the real costs and benefits of
technical differences may be much harder to predict and measure than the
costs and benefits of other considerations.
mikel <·····@evins.net> wrote:
> Christopher C. Stacy wrote:
>
>> Too bad that a quarter of a century ago we Lisp Machine guys were
>> naive technocrats who didn't know anything fundamental about business,
>> I think we all know by now that business success has practically
>> nothing to do with technical product quality. However, I don't imagine
>> that this obvious fact is taught in engineering schools today, either.
>> It's not something that scientists and engineers like to hear.
>
> It might be a slight overstatement. I've been around from the start on
> what I would regard as technically good products, both successes and
> failures. I think it's not that technical quality is irrelevant, but
> that it's only one of several important factors, and may be overwhelmed
> by others. To take a recent example, in an emerging market with perhaps
> a half dozen serious competitors I've seen the two best technologies win
> largely on technical merit, but compete against one another on the basis
> of customer relationship issues. I think it may be common that once
> products reach a certain minimum threshold of technical merit, technical
> differences become overwhelmed by other considerations. In part this may
> be because past that minimum threshold, the real costs and benefits of
> technical differences may be much harder to predict and measure than the
> costs and benefits of other considerations.
Donald Norman once wrote about this issue in his book "The Invisible
Computer". He just mentioned that you have at least to kinds of products:
exchangeable and infrastructural. While in the first catagory there can be
many competitors because customers can easily switch to another vendor if
they dislike the current one. But for infrastructural products this isn't
easily possible, since infrastructural means that there are a lot more
other products depending on this product (the infrastructure) to be
available. Thus a change of an infrastructural product is very expensive
and thus only one (or none) can exist. This can be accomplished by either
a common standard or a monopoly of one company- or it doesn't persist at
all, meaning that some other technology will thrive. (Norman mentiones the
US mobile phone system, where vendeors coudn't agree on one standard for a
digital protocol, which lead to anologous devices staying on the marked.)
To overcome an existing environment (i.e. infrastructure) you thus must
not be just better but be _much_ better to be worth a change (he, IIRC,
speaks of 130%).
Of course, this isn't all the truth. Furthermore you have to understand
and/or influence the customers by good marketing (at the right time). I.e.
like MS did with IBM in the 80s where they also loosened their license
terms a bit in order to spread their software, and support vendors
creating more products running in their environment.
Still there are other considerations. E.g. you have to focus on the right
group of users. A diagram in Norman's book characterised them like in this
diagram:
^ _.--- y-axis: market share
| ,' x-axis: time
| / EA: .. Early adopters (tech fans)
| / TG: .. Target Group (the majority,
|__.-' the "normal people")
+---------------> LA: .. late adopters (the "doubters")
| EA | TG | LA
So, since the vast amount of people are average users you have to focus on
them in order to maximize your market share. The early adopters are nice
to help you in your early days but if you want to grow (and you mostly you
just have to) you have to annoy your early adopters and focus on the
average people. I think many technologist couldn't do this.
-ts
--
,,
\../ / <<< The LISP Effect
|_\\ _==__
__ | |bb| | _________________________________________________
Thomas Schilling wrote:
> mikel <·····@evins.net> wrote:
>
>> Christopher C. Stacy wrote:
[...good points snipped...]
> Still there are other considerations. E.g. you have to focus on the
> right group of users. A diagram in Norman's book characterised them like
> in this diagram:
>
> ^ _.--- y-axis: market share
> | ,' x-axis: time
> | / EA: .. Early adopters (tech fans)
> | / TG: .. Target Group (the majority,
> |__.-' the "normal people")
> +---------------> LA: .. late adopters (the "doubters")
> | EA | TG | LA
>
> So, since the vast amount of people are average users you have to focus
> on them in order to maximize your market share. The early adopters are
> nice to help you in your early days but if you want to grow (and you
> mostly you just have to) you have to annoy your early adopters and focus
> on the average people. I think many technologist couldn't do this.
These considerations form a technical field in themselves, and can be
quite complicated. To oversimplify some, the target market of a new
product may be early adopters (if it's a substantially new kind of
product) or average users (if it's a new version of an old kind of
product -- this is a very tough market to enter). Once you have found a
large market for a product line your bread and butter comes from sales
to that target market, and you tend to become quite conservative about
changes that might lose sales to those customers. Further product
development increasingly focuses on squeezing out extra margin from the
large existing customer base by adding small incremental feature changes
aimed at pleasing existing customers. Substantial changes to products
are increasingly risky to that established revenue base, and yet are
exactly what's needed to make large advancements in any metric of
quality, including technical quality.
In other words, the risk/benefit analysis is substantially different for
a new firm from that for an established firm. Business nerds (some of
whom I work with) can get really detailed and technical about this
stuff, and I've learned to appreciate their cogent analysis of a very
difficult subject.
There's also always a question of how much it costs to increase some
metric of quality, and how much return you are likely to get from that
investment. That question is a matter of guesswork evenn in the best of
circumstances, though the business types work really hard to try to make
the guesses as educated as possible.
Engineers are fond of companies like Ferrari and Porsche because they
really push certain sexy technical metrics hard, but on thee other hand
they struggle to make a profit (I don't know if Ferrari has turned a
profit at all for a long time).
On Thu, 10 Jun 2004 12:58:41 GMT, mikel <·····@evins.net> wrote:
> Engineers are fond of companies like Ferrari and Porsche because
> they really push certain sexy technical metrics hard, but on thee
> other hand they struggle to make a profit (I don't know if Ferrari
> has turned a profit at all for a long time).
Porsche is generally considered to be the most profitable car maker
worldwide in the last years (but it's true that they almost went
bankrupt in the 80s).
Edi.
Edi Weitz wrote:
> On Thu, 10 Jun 2004 12:58:41 GMT, mikel <·····@evins.net> wrote:
>
>
>>Engineers are fond of companies like Ferrari and Porsche because
>>they really push certain sexy technical metrics hard, but on thee
>>other hand they struggle to make a profit (I don't know if Ferrari
>>has turned a profit at all for a long time).
>
>
> Porsche is generally considered to be the most profitable car maker
> worldwide in the last years (but it's true that they almost went
> bankrupt in the 80s).
Nevertheless, they make a good example. They are a small manufacturer
whose fortunes are always bet on a small, relatively narrow product
line. Their products are expensive to design, produce, and market, and
are therefore extremely risky: as several product introductions have
shown, a single misstep in product design has significant risk of
sinking the company. The 928, for example, despite being a very good
car, nearly did them in because it just wasn't quite what their target
market wanted.
This kind of high risk is intrinsic to any product line that
differentiates by spending a lot to raise some particular quality metric
significantly relative to competitors'. The marginal increase in the
metric decreases for each dollar spent, and the marginal value of the
increase also decreases, so that it becomes extremely expensive to raise
the metric enough to attract significant buyer interest. That nonlinear
increase in expense necessarily increases risk, which is itself a cost,
and therefore makes the product even more expensive (also in a nonlinear
way).
Ferrari, if I'm not mistaken, has rarely been profitable in recent
years, and survives chiefly as a jewel in the crown of whatever larger,
more profitable company happens to own them.
mikel <·····@evins.net> wrote:
+---------------
| Edi Weitz wrote:
| > Porsche is generally considered to be the most profitable car maker
| > worldwide in the last years (but it's true that they almost went
| > bankrupt in the 80s).
|
| Nevertheless, they make a good example. They are a small manufacturer
| whose fortunes are always bet on a small, relatively narrow product line.
+---------------
Hunh? I thought that Porsche/Audi/Volkswagon was all the same company
underneath the brand names. E.g., you could always drop Porsche engines
directly into a VW Beetle chassis; my VW Dasher squareback was *identical*
to an Audi Fox squareback [even had the Audi Fox logo on the steering
wheel]; etc. Not so?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Edi Weitz
Subject: [OT] Porsche (Was: Is it feasible to use Lisp to write an OS?)
Date:
Message-ID: <87smd21u1p.fsf_-_@bird.agharta.de>
On Thu, 10 Jun 2004 21:33:33 -0500, ····@rpw3.org (Rob Warnock) wrote:
> Hunh? I thought that Porsche/Audi/Volkswagon was all the same
> company underneath the brand names. E.g., you could always drop
> Porsche engines directly into a VW Beetle chassis; my VW Dasher
> squareback was *identical* to an Audi Fox squareback [even had the
> Audi Fox logo on the steering wheel]; etc. Not so?
Not quite. Volkswagen is one big company (I think it's Europe's
biggest car maker) and some of their brands are VW, Audi, Seat, Skoda,
Bentley, Lamborghini, and Bugatti. However, Porsche is an independent
company with no direct connection to Volkswagen. They share some
history (the first "Volkswagen" car, the original Beetle, was
constructed in 1934 by Ferdinand Porsche) and there have been
collaborations (like the new Porsche Cayenne which is almost identical
to the VW Touareg).
Edi.
> mikel <·····@evins.net> wrote:
>> I think it may be common that once products reach a certain minimum
>> threshold of technical merit, technical differences become overwhelmed by
>> other considerations. In part this may be because past that minimum
>> threshold, the real costs and benefits of technical differences may be
>> much harder to predict and measure than the costs and benefits of other
>> considerations.
That's probably true.
Thomas Schilling <······@yahoo.de> wrote on Thu, 10 Jun 2004:
> Donald Norman once wrote about this issue in his book "The Invisible
> Computer".
> Still there are other considerations. E.g. you have to focus on the right
> group of users. A diagram in Norman's book characterised them like in this
> diagram:
> ^ _.--- y-axis: market share
> | ,' x-axis: time
> | / EA: .. Early adopters (tech fans)
> | / TG: .. Target Group (the majority,
> |__.-' the "normal people")
> +---------------> LA: .. late adopters (the "doubters")
> | EA | TG | LA
This topic was covered in much more detail in Geoffrey Moore's "Crossing
the Chasm":
http://www.amazon.com/exec/obidos/tg/detail/-/0060517123/qid=1086888085/sr=1-1/ref=sr_1_1/002-0778647-8824830?v=glance&s=books
The graph you've suggested is the "technology adoption life cycle", which was
first derived in agricultural studies, looking at the adoption of new grains
by US farmers. It is best seen as a full bell curve, where there is a
downslope after the curve you've drawn. So you have the "early majority"
(the bulk of people on the upslope), and the "late majority" (past the peak).
But the real "late adopters" take place in the tiny tail to the far right:
people who avoid making changes at all costs, until their previous choices
are simply no longer available.
> So, since the vast amount of people are average users you have to focus on
> them in order to maximize your market share. The early adopters are nice to
> help you in your early days but if you want to grow (and you mostly you just
> have to) you have to annoy your early adopters and focus on the average
> people. I think many technologist couldn't do this.
"Crossing the Chasm" is all about making that transition. It isn't easy,
for some fundamental reasons. And a new startup generally can't appeal to
the majority from day one. Especially with a new technology, they generally
have to find a niche of early adopters to get off the ground.
The problem comes that the features appreciated by early adopters are very
different from those valued by the majority. So all your initial feedback
about what is "working" in the young years of your company will in fact be
actively undermining your attempt to cross over to a product designed for
the vast majority.
Even knowing this theory, and the history of other startups, it still isn't
easy to successfully navigate this transition, whether you're a technologist
or a business guy.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Most of the time it was probably real bad being stuck down in a dungeon. But
some days, when there was a bad storm outside, you'd look out your little
window and think, ``Boy, I'm glad I'm not out in THAT.''
-- Deep Thoughts, by Jack Handey
Don Geddis wrote:
> The problem comes that the features appreciated by early adopters are very
> different from those valued by the majority. So all your initial feedback
> about what is "working" in the young years of your company will in fact be
> actively undermining your attempt to cross over to a product designed for
> the vast majority.
...I wouldn't mind if a Common Lisp vendor would offer a simplified
stripped-down variant of Common Lisp, maybe with a more mainstream
syntax, that uses the same runtime environment and is generally
compatible with Common Lisp. This would allow expert Common Lispers to
help non-experts with more difficult tasks. Something like Dylan, but
closer to CL than to Scheme, for example...
Just brainstorming.
Pascal
--
1st European Lisp and Scheme Workshop
June 13 - Oslo, Norway - co-located with ECOOP 2004
http://www.cs.uni-bonn.de/~costanza/lisp-ecoop/
Pascal Costanza <········@web.de> writes:
> Don Geddis wrote:
>
> > The problem comes that the features appreciated by early adopters are very
> > different from those valued by the majority. So all your initial feedback
> > about what is "working" in the young years of your company will in fact be
> > actively undermining your attempt to cross over to a product designed for
> > the vast majority.
>
> ...I wouldn't mind if a Common Lisp vendor would offer a simplified
> stripped-down variant of Common Lisp, maybe with a more mainstream
> syntax, that uses the same runtime environment and is generally
> compatible with Common Lisp. This would allow expert Common Lispers to
> help non-experts with more difficult tasks. Something like Dylan, but
> closer to CL than to Scheme, for example...
>
> Just brainstorming.
I don't think the syntax is the real killer. It didn't take me that
long to get comfortable with parenthesized prefix notation. That
notation seems to also be what makes macros doable in Lisp.
I think that right now the barriers are rather more mundane. Sockets,
threads, and GUIs. Oh my!
We've hashed this topic quite recently (re-re-re-rehashed?). I don't
think it's going to go away though. The new generation of code
monkeys expect certain facilities to be available. A good development
environment is also a must. Emacs + SLIME is quite a good effort, but
how will people rate that next to Xcode or Visual Studio .NET?
I suspect that providing the mundane bits above is really not that
difficult compared to the other problem. The other problem is purely
social. It's the popularity contest. Lisp's low popularity is a real
problem because it means that all the zillions of libraries that Perl
and Python people have are not there.
Popularity is a problem because inter-operation is important in
software systems. For better or worse, XML is becoming the exchange
format. If there is a better language to write the libraries for
dealing with XML than Lisp, I sure don't know what it is.
Another issue of popularity is that programmers are seen as
replaceable cogs. That is an easy goal with Java programmers. It
should be even easier to swap out VB programmers. If Lisp was more
popular, then Lisp programers could also be swapped out just as
easily. That would make the language viable on a larger scale.
I know I'm leaving out the part where any major software system is too
complex to swap out the people who understand it with ease. I meet so
few managers who understand things on those terms though.
--
An ideal world is left as an excercise to the reader.
--- Paul Graham, On Lisp 8.1
From: Sergey Kataev
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <omdcac.esv.ln@195.171.216.1>
Pascal Costanza wrote:
> ...I wouldn't mind if a Common Lisp vendor would offer a simplified
> stripped-down variant of Common Lisp, maybe with a more mainstream
> syntax, that uses the same runtime environment and is generally
> compatible with Common Lisp. This would allow expert Common Lispers to
> help non-experts with more difficult tasks. Something like Dylan, but
> closer to CL than to Scheme, for example...
>
> Just brainstorming.
>
>
> Pascal
Not quite Common Lisp, but still something readily available...
Cogent, a canadian company, offers language called Gamma.
Lisp VM with lisp syntax and optional C-like syntax.
Works in Linux and QNX, and I know they had another OS port but I dont
see it available for download.
Pros: pretty lightweight and fast;
very well-documented;
fast IPC, sending raw text s-expressions;
"easy" syntax for those who can't read parentheses.
Cons: proprietary;
available only for two OSes;
dynamically scoped;
many simplifications from CL.
Developers can download it free of charge "for non-commercial use".
I should thank them for spoiling me with LISP after all, it wouldn't
have happened if they had no "easy" syntax.
Sergey
Don Geddis wrote:
> Thomas Schilling <······@yahoo.de> wrote on Thu, 10 Jun 2004:
> > Donald Norman once wrote about this issue in his book "The Invisible
> > Computer".
> > Still there are other considerations. E.g. you have to focus on the right
> > group of users. A diagram in Norman's book characterised them like in this
> > diagram:
> > ^ _.--- y-axis: market share
> > | ,' x-axis: time
> > | / EA: .. Early adopters (tech fans)
> > | / TG: .. Target Group (the majority,
> > |__.-' the "normal people")
> > +---------------> LA: .. late adopters (the "doubters")
> > | EA | TG | LA
>
> This topic was covered in much more detail in Geoffrey Moore's "Crossing
> the Chasm":
> http://www.amazon.com/exec/obidos/tg/detail/-/0060517123/qid=1086888085/sr=1-1/ref=sr_1_1/002-0778647-8824830?v=glance&s=books
>
> The graph you've suggested is the "technology adoption life cycle", which was
> first derived in agricultural studies, looking at the adoption of new grains
> by US farmers. It is best seen as a full bell curve, where there is a
> downslope after the curve you've drawn.
I think you are mistaken about the relationship between Norman's
sigmoid and Moore's bell curve. The sigmoid isn't half of the
bell curve, it's the integral of the bell curve. So the peak
of the bell curve corresponds to the maximum-slope bit of the
sigmoid, right in the middle where it's labelled "TG".
--
Gareth McCaughan
.sig under construc
From: ·········@random-state.net
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <cam2o4$dd9mg$1@midnight.cs.hut.fi>
Gareth McCaughan <················@pobox.com> wrote:
> Don Geddis wrote:
>> Thomas Schilling <······@yahoo.de> wrote on Thu, 10 Jun 2004:
> I think you are mistaken about the relationship between Norman's
> sigmoid and Moore's bell curve. The sigmoid isn't half of the
Not directly related, but interesting none the less:
"The Hype Cycle of New Technologies"
http://www.riarlington.com/hypecyc.html
Cheers,
-- Nikodemus "Not as clumsy or random as a C++ or Java.
An elegant weapon for a more civilized time."
On Thu, 10 Jun 2004 13:39:45 +0200, Thomas Schilling wrote:
> Still there are other considerations. E.g. you have to focus on the right
> group of users. A diagram in Norman's book characterised them like in this
> diagram:
>
> ^ _.--- y-axis: market share
> | ,' x-axis: time
> | / EA: .. Early adopters (tech fans)
> | / TG: .. Target Group (the majority,
> |__.-' the "normal people")
> +---------------> LA: .. late adopters (the "doubters")
> | EA | TG | LA
>
You also have to be good at judging where a product is on this curve, or
spend time and money trying to measure where it is. A bunch of us at work
were talking about this curve in relation to DVDs. basically everyone
under 30 (the people who haven't touched a VHS cassette in years) agreed
that DVDs are at the Late Adopter stage, and anyone who uses VHS is a
dinosaur. Most of the people over 30 felt that DVDs were still in either
the Early Adopter or Target Group stages.
At opposite ends of the spectrum were myself (gave up DVDs a while ago,
now keep all my movies on hard-disk), and another person who thought he
had been an Early Adopter by recently buying his first DVD player!
It's all very subjective if you're not careful.
Cheers,
Bill.
--
Dr. William Bland.
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax. (Ken Anderson).
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
> Anyone who thinks that the failure of Symbolics was due to hardware
> of software performance issues must have never studied the company's
> financials or done much historical analysis of the market.
Do you have some pointers to learn more? I looked at one or two on the
Symbolics museum, and I don't recall them mentioning anything
interesting. (But it was a while back.)
The thing about Apple has nothing to do with quality, in my
observation. They fired their visionary/founder and seemed to have
major political problems. The only reason Apple exists is they were
sitting on an oil well, as was Microsoft. MS was possibly the only
sane company.
Being sane, they controlled the viral commodity PC assemblers to work
for them. Anyway, that's how it seems from here.
> Too bad that a quarter of a century ago we Lisp Machine guys were
> naive technocrats who didn't know anything fundamental about business,
> I think we all know by now that business success has practically
> nothing to do with technical product quality. However, I don't imagine
> that this obvious fact is taught in engineering schools today, either.
> It's not something that scientists and engineers like to hear.
Ever heard of that _In Search of Stupidity_ book? Its thesis is that
companies like MS succeed by avoiding fatal mistakes. Not by marketing
or technical brilliance, but by avoiding idiocy.
http://www.insearchofstupidity.com/
I've talked with the author a bit, and he desires to provide an
"institutional memory" which new companies lack, on what to avoid.
Erann Gat <·········@flownet.com> wrote in message news:<·······························@nntp1.jpl.nasa.gov>...
>
> My personal recollection of LispMs was that they were slower than
> molasses in February. Whether this was due to I/O or something else is,
> perhaps, debatable, but given that not a single Lisp machine vendor is
> in business today I'd say there's a case to be made against the
> proposition that anything on the LispM was "clearly fast enough."
>
I agree with this. They were (and still are) really fun to use, but
my memory is that a lot of aspects of their performance (disk and
network performance specifically) seriously sucked compared to the
competition, and price/performance sucked so much it wasn't even
funny. There are probably 6-month periods when this wasn't true if
you were in the right place which people will now regurgitate (hint:
choose a period just before Suns started shipping, and/or a LispM that
never made it into production, or a prototype which only became
commercially available 3 years later).
This is hard to verify today - I'm not aware of any disk or network
I/O figures, and although I do have a LispM (currently not working as
it has no disk and I can't get at it to fit one...) I don't have, say,
Suns of the same era to compare, or price lists for either.
I remember talking to people who were making a decision between a
LispM and Suns. I forget the options, but the machines they got were
some AI-configuration Sun 3/160s, which had more memory, a wonderful
high-resolution screen, much better disk & network I/O, were
general-purpose multi-user machines, came with Lucid licenses and so
on. And you could get three for the price of the LispM.
--tim
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <uisdzzdlz.fsf@news.dtpq.com>
>>>>> On 10 Jun 2004 04:23:30 -0700, Tim Bradshaw ("Tim") writes:
Tim> I remember talking to people who were making a decision between a
Tim> LispM and Suns. I forget the options, but the machines they got were
Tim> some AI-configuration Sun 3/160s, which had more memory, a wonderful
Tim> high-resolution screen, much better disk & network I/O, were
Tim> general-purpose multi-user machines, came with Lucid licenses and so
Tim> on. And you could get three for the price of the LispM.
Which Lisp Machine architecture and machine model and configuration
are you comparing to what configuration Sun 3/160 and at what time?
From: Tim Bradshaw
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ey3k6yf57nm.fsf@cley.com>
* Christopher C Stacy wrote:
> Which Lisp Machine architecture and machine model and configuration
> are you comparing to what configuration Sun 3/160 and at what time?
Some Symbolics 3xxx, late 80s (I think).
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <u1xknxtct.fsf@news.dtpq.com>
>>>>> On 10 Jun 2004 04:23:30 -0700, Tim Bradshaw ("Tim") writes:
Tim> I agree with this. They were (and still are) really fun to use, but
Tim> my memory is that a lot of aspects of their performance (disk and
Tim> network performance specifically) seriously sucked compared to the
Tim> competition, and price/performance sucked so much it wasn't even
Tim> funny. There are probably 6-month periods when this wasn't true if
Tim> you were in the right place which people will now regurgitate (hint:
Tim> choose a period just before Suns started shipping, and/or a LispM that
Tim> never made it into production, or a prototype which only became
Tim> commercially available 3 years later).
This does not match my experience, but I was always using (either as a
customer, or as a developer at Symbolics) one of the latest available
production machines. The conventional workstations that I used during
the same time were all SUNs.
Can you provide some performance data that includes the date along with
the machines and OS versions being compared and their configurations?
I suspect that there are combinations where the SUN machine would have
beat the Symbolics machine on certain kinds of tests (although you may
not be exactly comparing apples), but random disparaging remarks are
not very elucidating as to the facts or what issues (that might be
relevent today) might be.
From: Tim Bradshaw
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ey3brjr576q.fsf@cley.com>
* Christopher C Stacy wrote:
> Can you provide some performance data that includes the date along with
> the machines and OS versions being compared and their
> configurations?
No. This is getting on for 20 years ago: can you? (Particularly, say
for disk performance and network performance, and relative per-user
cost.) If I cared then I definitely don't care now. It was a fairly
serious comparison on which a reasonably large purchase rested.
I know, I know, it's important to always maintain that anything
Symbolics made was better than those horrible lower-class Unix
machines. Kill me now.
--tim
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <usmd2hybr.fsf@news.dtpq.com>
>>>>> On Fri, 11 Jun 2004 00:23:09 +0100, Tim Bradshaw ("Tim") writes:
Tim> * Christopher C Stacy wrote:
>> Can you provide some performance data that includes the date along with
>> the machines and OS versions being compared and their
>> configurations?
Tim> No. This is getting on for 20 years ago: can you?
I'm not the one making performance claims.
From: Tim Bradshaw
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ey3wu29nurn.fsf@cley.com>
* Christopher C Stacy wrote:
>>>>>> On Fri, 11 Jun 2004 00:23:09 +0100, Tim Bradshaw ("Tim") writes:
> I'm not the one making performance claims.
Indeed not, but I was careful to say in my original article
This is hard to verify today - I'm not aware of any disk or
network I/O figures, and although I do have a LispM (currently not
working as it has no disk and I can't get at it to fit one...) I
don't have, say, Suns of the same era to compare, or price lists
for either.
I found your immediate followup
Can you provide some performance data that includes the date along
with the machines and OS versions being compared and their
configurations? I suspect that there are combinations where the
SUN machine would have beat the Symbolics machine on certain kinds
of tests (although you may not be exactly comparing apples), but
random disparaging remarks are not very elucidating as to the
facts or what issues (that might be relevent today) might be.
somewhat curious. I guess you may not have read the whole article
carefully enough: sorry for my somewhat abrupt response in that case.
--tim
(There was also an error in the next paragraph of my article: the Suns
concerned were (AI configuration) 3/260s, not 3/160s. I'm not even
sure if 3/160s existed, although there were 3/180s so I'd guess they
did - 3/260s were the deskside versions of 3/280s, so I guess 3/160s
were an equivalent variant on 3/180s. 3/260s were very nice machines
for their time, performance wise - the environment sucked compared to
a LispM obviously, but then everything did.)
On Tue, 15 Jun 2004 09:30:04 +0100, Tim Bradshaw wrote:
> (There was also an error in the next paragraph of my article: the Suns
> concerned were (AI configuration) 3/260s, not 3/160s. I'm not even
> sure if 3/160s existed, although there were 3/180s so I'd guess they
> did - 3/260s were the deskside versions of 3/280s, so I guess 3/160s
> were an equivalent variant on 3/180s. 3/260s were very nice machines
> for their time, performance wise - the environment sucked compared to
> a LispM obviously, but then everything did.)
The specs for all the models are at:
<http://sunsolve.sun.com/handbook_pub/Systems/Sun3/FEH3.enter.html>
There was a 3/160.
Looking at the 3/260 specs, I expect that they came with a fair bit
of memory.
I have a file containing the Gabriel benchmarks results for Lucid and AKCL
that William Schelter ran on a 3/280 in 87. They are all better than the
lispm results from the book.
Robert Swindells
"Robert Swindells" <···@fdy2.demon.co.uk> wrote in message news:<······························@fdy2.demon.co.uk>...
>
>
> The specs for all the models are at:
>
> <http://sunsolve.sun.com/handbook_pub/Systems/Sun3/FEH3.enter.html>
>
> There was a 3/160.
>
> Looking at the 3/260 specs, I expect that they came with a fair bit
> of memory.
>
Yes, I think they did, especially the AI config ones. They were very
good machines hardwarily for their time (as was the 3/280 of course).
However, do note that I was specifically talking about network & disk
I/O rather than raw CPU/memory performance.
On Thu, 17 Jun 2004 05:07:27 -0700, Tim Bradshaw wrote:
> "Robert Swindells" <···@fdy2.demon.co.uk> wrote in message news:<······························@fdy2.demon.co.uk>...
>>
>>
>> The specs for all the models are at:
>>
>> <http://sunsolve.sun.com/handbook_pub/Systems/Sun3/FEH3.enter.html>
>>
>> There was a 3/160.
>>
>> Looking at the 3/260 specs, I expect that they came with a fair bit
>> of memory.
>>
>
> Yes, I think they did, especially the AI config ones. They were very
> good machines hardwarily for their time (as was the 3/280 of course).
>
> However, do note that I was specifically talking about network & disk
> I/O rather than raw CPU/memory performance.
I know. The fread and fprint benchmarks are not testing raw disk
performance, but it will influence the total time. It would have
been interesting if times were recorded for remote filesystems
as well as (presumably) local.
My reason for commenting was that I had thought that UNIX workstations
had only overtaken lisp machines in performance on AI type benchmarks
when the first RISC chips came out.
Robert Swindells
··········@tfeb.org (Tim Bradshaw) writes:
> I remember talking to people who were making a decision between a
> LispM and Suns. I forget the options, but the machines they got were
> some AI-configuration Sun 3/160s, which had more memory, a wonderful
> high-resolution screen, much better disk & network I/O, were
> general-purpose multi-user machines, came with Lucid licenses and so
> on. And you could get three for the price of the LispM.
Hmm. When at Xerox PARC during the summer of '88, I had a brand new
Sun 4 (a SPARC, not one of those 68k Sun 3s) with Lucid to play with
in addition to a Xerox Lisp machine and a Macintosh II, and I don't
remember the Sun as very impressive compared to the Xerox. The Mac,
however, was very interesting price-wise, MCL (it was MACL back then)
was really a lot of bang for the buck (especially since it could do
with only a fraction of the RAM) (but it didn't support real
multithreading yet).
(one of the problems with Lucid was that its memory requirements
were outrageous for '88 standards, I think that may have been partly
due to the fact that this was an early sparc version, so my
memories may be a little unfair to Lucid)
--
(espen)
From: Tim Bradshaw
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ey3fz9357gj.fsf@cley.com>
* Espen Vestre wrote:
> Hmm. When at Xerox PARC during the summer of '88, I had a brand new
> Sun 4 (a SPARC, not one of those 68k Sun 3s) with Lucid to play with
> in addition to a Xerox Lisp machine and a Macintosh II, and I don't
> remember the Sun as very impressive compared to the Xerox.
We benchmarked some of the commercially available d-machines (Doves
and Dandytigers were what we had) against fairly early SPARC boxes
(4/110, 4/65s and 4/330s) running ACL for a specific application.
They were completely non-competitive, *unless* you drove them into
paging when they did OK. I could probably find these figures (but,
see following article, I can't actually be bothered).
--tim
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Espen Vestre wrote:
> > Hmm. When at Xerox PARC during the summer of '88, I had a brand new
> > Sun 4 (a SPARC, not one of those 68k Sun 3s) with Lucid to play with
> > in addition to a Xerox Lisp machine and a Macintosh II, and I don't
> > remember the Sun as very impressive compared to the Xerox.
>
> We benchmarked some of the commercially available d-machines (Doves
> and Dandytigers were what we had) against fairly early SPARC boxes
> (4/110, 4/65s and 4/330s) running ACL for a specific application.
> They were completely non-competitive, *unless* you drove them into
> paging when they did OK. I could probably find these figures (but,
> see following article, I can't actually be bothered).
We (at University of []) regularly benchmarked LispM hardware (both Explorer
and Symbolics) against UNIX implementations before we purchased new
equipment running several "largish" (for the time, in academia) AI systems.
In 1984, Symbolics machines were clearly superior to the Vax 7xx's we had
available in the same price range. In 1986 Symbolics won again over Sun
implementations and the Explorer I. About the time the Explorer II came out
(88?), that won out over the 3620 (the latest Symbolics machine) and
whatever Sun was the top of the line workstation running Lucid. When the
UX400 came out, we got one to maintain Symbolics for development of new code
and maintenance of existing code, but we had already moved to using Franz
ACL for actual code execution on Sparcstations. (5s & 10s as I recall). By
95, even the UX400 wasn't used anymore.
One can argue that Symbolics failed for reasons other than performance, but
Price/Performance was the primary reason we stopped investing in Lisp
machines. When a Sun seat dropped below $5k, it became easy to justify
buying one per grad student. LispM seats were never that cheap. At some
point we probably would have stopped anyway, because our UI research
required something more flexible than CLIM, and LispMs did not have the best
X server implementation, though the client was pretty good for the purposes
of the UX.
··········@tfeb.org (Tim Bradshaw) writes:
> This is hard to verify today - I'm not aware of any disk or network
> I/O figures, and although I do have a LispM (currently not working as
> it has no disk and I can't get at it to fit one...) I don't have, say,
> Suns of the same era to compare, or price lists for either.
This is not related to I/O. But some time ago, I run across an old
posting by SWM to the CLIM mailing list. He gave a rough performance
comparison of CLIM applications on a variety of architectures and
operating systems. He compared the performance of a Symbolics LispM
to that of a 33 MHz 486 PC.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> writes:
> This is not related to I/O. But some time ago, I run across an old
> posting by SWM to the CLIM mailing list. He gave a rough performance
It was posted in the early 1990s.
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools (Google for info on each):
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Paolo Amoroso <·······@mclink.it> wrote:
> This is not related to I/O. But some time ago, I run across an old
> posting by SWM to the CLIM mailing list. He gave a rough performance
> comparison of CLIM applications on a variety of architectures and
> operating systems. He compared the performance of a Symbolics LispM
> to that of a 33 MHz 486 PC.
While trying to port SciGraph to Lispworks CLIM a while ago, I found a
small piece of timing code that included the following comment:
;; In genera on a 3600, this can be done 800 times per second.
I timed the same code with Lispworks 4.2 on a new Toshiba laptop a year
ago, and it ran about 70,000 times per second. That's almost 90 times as
fast. I took that as an indication that most of the hairier optimizations
in SciGraph are probably not necessary anymore.
Arthur Lemmens
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <uoenqhy9a.fsf@news.dtpq.com>
>>>>> On Fri, 11 Jun 2004 17:30:52 +0200, Arthur Lemmens ("Arthur") writes:
Arthur> Paolo Amoroso <·······@mclink.it> wrote:
>> This is not related to I/O. But some time ago, I run across an old
>> posting by SWM to the CLIM mailing list. He gave a rough performance
>> comparison of CLIM applications on a variety of architectures and
>> operating systems. He compared the performance of a Symbolics LispM
>> to that of a 33 MHz 486 PC.
Arthur> While trying to port SciGraph to Lispworks CLIM a while ago, I found a
Arthur> small piece of timing code that included the following comment:
Arthur> ;; In genera on a 3600, this can be done 800 times per second.
Arthur> I timed the same code with Lispworks 4.2 on a new Toshiba laptop a year
Arthur> ago, and it ran about 70,000 times per second.
That sounds about right for Moore's Law over 20 years, doesn't it?
Tim Bradshaw wrote:
[Erann Gat, about LispMs:]
> > My personal recollection of LispMs was that they were slower than
> > molasses in February. Whether this was due to I/O or something else is,
> > perhaps, debatable, but given that not a single Lisp machine vendor is
> > in business today I'd say there's a case to be made against the
> > proposition that anything on the LispM was "clearly fast enough."
[Tim:]
...
> I remember talking to people who were making a decision between a
> LispM and Suns. I forget the options, but the machines they got were
> some AI-configuration Sun 3/160s, which had more memory, a wonderful
> high-resolution screen, much better disk & network I/O, were
> general-purpose multi-user machines, came with Lucid licenses and so
> on. And you could get three for the price of the LispM.
<unix-haters>And they booted really fast, too.</unix-haters>
--
Gareth McCaughan
.sig under construc
Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...
>
> <unix-haters>And they booted really fast, too.</unix-haters>
They certainly did. Even better, you didn't *need* to reboot them
when you trashed your Lisp image, which was ... an improvement.
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <uk6y6ymhh.fsf@news.dtpq.com>
>>>>> On 17 Jun 2004 11:43:11 -0700, Tim Bradshaw ("Tim") writes:
Tim> Gareth McCaughan <················@pobox.com> wrote in message news:<··············@g.mccaughan.ntlworld.com>...
>>
>> <unix-haters>And they booted really fast, too.</unix-haters>
Tim> They certainly did. Even better, you didn't *need* to reboot them
Tim> when you trashed your Lisp image, which was ... an improvement.
In what way did you trash your Lisp image?
······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
>
> In what way did you trash your Lisp image?
Lots of ways: horribly mangling the package system was a favourite. I
know, given enough time and intimate knowlege of the implementation
it's possible to recover from almost anything. For the rest of us,
saving files and restarting the Lisp is often a more realistic option
though.
--tim
From: Christopher C. Stacy
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ullil5f9k.fsf@news.dtpq.com>
>>>>> On 18 Jun 2004 02:52:11 -0700, Tim Bradshaw ("Tim") writes:
Tim> ······@news.dtpq.com (Christopher C. Stacy) wrote in message news:<·············@news.dtpq.com>...
>>
>> In what way did you trash your Lisp image?
Tim> Lots of ways: horribly mangling the package system was a
Tim> favourite. I know, given enough time and intimate knowlege of
Tim> the implementation it's possible to recover from almost
Tim> anything. For the rest of us, saving files and restarting the
Tim> Lisp is often a more realistic option though.
I guess I'm still left wondering how that happened.
You seemed to be suggesting that the systems were
unstable and randomly crashed on you all the time.
That is hardly the experience that I am familiar with.
From: Joe Marshall
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <u0xjtq3l.fsf@ccs.neu.edu>
Erann Gat <·········@flownet.com> writes:
> In article <···············@panix3.panix.com>,
> Carl Shapiro <·············@panix.com> wrote:
>
>> Erann Gat <·········@flownet.com> writes:
>>
>> > That is not at all clear.
>>
>> I think it is all that clear.
>
> Let us remind ourselves what "it" is:
>
> * Well, it was certainly fast enough for the Lisp Machines!! ;-} ;-}
>
>> Disk I/O is reasonably fast if you do
>> not pass your data through an overly generic stream. There is
>> anecdotal evidence that network I/O was also quite good on later
>> machines.
>
> "Reasonably fast", "quite good", "fast enough" and "clearly fast enough"
> are four very distinct concepts.
>
> My personal recollection of LispMs was that they were slower than
> molasses in February. Whether this was due to I/O or something else is,
> perhaps, debatable, but given that not a single Lisp machine vendor is
> in business today I'd say there's a case to be made against the
> proposition that anything on the LispM was "clearly fast enough."
`Fast enough to satisfy the users expectations' is much harder to
achieve than `fast enough to handle incoming ethernet packets on a
10KBS line without dropping them'.
In article <············@ccs.neu.edu>, Joe Marshall <···@ccs.neu.edu>
wrote:
> `Fast enough to satisfy the users expectations' is much harder to
> achieve than `fast enough to handle incoming ethernet packets on a
> 10KBS line without dropping them'.
And in fact, Symbolics 36xx Lispms *couldn't* handle wire-speed traffic
on an Ethernet. We ran into problems when we started using them as NFS
clients of Sun fileservers, and the Lispm would almost always report
read timeouts. The problem was that the default read-size was 8KB,
which would be fragmented by IP into 6 packets, which the server would
send in rapid succession, but the Lispm's NIC could only buffer about 4
of them and the others would be dropped. This doesn't cause fatal
problems for TCP-based protocols, because TCP automatically adjusts for
congestion, but UDP doesn't have any similar mechanism. Sun's NFS
client implementation automatically reduced the read-size when it
noticed a few timeouts in a row, but the Symbolics implementation
didn't. Luckily it was just a global variable, which I adjusted in our
site images, and things worked OK.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
From: Tim Bradshaw
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <ey37juf573i.fsf@cley.com>
* Barry Margolin wrote:
> And in fact, Symbolics 36xx Lispms *couldn't* handle wire-speed traffic
> on an Ethernet. We ran into problems when we started using them as NFS
> clients of Sun fileservers, and the Lispm would almost always report
> read timeouts. The problem was that the default read-size was 8KB,
> which would be fragmented by IP into 6 packets, which the server would
> send in rapid succession, but the Lispm's NIC could only buffer about 4
> of them and the others would be dropped. This doesn't cause fatal
> problems for TCP-based protocols, because TCP automatically adjusts for
> congestion, but UDP doesn't have any similar mechanism. Sun's NFS
> client implementation automatically reduced the read-size when it
> noticed a few timeouts in a row, but the Symbolics implementation
> didn't. Luckily it was just a global variable, which I adjusted in our
> site images, and things worked OK.
Right. Not only slower, but the implementation sucked too.
--tim
From: Pekka Niiranen
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <40C8ADDE.5020108@wlanmail.com>
Svein Ove Aas wrote:
> This autumn I'll be taking a course in my university that, among other
> things, involves writing a simple OS from scratch.
>
> The usual plan seems to be to write it in C, but I haven't been able to
> find any restrictions other than "it must work". Obviously, you need a
> lot more groundwork to run Lisp code than you do to run C code, but is it
> feasible to write a simple Lisp (interpreter?) in C and use that?
>
> I won't have time to reimplement all of Common Lisp, but some useful
> subset should be possible.
>
> It doesn't need to be self-hosting, but it isn't prohibited either, so I
> was thinking - maybe a C bootstrapper that takes care of the lowest-level
> details including a Lisp VM, and a self-hosting compiler on top of that.
>
> Ideally, the drivers - network, console, etc. - should be written in Lisp
> as well. Would this be fast enough? (How fast *is* CLISP anyway? Would a
> tenth of that do?) I'm not sure about the GC, but that's a detail.
>
>
> Having a decent REPL would help with debugging, but is it at all possible
> to complete something like this in one semester, or am I smoking crack?
> I won't have much of anything else to do, so let's say ~3 months to be on
> the safe side.
Check this out: http://www.oliotalo.fi/hedgehog/hoglisp.html
-pekka-
From: Pekka Niiranen
Subject: Re: Is it feasible to use Lisp to write an OS?
Date:
Message-ID: <40C8B83C.9030704@wlanmail.com>
Check this out: http://www.oliotalo.fi/hedgehog/hoglisp.html
Svein Ove Aas wrote:
> This autumn I'll be taking a course in my university that, among other
> things, involves writing a simple OS from scratch.
>
> The usual plan seems to be to write it in C, but I haven't been able to
> find any restrictions other than "it must work". Obviously, you need a
> lot more groundwork to run Lisp code than you do to run C code, but is it
> feasible to write a simple Lisp (interpreter?) in C and use that?
>
> I won't have time to reimplement all of Common Lisp, but some useful
> subset should be possible.
>
> It doesn't need to be self-hosting, but it isn't prohibited either, so I
> was thinking - maybe a C bootstrapper that takes care of the lowest-level
> details including a Lisp VM, and a self-hosting compiler on top of that.
>
> Ideally, the drivers - network, console, etc. - should be written in Lisp
> as well. Would this be fast enough? (How fast *is* CLISP anyway? Would a
> tenth of that do?) I'm not sure about the GC, but that's a detail.
>
>
> Having a decent REPL would help with debugging, but is it at all possible
> to complete something like this in one semester, or am I smoking crack?
> I won't have much of anything else to do, so let's say ~3 months to be on
> the safe side.