I've been surveying the software and wondering what you lispers would
use out of today's linux software (sorry Joswig, I know nada about
mac :-) to emulate symbolic's OS. Here are some of my ideas.
Editor -- Emacs/Xemacs
Ftp -- ftp with lisp overlay
File Manager -- Emacs
Scripting -- Clisp, can use cmucl with run-program
Browser -- W3
Word processing -- Curl but rather limited. Probably would be exciting
to mix groff or latex with common lisp's defstruct.
Program Manager -- Emacs, have experimented with cmucl and run-program
X-window-manager -- Sawfish, but see next sentence.
Sockets, Tcp, Lisp to C conversion for drivers?
A lot more could be done with a dot file manager in lisp. This would
help with window-managers, etc.
Any other software out there? Ideas?
i.b.
IBMackey wrote:
> I've been surveying the software and wondering what you lispers would
> use out of today's linux software (sorry Joswig, I know nada about
> mac :-) to emulate symbolic's OS. Here are some of my ideas.
>
> Editor -- Emacs/Xemacs
> Ftp -- ftp with lisp overlay
> File Manager -- Emacs
> Scripting -- Clisp, can use cmucl with run-program
> Browser -- W3
> Word processing -- Curl but rather limited. Probably would be exciting
> to mix groff or latex with common lisp's defstruct.
> Program Manager -- Emacs, have experimented with cmucl and run-program
> X-window-manager -- Sawfish, but see next sentence.
> Sockets, Tcp, Lisp to C conversion for drivers?
>
> A lot more could be done with a dot file manager in lisp. This would
> help with window-managers, etc.
KDE2 is fully scriptable with XMLRPC.
As there is at least one XMLRPC-Client Package for CormanLisp and CMUCL
(should be easy portable) it is possible to access in near future each KDE2
Application.
To say it clearly - I do think by myself that XMLRPC is a rather simple and
ressource-wasting RPC-protocoll - but it is so easy to develop language
bindings that it is probably the best alternative for scripting purposes.
I cannot promise you anything but I and a friend plan to begin in february
to write a GUI-Server which will allow OS and Lisp-System indepenent
development.
The first design-rule will be simplicity too - we want/need this thing as
soon as possible so it could be possible that not everyone likes some of
the decisions we will make.
We will develop our own protocoll for that purpose. I think a protocoll
that handles GUIs on a _much_ higher level than X-Window could probably be
much more useful when used over low-bandwidth lines.
The GUI-Toolkit is not chosen so far - probably wxWindows or Java. I for
myself would prefer wxWindows over Java because Java-GUIs suck under UNIX
(particularily swing). I'am open for any hints.
If someone other is interested to participate - don't hesitate to post here
and/or mail me.
Imagine - if we have a free universally usable GUI-Toolkit for Lisp, it
would be possible to develop a rather sophisticated IDE usable with _all_
Lisps on _all_ OSes. We could use Emacs for the editing side. Probably we
could enhance ILISP with class- and functionbrowsers, graphical debuggers
and inspectors, GUI-builders ....
Regards,
Jochen
--
http://www.dataheaven.de
Jochen Schmidt <···@dataheaven.de> writes:
> IBMackey wrote:
>
> > I've been surveying the software and wondering what you lispers would
> > use out of today's linux software (sorry Joswig, I know nada about
> > mac :-) to emulate symbolic's OS. Here are some of my ideas.
> >
> > Editor -- Emacs/Xemacs
> > Ftp -- ftp with lisp overlay
> > File Manager -- Emacs
> > Scripting -- Clisp, can use cmucl with run-program
> > Browser -- W3
> > Word processing -- Curl but rather limited. Probably would be exciting
> > to mix groff or latex with common lisp's defstruct.
> > Program Manager -- Emacs, have experimented with cmucl and run-program
> > X-window-manager -- Sawfish, but see next sentence.
> > Sockets, Tcp, Lisp to C conversion for drivers?
> >
> > A lot more could be done with a dot file manager in lisp. This would
> > help with window-managers, etc.
>
> KDE2 is fully scriptable with XMLRPC.
...
> Imagine - if we have a free universally usable GUI-Toolkit for Lisp, it
> would be possible to develop a rather sophisticated IDE usable with _all_
> Lisps on _all_ OSes. We could use Emacs for the editing side. Probably we
> could enhance ILISP with class- and functionbrowsers, graphical debuggers
> and inspectors, GUI-builders ....
That is commendable, as long as you take into account
(a) the beast must run on every major CL implementation
(b) CMUCL has SERVE-EVENT you must deal with. (No, you cannot use the
MP package in CMUCL because it has not been ported to Solaris yet.)
Note that (a) conflicts immediately with your search for simplicity.
The simplicity you want is the simplicity for the user (in this case a
programmer), *not* for the developer.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti wrote:
>
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> IBMackey wrote:
>>
>> > I've been surveying the software and wondering what you lispers would
>> > use out of today's linux software (sorry Joswig, I know nada about
>> > mac :-) to emulate symbolic's OS. Here are some of my ideas.
>> >
>> > Editor -- Emacs/Xemacs
>> > Ftp -- ftp with lisp overlay
>> > File Manager -- Emacs
>> > Scripting -- Clisp, can use cmucl with run-program
>> > Browser -- W3
>> > Word processing -- Curl but rather limited. Probably would be exciting
>> > to mix groff or latex with common lisp's defstruct.
>> > Program Manager -- Emacs, have experimented with cmucl and run-program
>> > X-window-manager -- Sawfish, but see next sentence.
>> > Sockets, Tcp, Lisp to C conversion for drivers?
>> >
>> > A lot more could be done with a dot file manager in lisp. This would
>> > help with window-managers, etc.
>>
>> KDE2 is fully scriptable with XMLRPC.
>
> ...
>
>> Imagine - if we have a free universally usable GUI-Toolkit for Lisp, it
>> would be possible to develop a rather sophisticated IDE usable with _all_
>> Lisps on _all_ OSes. We could use Emacs for the editing side. Probably we
>> could enhance ILISP with class- and functionbrowsers, graphical debuggers
>> and inspectors, GUI-builders ....
>
> That is commendable, as long as you take into account
>
> (a) the beast must run on every major CL implementation
> (b) CMUCL has SERVE-EVENT you must deal with. (No, you cannot use the
> MP package in CMUCL because it has not been ported to Solaris yet.)
>
> Note that (a) conflicts immediately with your search for simplicity.
> The simplicity you want is the simplicity for the user (in this case a
> programmer), *not* for the developer.
No.
The GUI-Server will not be developed with CL. If there were a
CL-GUI-Toolkit that would allow this I would not need to write one at all.
It would be *much* more difficult to e.g. develop the CL-GUI-Toolkit with
the FFIs of the CL-Systems.
(b) There is nothing that enforces me to use SERVE-EVENT in CMUCL. Yes it
would be nice if it could be so integrated but if it would lead to much
more difficulties then I will go another way. Time will show. Maybe it's
time for CMUCL-Solaris _and_ CLISP to get it's MP package ;-)
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Marco Antoniotti wrote:
>
> >
> > Jochen Schmidt <···@dataheaven.de> writes:
> >
> >> IBMackey wrote:
> >>
> >> > I've been surveying the software and wondering what you lispers would
> >> > use out of today's linux software (sorry Joswig, I know nada about
> >> > mac :-) to emulate symbolic's OS. Here are some of my ideas.
> >> >
> >> > Editor -- Emacs/Xemacs
> >> > Ftp -- ftp with lisp overlay
> >> > File Manager -- Emacs
> >> > Scripting -- Clisp, can use cmucl with run-program
> >> > Browser -- W3
> >> > Word processing -- Curl but rather limited. Probably would be exciting
> >> > to mix groff or latex with common lisp's defstruct.
> >> > Program Manager -- Emacs, have experimented with cmucl and run-program
> >> > X-window-manager -- Sawfish, but see next sentence.
> >> > Sockets, Tcp, Lisp to C conversion for drivers?
> >> >
> >> > A lot more could be done with a dot file manager in lisp. This would
> >> > help with window-managers, etc.
> >>
> >> KDE2 is fully scriptable with XMLRPC.
> >
> > ...
> >
> >> Imagine - if we have a free universally usable GUI-Toolkit for Lisp, it
> >> would be possible to develop a rather sophisticated IDE usable with _all_
> >> Lisps on _all_ OSes. We could use Emacs for the editing side. Probably we
> >> could enhance ILISP with class- and functionbrowsers, graphical debuggers
> >> and inspectors, GUI-builders ....
> >
> > That is commendable, as long as you take into account
> >
> > (a) the beast must run on every major CL implementation
> > (b) CMUCL has SERVE-EVENT you must deal with. (No, you cannot use the
> > MP package in CMUCL because it has not been ported to Solaris yet.)
> >
> > Note that (a) conflicts immediately with your search for simplicity.
> > The simplicity you want is the simplicity for the user (in this case a
> > programmer), *not* for the developer.
>
> No.
> The GUI-Server will not be developed with CL. If there were a
> CL-GUI-Toolkit that would allow this I would not need to write one at all.
> It would be *much* more difficult to e.g. develop the CL-GUI-Toolkit with
> the FFIs of the CL-Systems.
There must be a CL part in this project. Hence at some level you
*wiil* have to deal with portability issues.
> (b) There is nothing that enforces me to use SERVE-EVENT in CMUCL. Yes it
> would be nice if it could be so integrated but if it would lead to much
> more difficulties then I will go another way. Time will show. Maybe it's
> time for CMUCL-Solaris _and_ CLISP to get it's MP package ;-)
Allow me to be blunt here. CLisp and CMUCL-Solaris do not have a MP.
However, as far as CMUCL is concerned, there is a nice way to deal
with "asynchronous" and "concurrent" events (double quotes intended).
If you are not taking that into account your system will not "do the
right thing" in CMUCL. This is the reason why the original port of
CL-GTK did not quite make it.
The point that I want to make is that your project is commendable,
yet, it *must* address these issues. Otherwise it *will* fall short
of its intended aim.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti wrote:
>> No.
>> The GUI-Server will not be developed with CL. If there were a
>> CL-GUI-Toolkit that would allow this I would not need to write one at
>> all. It would be *much* more difficult to e.g. develop the CL-GUI-Toolkit
>> with the FFIs of the CL-Systems.
>
> There must be a CL part in this project. Hence at some level you
> *wiil* have to deal with portability issues.
Yes sure. I think we'll try to make the CL-Part as similar to CAPI as we
get it. By simplicity is really meant simplicity of implementation. We will
probably not have much time and I think this project will be to important
to let it die in a to long design-phase.
Yes maybe it will be a hack - but it will do something that is not here yet
and perhaps will never come if no one begins.
See it as a prototype or draft.
>> (b) There is nothing that enforces me to use SERVE-EVENT in CMUCL. Yes it
>> would be nice if it could be so integrated but if it would lead to much
>> more difficulties then I will go another way. Time will show. Maybe it's
>> time for CMUCL-Solaris _and_ CLISP to get it's MP package ;-)
>
> Allow me to be blunt here. CLisp and CMUCL-Solaris do not have a MP.
> However, as far as CMUCL is concerned, there is a nice way to deal
> with "asynchronous" and "concurrent" events (double quotes intended).
> If you are not taking that into account your system will not "do the
> right thing" in CMUCL. This is the reason why the original port of
> CL-GTK did not quite make it.
Yes that is true - but what I meant was more that this problem doesn*t
exist only with CMUCL. CLISP doesn't have MP too. I think all comes down to
non-blocking (asynchronous) I/O between GUI-Server and Lisp. The problem
with SERVE-EVENT is that tis usage is so completely different to that the
other implementations deliver. Perhaps it is easier to use select() in all
implementations than to use it in some and in CMUCL SERVE-EVENT. What are
the different possibilites to do non-blocking I/O in the different CLs:
CMUCL: SERVE-EVENT
CLISP: wrapper for select() (only UNIX? Windows too?)
ACL: Don't know
LispWorks: Don't know
CormanLisp: Don't know
SBCL: the socket-package allows explicit setting of sockets to non-blocking
as I remember.
It would be nice if the maintainers of this projects (or people that know
it too) can give me some information on how to do that.
> The point that I want to make is that your project is commendable,
> yet, it *must* address these issues. Otherwise it *will* fall short
> of its intended aim.
Yes that is true. And I think it would be very good to hear other opinions
of the comunity upon this project.
The one and only thing I can say is that it will be somewhat restricted in
the beginnings (e. g. few widget-types).
but I'am sure that it will grow if it exists. If we plan and plan and
design so that it has all that we can imagine then i'am sure it would be
never begun.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
...
> Yes maybe it will be a hack - but it will do something that is not here yet
> and perhaps will never come if no one begins.
> See it as a prototype or draft.
...
> The one and only thing I can say is that it will be somewhat restricted in
> the beginnings (e. g. few widget-types).
> but I'am sure that it will grow if it exists. If we plan and plan and
> design so that it has all that we can imagine then i'am sure it would be
> never begun.
Think about "worse is better"?
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
In article <··············@mailandnews.com>, IBMackey
<········@hotmail.com> wrote:
> I've been surveying the software and wondering what you lispers would
> use out of today's linux software (sorry Joswig, I know nada about
> mac :-) to emulate symbolic's OS. Here are some of my ideas.
>
> Editor -- Emacs/Xemacs
> Ftp -- ftp with lisp overlay
> File Manager -- Emacs
> Scripting -- Clisp, can use cmucl with run-program
> Browser -- W3
> Word processing -- Curl but rather limited. Probably would be exciting
> to mix groff or latex with common lisp's defstruct.
> Program Manager -- Emacs, have experimented with cmucl and run-program
> X-window-manager -- Sawfish, but see next sentence.
> Sockets, Tcp, Lisp to C conversion for drivers?
>
> A lot more could be done with a dot file manager in lisp. This would
> help with window-managers, etc.
>
> Any other software out there? Ideas?
Some thoughts:
First you need to be clear about you really want:
"what you lispers would use out of today's linux software
to emulate symbolic's OS."
Above does not really make sense. See following link to read
about Symbolics' Genera operating system's philosophy:
http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/genera/genera.html
The difference is so, that you cannot reasonably "emulate"
it (on Linux), by a collection of not integrated software.
But Genera is not "the Lisp OS" - just one out of
several and it has a special design - but it is an OS.
Everything in Genera is written in Lisp
(virtual memory, process scheduler, TCP stack, applications,
you name it) and runs in one big Lisp system. It is also a single user
operating system - one user per machine at a time. It has
also some very unusual facilities that you won't find anywhere
else.
What could make sense under Linux?
a) everything on top of the kernel is Lisp software (tough)
b) use as much Lisp software as possible (evolutionary)
c) use as much integrated Lisp software as possible (tough)
d) accept software that "just" provides a high-level
interface to low-level stuff (some existing stuff)
e) use Lisp-scriptable applications where possible (-> GUILE)
f) maybe provide some of the unusual Genera facilities for the
Linux/Unix user (-> writing of "some" KLOCs of Lisp code needed)
g) copy a bit of the development environment
(tough)
If you want to go with free Common Lisp software, one needs
to go with CMUCL (IMHO, for many applications
Clisp is also sufficient). But it is not quite there
(some stuff is kind-of existing):
- it may need to be able to run on more platforms
- it needs one or more modern GCs (robust and for several platforms)
- it needs multithreading (robust and on several platforms)
- after that the software needs to take advantage of
the GC and the multithreading
- it needs a modern GUI toolkit
- it may need to be integrateable into other software
(then you could replace GUILE)
- it may need to get smaller
- and many other issues
(note that some of the commercial Lisps are already
better for that. ACL for example is quite robust and
has a lot of low-level stuff really working.
LispWorks has an X-based GUI that would be a start.)
Studying the discussions on the LispOS mailing list
(which is dead) might be interesting (and you
get a realistic view not to start too ambitious -
and starting at all is the problem).
(CMUCL has for example an editor written in Lisp
(Hemlock), and other parts of a GUI-based development
environment. Also don't forget the FreeCLIM project.
And something like Plob!.)
If you don't want to go the "one running Lisp" route,
than it is necessary to have multiple running Lisps
to be able to communicate with each other and other
running software. So, if the environment is using
something like CORBA for that, then the Lisp system needs
to talk CORBA, too.
CMUCL is cool and people are hacking on it. I'm pretty
optimistic that there is enough interest to improve
CMUCL over time.
Maybe some members of the CMUCL user community can
give an more in-depth overview of the state of CMUCL,
what it is being used for currently, what are generally its
application areas and what not (can you write
a window manager with CMUCL?).
Anyway, writing/using Lisp applications is the key.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
<······@corporate-world.lisp.de> wrote:
>In article <··············@mailandnews.com>, IBMackey
><········@hotmail.com> wrote:
>
>But Genera is not "the Lisp OS" - just one out of
>several and it has a special design - but it is an OS.
>Everything in Genera is written in Lisp
Would it be feasible to port that to Intel (if the source code is
available for this purpose)?
>CMUCL is cool and people are hacking on it. I'm pretty
>optimistic that there is enough interest to improve
>CMUCL over time.
Is a win32 port being considered?
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Fernando Rodr�guez <·······@must.die> writes:
> On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
>
> >In article <··············@mailandnews.com>, IBMackey
> ><········@hotmail.com> wrote:
> >
>
> >But Genera is not "the Lisp OS" - just one out of
> >several and it has a special design - but it is an OS.
> >Everything in Genera is written in Lisp
>
> Would it be feasible to port that to Intel (if the source code is
> available for this purpose)?
Essentially no.
I think you could get much further if you wrote an emulator for the
Symbolics hardware (actually, for the `virtual machine' that the
microcode implemented).
I don't think the source code is available, though.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
From: ······@corporate-world.lisp.de
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <94vpmc$lsq$1@nnrp1.deja.com>
In article <············@content-integrity.com>,
Joe Marshall <···@content-integrity.com> wrote:
> Fernando Rodr�guez <·······@must.die> writes:
>
> > On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
> > <······@corporate-world.lisp.de> wrote:
> >
> > >In article <··············@mailandnews.com>, IBMackey
> > ><········@hotmail.com> wrote:
> > >
> >
> > >But Genera is not "the Lisp OS" - just one out of
> > >several and it has a special design - but it is an OS.
> > >Everything in Genera is written in Lisp
> >
> > Would it be feasible to port that to Intel (if the source code is
> > available for this purpose)?
>
> Essentially no.
>
> I think you could get much further if you wrote an emulator for the
> Symbolics hardware (actually, for the `virtual machine' that the
> microcode implemented).
There are/were assembler (Alpha) and C-version(s?) of the
Ivory (the microprocessor) emulator.
> I don't think the source code is available, though.
Atleast not publicly.
Sent via Deja.com
http://www.deja.com/
From: ······@corporate-world.lisp.de
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <94vo0v$kr7$1@nnrp1.deja.com>
In article <··································@4ax.com>,
Fernando Rodr�guez <·······@must.die> wrote:
> On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
>
> >In article <··············@mailandnews.com>, IBMackey
> ><········@hotmail.com> wrote:
> >
>
> >But Genera is not "the Lisp OS" - just one out of
> >several and it has a special design - but it is an OS.
> >Everything in Genera is written in Lisp
>
> Would it be feasible to port that to Intel (if the source code is
> available for this purpose)?
It would be possible to port the emulator. It would be
a *lot* of work though.
> >CMUCL is cool and people are hacking on it. I'm pretty
> >optimistic that there is enough interest to improve
> >CMUCL over time.
>
> Is a win32 port being considered?
I can't answer that.
Sent via Deja.com
http://www.deja.com/
······@corporate-world.lisp.de wrote in message
<············@nnrp1.deja.com>...
>In article <··································@4ax.com>,
> Fernando Rodr�guez <·······@must.die> wrote:
>> On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
>> <······@corporate-world.lisp.de> wrote:
>>
>> >In article <··············@mailandnews.com>, IBMackey
>> ><········@hotmail.com> wrote:
>> >
>>
>> >But Genera is not "the Lisp OS" - just one out of
>> >several and it has a special design - but it is an OS.
>> >Everything in Genera is written in Lisp
>>
>> Would it be feasible to port that to Intel (if the source code is
>> available for this purpose)?
>
>It would be possible to port the emulator. It would be
>a *lot* of work though.
I was one of the people who wrote the OpenGenera emulator
for the Alpha. It's semantics and performance depend on
running on 64-bit addressable machine. It's implementation
is very carefully tuned for the [formerly] DEC Alpha. Porting
it would involve rewriting the emulator entirely, but since the
emulator is probably fewer than 20,000 lines of machine code,
I would guess this isn't as much work as you might thing.
The "life support" that glues Genera to the native OS for doing
I/O and windowing support is the expensive part.
In article <······················@typhoon.ne.mediaone.net>,
"Scott McKay" <···@mediaone.net> writes:
>
> ······@corporate-world.lisp.de wrote in message
> <············@nnrp1.deja.com>...
>>It would be possible to port the emulator. It would be
>>a *lot* of work though.
>
>
> I was one of the people who wrote the OpenGenera emulator
> for the Alpha. It's semantics and performance depend on
> running on 64-bit addressable machine. It's implementation
> is very carefully tuned for the [formerly] DEC Alpha. Porting
> it would involve rewriting the emulator entirely, but since the
> emulator is probably fewer than 20,000 lines of machine code,
> I would guess this isn't as much work as you might thing.
>
> The "life support" that glues Genera to the native OS for doing
> I/O and windowing support is the expensive part.
For the three or four years, I've had this crazy idea to reverse engineer
the underlying instruction set of my XL1201 and write an emulator in C. (Isaid
it was CRAZY, didn't I!) I had come to the conclusion that emulating the
instruction set was probably doable but adding support for all that "life
support" was not feasable. By "life support", I'm meaning all of those
hardware device interfaces like graphics, ethernet, keyboard, disks, ... Since
I don't have the ability to generate a custom world load easily (I probably
can't make it use X as the default console, for instance.), I'm pretty much
stuck having to emulate those hardware devices, with only minor tweaking of
the world load.
It sure would be a neat hack though!
Mike McDonald
·······@mikemac.com
Mike McDonald <·······@mikemac.com> wrote:
+---------------
| For the three or four years, I've had this crazy idea to reverse engineer
| the underlying instruction set of my XL1201 and write an emulator in C.
| (Isaid it was CRAZY, didn't I!) I had come to the conclusion that emulating
| the instruction set was probably doable but adding support for all that
| "life support" was not feasable. By "life support", I'm meaning all of those
| hardware device interfaces like graphics, ethernet, keyboard, disks, ...
| Since I don't have the ability to generate a custom world load easily
| (I probably can't make it use X as the default console, for instance.),
| I'm pretty much stuck having to emulate those hardware devices, with only
| minor tweaking of the world load.
+---------------
Well, others have been doing similar things recently. For inspiration,
wander over to alt.sys.pdp10 and take a look at what a fellow named
Timothy Stark has been doing with an emulator for a DEC KL-10/KS-10.
He's got several versions of TOPS-10 & TOPS-20 up and running (well,
limping), using the binary installation tapes as his fixed "world load".
Quite amazing stuff!! [Plus, his emulator -- on an 800 MHz Pentium --
is running more than 5 times faster than a KL-10B!! Which caused some
bugs, actually...]
And yes, he had to emulate the I/O channels, tapes, disks, front-end
processor, terminals, etc., to get the system software to boot correctly.
So don't give up yet...
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
From: Tim Bradshaw
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <ey3vgqw4rxi.fsf@cley.com>
* Rob Warnock wrote:
> Well, others have been doing similar things recently. For inspiration,
> wander over to alt.sys.pdp10 and take a look at what a fellow named
> Timothy Stark has been doing with an emulator for a DEC KL-10/KS-10.
> He's got several versions of TOPS-10 & TOPS-20 up and running (well,
> limping), using the binary installation tapes as his fixed "world load".
> Quite amazing stuff!! [Plus, his emulator -- on an 800 MHz Pentium --
> is running more than 5 times faster than a KL-10B!! Which caused some
> bugs, actually...]
Somewhere I read that someone (XKL?) is funding a port of gcc to the
PDP10.
--tim
in article ·····················@typhoon.aracnet.com, Mike McDonald at
·······@mikemac.com wrote on 01-01-29 11:46:
> In article <······················@typhoon.ne.mediaone.net>,
> "Scott McKay" <···@mediaone.net> writes:
>>
>> ······@corporate-world.lisp.de wrote in message
>> <············@nnrp1.deja.com>...
>
>>> It would be possible to port the emulator. It would be
>>> a *lot* of work though.
[...]
>> The "life support" that glues Genera to the native OS for doing
>> I/O and windowing support is the expensive part.
>
> For the three or four years, I've had this crazy idea to reverse engineer
> the underlying instruction set of my XL1201 and write an emulator in C. (Isaid
> it was CRAZY, didn't I!) I had come to the conclusion that emulating the
> instruction set was probably doable but adding support for all that "life
> support" was not feasable. By "life support", I'm meaning all of those
> hardware device interfaces like graphics, ethernet, keyboard, disks, ... Since
> I don't have the ability to generate a custom world load easily (I probably
> can't make it use X as the default console, for instance.), I'm pretty much
> stuck having to emulate those hardware devices, with only minor tweaking of
> the world load.
If you were to reverse-engineer the VLM, you would have an easier time.
Rather than emulating a lot of weird hardware, you would just have to
implement the life support RPC mechanism and field the calls that Genera
makes to get its file, etc. services from the underlying O/S.
The VLM life support was based on the MacIvory life support, just replacing
the Mac implementations of the various services with Unix ones.
For the record, as I understood it, Harlequin, Franz, and MIT wanted to buy
Symbolics at it's last bankruptcy and put everything in the public domain,
but they were outbid. Next time, let's take up a collection!
Fernando Rodríguez <·······@must.die> writes:
> >But Genera is not "the Lisp OS" - just one out of
> >several and it has a special design - but it is an OS.
> >Everything in Genera is written in Lisp
>
> Would it be feasible to port that to Intel (if the source code is
> available for this purpose)?
The only thing that seems in any way a feasible approach to me would
be to port the Alpha Ivory Emulator that underlies Open Genera to a
more mainstream 64bit platform, once that exists. Of course even that
seems quite tricky, given that the emulator makes very extensive use
of Alpha-specific features (microcode, etc.).
As long as the alpha market stays reasonably healthy, I don't think it
makes much business sense to do the port, though.
> >CMUCL is cool and people are hacking on it. I'm pretty
> >optimistic that there is enough interest to improve
> >CMUCL over time.
>
> Is a win32 port being considered?
In regular intervals this topic comes up, either here or on the
implementation mailing lists. But given that few/none of those
seriously working with CMU CL are interested in Win32, a port will
only happen when one of those interested will sit down and do it.
The really hard-stuff will be getting signal-handling and low-level
memory-management working under NT. The rest should be reasonably
"easy"...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> writes:
> Fernando Rodr�guez <·······@must.die> writes:
>> >But Genera is not "the Lisp OS" - just one out of
>> >several and it has a special design - but it is an OS.
>> >Everything in Genera is written in Lisp
>> >> Would it be feasible to port that to Intel (if the source code is
>> available for this purpose)?
> The only thing that seems in any way a feasible approach to me would
> be to port the Alpha Ivory Emulator that underlies Open Genera to a
> more mainstream 64bit platform, once that exists. Of course even that
> seems quite tricky, given that the emulator makes very extensive use
> of Alpha-specific features (microcode, etc.).
But that's only the because they started with really slow Alphas so they had
to milk it for all it's worth. Personally, I'd love to get my hands on the C
version of the emulator. Then let me worry about finding a "fast enough"
processor to make it "usable"! :-)
Mike McDonald
·······@mikemac.com
Mike McDonald wrote in message <····················@typhoon.aracnet.com>...
>In article <··············@orion.bln.pmsf.de>,
> But that's only the because they started with really slow Alphas so they
had
>to milk it for all it's worth. Personally, I'd love to get my hands on the
C
>version of the emulator. Then let me worry about finding a "fast enough"
>processor to make it "usable"! :-)
>
The C version was just a feasability test. When we discovered
it only ran about 20x slower than a real Ivory chip (on a very
early Alpha, mind you), and looked at how poor the generated
code for the C was, we realized that a hand-crafted version
could be made to win. The hand-crafted version ended up
being maybe 7 to 10 percent slower than the real thing on the
same slow Alpha. New Alphas kick butt.
Note that the biggest trick we used in hand-crafting the code
to run fast is a trick that, as far as I know, no modern compilers
do. (In fact, I don't know of any papers that suggest how they
would do it.) The trick is obvious. The Lisp machine instr
set has a bunch of varieties of "the same" instruction which
differ only in where the non-stack argument comes from. If
you do some dynamic profiling of "typical" code, you can
identify which cases are the most important, and arrange
for the most common case to "fall through" from the arg
decoding into the body of the instruction. Now the trick:
you do by-hand register allocation and instr scheduling
*across* the basic block, so that the common case is
guaranteed to have no stalls. We used this trick all over
the place, and its wide use gained probably 200 to 300
percent performance improvement. In fact, when we ran
a DEC tool to do "improved" instruction scheduling, it
disimproved performance by the same few hundred
percent! (The reason this is a "hard" optimization is that,
AFAIK, all compiler optimizations, register allocation and
instruction scheduling algorithms work *on* basic blocks,
*not* across them.)
In article <······················@typhoon.ne.mediaone.net>,
"Scott McKay" <···@mediaone.net> wrote:
> Mike McDonald wrote in message
<····················@typhoon.aracnet.com>...
> >In article <··············@orion.bln.pmsf.de>,
>
> > But that's only the because they started with really slow Alphas so
they
> had
> >to milk it for all it's worth. Personally, I'd love to get my hands
on the
> C
> >version of the emulator. Then let me worry about finding a "fast enough"
> >processor to make it "usable"! :-)
> >
>
> The C version was just a feasability test. When we discovered
> it only ran about 20x slower than a real Ivory chip (on a very
> early Alpha, mind you), and looked at how poor the generated
> code for the C was, we realized that a hand-crafted version
> could be made to win. The hand-crafted version ended up
> being maybe 7 to 10 percent slower than the real thing on the
> same slow Alpha. New Alphas kick butt.
>
> Note that the biggest trick we used in hand-crafting the code
> to run fast is a trick that, as far as I know, no modern compilers
> do. (In fact, I don't know of any papers that suggest how they
> would do it.) The trick is obvious. The Lisp machine instr
> set has a bunch of varieties of "the same" instruction which
> differ only in where the non-stack argument comes from. If
> you do some dynamic profiling of "typical" code, you can
> identify which cases are the most important, and arrange
> for the most common case to "fall through" from the arg
> decoding into the body of the instruction. Now the trick:
> you do by-hand register allocation and instr scheduling
> *across* the basic block, so that the common case is
> guaranteed to have no stalls. We used this trick all over
> the place, and its wide use gained probably 200 to 300
> percent performance improvement. In fact, when we ran
> a DEC tool to do "improved" instruction scheduling, it
> disimproved performance by the same few hundred
> percent! (The reason this is a "hard" optimization is that,
> AFAIK, all compiler optimizations, register allocation and
> instruction scheduling algorithms work *on* basic blocks,
> *not* across them.)
There's a limit to how much you can do, but the GNU C/C++ compiler does
let you place variables in specific registers (you would need a few
#defines to change the registers for various architectures), but I think
this would allow you to do the register scheduling at least.
Instruction scheduling across the basic block is trickier, but a lot of
modern processors have hardware support for instruction scheduling so it
might not hurt you as badly as it did on that old alpha.
Sent via Deja.com
http://www.deja.com/
"Scott McKay" <···@mediaone.net> writes:
> Note that the biggest trick we used in hand-crafting the code
> to run fast is a trick that, as far as I know, no modern compilers
> do. (In fact, I don't know of any papers that suggest how they
> would do it.) The trick is obvious. The Lisp machine instr
> set has a bunch of varieties of "the same" instruction which
> differ only in where the non-stack argument comes from. If
> you do some dynamic profiling of "typical" code, you can
> identify which cases are the most important, and arrange
> for the most common case to "fall through" from the arg
> decoding into the body of the instruction. Now the trick:
> you do by-hand register allocation and instr scheduling
> *across* the basic block, so that the common case is
> guaranteed to have no stalls. We used this trick all over
> the place, and its wide use gained probably 200 to 300
> percent performance improvement. In fact, when we ran
> a DEC tool to do "improved" instruction scheduling, it
> disimproved performance by the same few hundred
> percent! (The reason this is a "hard" optimization is that,
> AFAIK, all compiler optimizations, register allocation and
> instruction scheduling algorithms work *on* basic blocks,
> *not* across them.)
>
Do you mean something like a function with multiple entry points
variant_1: mov *sp, r0
mov *(sp+1), *sp
jump main_label;
variant_2: mov *(globals+offset_constant), *sp
jump main_label
; other variants
main_label: ; do the work assuming arg_1 in r0, arg_2 in *sp
It can be done fairly portably in C. There's a bunch of examples in
the Linux TCP/IP stack. About once a year some good meaning soul comes
up with a patch to eliminate the ugly goto's and replace them by nice
clean constructs.
--
Lieven Marchand <···@wyrd.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
In article <······················@typhoon.ne.mediaone.net>,
"Scott McKay" <···@mediaone.net> writes:
> Mike McDonald wrote in message <····················@typhoon.aracnet.com>...
>>In article <··············@orion.bln.pmsf.de>,
>
>
>> But that's only the because they started with really slow Alphas so they
> had
>>to milk it for all it's worth. Personally, I'd love to get my hands on the
> C
>>version of the emulator. Then let me worry about finding a "fast enough"
>>processor to make it "usable"! :-)
>>
>
>
> The C version was just a feasability test. When we discovered
> it only ran about 20x slower than a real Ivory chip (on a very
> early Alpha, mind you), and looked at how poor the generated
> code for the C was, we realized that a hand-crafted version
> could be made to win. The hand-crafted version ended up
> being maybe 7 to 10 percent slower than the real thing on the
> same slow Alpha. New Alphas kick butt.
I'm not arguing that a C emulator would be as efficient. But given that
processors are at least 20x faster than they were 10 years ago, the chances of
me finding a machine to give similar or better performance of an Ivory is
pretty good. To me, having a LispM environment available on as wide a set of
platforms is more important than absolute speed. (I'm leary of turning my
XL1201 on for fear something irreplacable will break and then I'll be up a
creek. But of course, since I don't turn it on, I'm essentially up that creek
anyway.)
Mike McDonald
·······@mikemac.com
In article <····················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> To me, having a LispM environment available on as wide a set of
> platforms is more important than absolute speed.
I agree wholeheartedly. The problem with the Alpha VLM is that
alpha hardware is both uncommon and expensive. Not as uncommon
as an Ivory (or as expensive when new), but Genera really needs
to run on something a little more standard, because once those
XL1200's start conking out for good I doubt people will be springing
for a brand new Alpha plus a $5000 VLM license. Not on their own
dollar, anyway.
Sent via Deja.com
http://www.deja.com/
Michael Parker <··········@my-deja.com> writes:
> I agree wholeheartedly. The problem with the Alpha VLM is that
> alpha hardware is both uncommon and expensive. Not as uncommon
> as an Ivory (or as expensive when new), but Genera really needs
> to run on something a little more standard, because once those
> XL1200's start conking out for good I doubt people will be springing
> for a brand new Alpha plus a $5000 VLM license. Not on their own
> dollar, anyway.
Uncommon - by PC standards - I'll grant you. Expensive? 533MHz
21164, 128Mb RAM, 15Gb disk, all the frills, no monitor, $2000.
That's not exactly prohibitive. It's not exactly state-of-the-art
these days either, but I bet it runs a lot faster than the 150MHz
machines that were discussed earlier in this thread. And aside from
the CPU and motherboard it uses standard PC parts.
$5000 for Genera is certainly in the same ballpark as $4000 for ACL
How much work would it be to port the host environment from
Tru64/DU/OSF1/whatever-its-called-this-year to Linux? My impression
is that there's an awful lot of Alpha Linux stuff out there.
(In fairness to Symbolics people who may be reading, I'll point out
that this is still an entirely idle question - I doubt I'll be buying
it any time soon no matter what OS it runs on.)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@noetbook.telent.net> writes:
> $5000 for Genera is certainly in the same ballpark as $4000 for ACL
A lot of people seem to over look the fact that the $5000 Open Genera
bundles the Statice object oriented database. I don't think the $4000
version of ACL includes an equivalent database interface (such as
their AllegroStore product). This always makes Open Genera look like
a much better deal that the other Lisp on UNIX offerings to me.
From: Friedrich Dominicus
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <87vgqyq3b2.fsf@frown.here>
Carl Shapiro <········@panix.com> writes:
> Daniel Barlow <···@noetbook.telent.net> writes:
>
> > $5000 for Genera is certainly in the same ballpark as $4000 for ACL
>
> A lot of people seem to over look the fact that the $5000 Open Genera
> bundles the Statice object oriented database. I don't think the $4000
> version of ACL includes an equivalent database interface (such as
> their AllegroStore product). This always makes Open Genera look like
> a much better deal that the other Lisp on UNIX offerings to me.
I agree. There is still a lot of software bundeled with
OpenGenera, e.g text-processing, diverse compilers, servers etc. Now
the only point in it that it's a bit hard to get an AlphaStation (at
least it took here in Germany more then 4 weeks ;().
But if I understand than OpenGenera just runs on Alphas because it's
64-bit Processor. Now it seems that we are getting some more of them
in the future. As someone pointed out before in this thread the task
of porting it to another 64-bit Processor is localized in a few
modules. That seems to be a wortwhile undertaking, maybe this would be
another chance if it would run on "stock" hardware.
Still open if of course the question on how if people are willing to
spend $5000 on Software. Of course not a big deal for larger
companies, but I doubt that one can ask them to go with other software
but from Big Blue and/or Microsoft.
IMHO it might be an interesting move to offer the software for a few
hundred dollar for private use only. And ask the universities to teach
students on that machines too.
However, that are just speculations.
Regards
Friedrich
>>>>> "Friedrich" == Friedrich Dominicus
>>>>> <·····@q-software-solutions.com> writes:
Friedrich> Carl Shapiro <········@panix.com> writes:
>> Daniel Barlow <···@noetbook.telent.net> writes:
>> $5000 for Genera is certainly in the same ballpark as $4000 for ACL
>> A lot of people seem to over look the fact that the $5000 Open
>> Genera bundles the Statice object oriented database. I don't think
>> the $4000 version of ACL includes an equivalent database interface
>> (such as their AllegroStore product). This always makes Open
>> Genera look like a much better deal that the other Lisp on UNIX
>> offerings to me.
Friedrich> I agree. There is still a lot of software bundeled with
Friedrich> OpenGenera, e.g text-processing, diverse compilers, servers
Friedrich> etc. Now the only point in it that it's a bit hard to get
Friedrich> an AlphaStation (at least it took here in Germany more then
Friedrich> 4 weeks ;().
Friedrich> But if I understand than OpenGenera just runs on Alphas
Friedrich> because it's 64-bit Processor. Now it seems that we are
Friedrich> getting some more of them in the future. As someone pointed
Friedrich> out before in this thread the task of porting it to another
Friedrich> 64-bit Processor is localized in a few modules. That seems
Friedrich> to be a wortwhile undertaking, maybe this would be another
Friedrich> chance if it would run on "stock" hardware.
Friedrich> Still open if of course the question on how if people are
Friedrich> willing to spend $5000 on Software. Of course not a big
Friedrich> deal for larger companies, but I doubt that one can ask
Friedrich> them to go with other software but from Big Blue and/or
Friedrich> Microsoft.
There's a _bigger_ problem, which is the question of how "deployable"
Statice-based applications are.
I'm not sure how available it is for deployment with CL on platforms
other than Symbolics. If it is, but at 'prohibitive' license pricing,
then it represents an interesting toy, but will be not usable for
"real applications."
Friedrich> IMHO it might be an interesting move to offer the software
Friedrich> for a few hundred dollar for private use only. And ask the
Friedrich> universities to teach students on that machines too.
Friedrich> However, that are just speculations.
If Symbolics was interested in increasing the size of their market,
there are a number of things they could do. It is not evident that
they are so interested.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www.ntlug.org/~cbbrowne/languages.html
Rules of the Evil Overlord #228. "If the hero claims he wishes to
confess in public or to me personally, I will remind him that a
notarized deposition will serve just as well."
<http://www.eviloverlord.com/>
From: Friedrich Dominicus
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <87u26gxmk9.fsf@frown.here>
> There's a _bigger_ problem, which is the question of how "deployable"
> Statice-based applications are.
>
> I'm not sure how available it is for deployment with CL on platforms
> other than Symbolics. If it is, but at 'prohibitive' license pricing,
> then it represents an interesting toy, but will be not usable for
> "real applications."
You are right, just a "few thoughts extra" if it were not "probibitve"
prices and if it would run on "stock-hardware" it would be "usuable"
even for real applications.
>
> If Symbolics was interested in increasing the size of their market,
> there are a number of things they could do. It is not evident that
> they are so interested.
I do to less about the efforts spend on those Applicatons and/or the
whole Operating System. So they might be interested in increasing
their marke share, but who is willing to pay for it? Wasn't that the
primary reason that Symbolics went bancrupt? There are just a few
possibilites to "change" that.
- either more people buy the software (which I do think is just
wishful thinking, because you do not just need some software but
hardware too)
- they put out the specifications (and implementation) of the Virtual
Machine and ask people to re-implement it on stock hardware.
IMHO both approaches are not highly likely to occur. But I do not no
any alternative which might work. It seems they can live with the
state of the art as it is now. But however I do not think they will
get some more chances. And so one "era" of OSes will end ...
Regards
Friedrich
In article <··············@mail.hex.net>, ········@hex.net wrote:
> Friedrich> Still open if of course the question on how if people are
> Friedrich> willing to spend $5000 on Software. Of course not a big
> Friedrich> deal for larger companies, but I doubt that one can ask
> Friedrich> them to go with other software but from Big Blue and/or
> Friedrich> Microsoft.
>
> There's a _bigger_ problem, which is the question of how "deployable"
> Statice-based applications are.
FYI, the White House site ran under Open Genera and used
Statice.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
| FYI, the White House site ran under Open Genera and used
| Statice.
Ran? Did they switch? If they switched, do you know why?
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
Nothing increases your golf score like witnesses.
In article <··············@qiwi.uncommon-sense.net>, Boris Schaefer
<·····@uncommon-sense.net> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> | FYI, the White House site ran under Open Genera and used
> | Statice.
>
> Ran? Did they switch?
It was not the whole site - just the "Publications Server".
> If they switched, do you know why?
I heard they got a new President, kind of.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Boris Schaefer <·····@uncommon-sense.net> writes:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> | FYI, the White House site ran under Open Genera and used
> | Statice.
>
> Ran? Did they switch? If they switched, do you know why?
New administration. Bush is asserting himself in various ways,
including redecorating the Oral Office and tearing down the
Publications Server.
//Raymond.
--
Raymond Wiker
·············@fast.no
From: Larry J. Elmore
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <3A7B732A.5FCEE0CA@home.com>
Rainer Joswig wrote:
> In article <··············@mail.hex.net>, ········@hex.net wrote:
>
> > Friedrich> Still open if of course the question on how if people are
> > Friedrich> willing to spend $5000 on Software. Of course not a big
> > Friedrich> deal for larger companies, but I doubt that one can ask
> > Friedrich> them to go with other software but from Big Blue and/or
> > Friedrich> Microsoft.
> >
> > There's a _bigger_ problem, which is the question of how "deployable"
> > Statice-based applications are.
>
> FYI, the White House site ran under Open Genera and used
> Statice.
whitehouse.gov or whitehouse.com? :D
I wonder which gets more traffic?
Larry
From: Tim Bradshaw
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <ey3n1c741ul.fsf@cley.com>
* cbbrowne wrote:
> There's a _bigger_ problem, which is the question of how "deployable"
> Statice-based applications are.
> I'm not sure how available it is for deployment with CL on platforms
> other than Symbolics. If it is, but at 'prohibitive' license pricing,
> then it represents an interesting toy, but will be not usable for
> "real applications."
To reopen an old debate, which I can tell I'm going to regret doing.
The deployment cost is likely to be bounded above by $5000, which is
not really a lot compared to the license fees that many kinds of
software involve. Yes, obviously not mass-market software.
--tim
On 28 Jan 2001 23:50:11 -0500, Carl Shapiro <········@panix.com> wrote:
>Daniel Barlow <···@noetbook.telent.net> writes:
>
>> $5000 for Genera is certainly in the same ballpark as $4000 for ACL
>
>A lot of people seem to over look the fact that the $5000 Open Genera
>bundles the Statice object oriented database. I don't think the $4000
>version of ACL includes an equivalent database interface (such as
>their AllegroStore product). This always makes Open Genera look like
>a much better deal that the other Lisp on UNIX offerings to me.
But you can't deploy...
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>, Fernando
Rodr?guez <·······@must.die> wrote:
> On 28 Jan 2001 23:50:11 -0500, Carl Shapiro <········@panix.com> wrote:
>
> >Daniel Barlow <···@noetbook.telent.net> writes:
> >
> >> $5000 for Genera is certainly in the same ballpark as $4000 for ACL
> >
> >A lot of people seem to over look the fact that the $5000 Open Genera
> >bundles the Statice object oriented database. I don't think the $4000
> >version of ACL includes an equivalent database interface (such as
> >their AllegroStore product). This always makes Open Genera look like
> >a much better deal that the other Lisp on UNIX offerings to me.
>
> But you can't deploy...
What do you mean by that?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
On Mon, 29 Jan 2001 10:39:45 +0100, Rainer Joswig
<······@corporate-world.lisp.de> wrote:
>> >A lot of people seem to over look the fact that the $5000 Open Genera
>> >bundles the Statice object oriented database. I don't think the $4000
>> >version of ACL includes an equivalent database interface (such as
>> >their AllegroStore product). This always makes Open Genera look like
>> >a much better deal that the other Lisp on UNIX offerings to me.
>>
>> But you can't deploy...
>
>What do you mean by that?
I'm assuming that to distribute any app you build you'll have to use the Open
Genera emulator on Alpha processors, which seems very restrictive. Unless it
can be easily recompiled (including statice and whatever else you're using)
with other compilers...
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Fernando Rodr�guez wrote in message ...
>On Mon, 29 Jan 2001 10:39:45 +0100, Rainer Joswig
><······@corporate-world.lisp.de> wrote:
>I'm assuming that to distribute any app you build you'll have to use the
Open
>Genera emulator on Alpha processors, which seems very restrictive. Unless
it
>can be easily recompiled (including statice and whatever else you're using)
>with other compilers...
Develop using Genera's still-superior development environment,
and deploy on a different platform. This is pretty straightforward
thanks to X3J13.
From: Tim Bradshaw
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <ey3bssp6fg1.fsf@cley.com>
* Scott McKay wrote:
> Develop using Genera's still-superior development environment,
> and deploy on a different platform. This is pretty straightforward
> thanks to X3J13.
Not if you want statice (which was the thing that made the $5000 look
cheap compared to other commercial Lisps).
--tim
>>>>> "Scott" == Scott McKay <···@mediaone.net> writes:
Scott> Fernando Rodr�guez wrote in message ...
>> On Mon, 29 Jan 2001 10:39:45 +0100, Rainer Joswig
>> <······@corporate-world.lisp.de> wrote:
>> I'm assuming that to distribute any app you build you'll have to
>> use the Open Genera emulator on Alpha processors, which seems very
>> restrictive. Unless it can be easily recompiled (including statice
>> and whatever else you're using) with other compilers...
Scott> Develop using Genera's still-superior development environment,
Scott> and deploy on a different platform. This is pretty
Scott> straightforward thanks to X3J13.
X3J13 doesn't include "statice and whatever else you're using," so
that seems not to be quite so straightforward.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://vip.hex.net/~cbbrowne/lisp.html
As of next Tuesday NCOMPLR will no longer open-code arithmetic statements.
Please update your programs.
From: ······@corporate-world.lisp.de
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <95ajpc$l21$1@nnrp1.deja.com>
In article <··············@mail.hex.net>,
········@hex.net wrote:
> Scott> Develop using Genera's still-superior development environment,
> Scott> and deploy on a different platform. This is pretty
> Scott> straightforward thanks to X3J13.
>
> X3J13 doesn't include "statice and whatever else you're using," so
> that seems not to be quite so straightforward.
That's why people developed stuff like "Extended Common Lisp",
CLIM, Portable Statice, CL-HTTP, ...
Sent via Deja.com
http://www.deja.com/
On Thu, 01 Feb 2001 03:05:20 GMT, ······@corporate-world.lisp.de wrote:
>In article <··············@mail.hex.net>,
> ········@hex.net wrote:
>> Scott> Develop using Genera's still-superior development environment,
>> Scott> and deploy on a different platform. This is pretty
>> Scott> straightforward thanks to X3J13.
>>
>> X3J13 doesn't include "statice and whatever else you're using," so
>> that seems not to be quite so straightforward.
>
>That's why people developed stuff like "Extended Common Lisp",
>CLIM, Portable Statice, CL-HTTP, ...
Portable statice? Could you give some links to it, please? :-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>, Fernando
Rodr?guez <·······@must.die> wrote:
> On Thu, 01 Feb 2001 03:05:20 GMT, ······@corporate-world.lisp.de wrote:
>
> >In article <··············@mail.hex.net>,
> > ········@hex.net wrote:
> >> Scott> Develop using Genera's still-superior development environment,
> >> Scott> and deploy on a different platform. This is pretty
> >> Scott> straightforward thanks to X3J13.
> >>
> >> X3J13 doesn't include "statice and whatever else you're using," so
> >> that seems not to be quite so straightforward.
> >
> >That's why people developed stuff like "Extended Common Lisp",
> >CLIM, Portable Statice, CL-HTTP, ...
>
> Portable statice? Could you give some links to it, please? :-)
Portable Statice has been developed *years* ago for
Lucid Common Lisp and Symbolics Common Lisp. I guess
it won't help you.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
In article <··············@noetbook.telent.net>,
Daniel Barlow <···@noetbook.telent.net> writes:
> Michael Parker <··········@my-deja.com> writes:
>> I agree wholeheartedly. The problem with the Alpha VLM is that
>> alpha hardware is both uncommon and expensive. Not as uncommon
>> as an Ivory (or as expensive when new), but Genera really needs
>> to run on something a little more standard, because once those
>> XL1200's start conking out for good I doubt people will be springing
>> for a brand new Alpha plus a $5000 VLM license. Not on their own
>> dollar, anyway.
>
> Uncommon - by PC standards - I'll grant you. Expensive? 533MHz
> 21164, 128Mb RAM, 15Gb disk, all the frills, no monitor, $2000.
> That's not exactly prohibitive.
Depends on your application. For my application, namely me goofing off, it's
extremely prohibitive! :-)
> $5000 for Genera is certainly in the same ballpark as $4000 for ACL
That too is out of my ballpark. (For a LOT less, I could get one of those
nifty new Mac laptops with MCL. But that's out of my range too. (I am trying
to talk my boss into getting me one.))
> How much work would it be to port the host environment from
> Tru64/DU/OSF1/whatever-its-called-this-year to Linux? My impression
> is that there's an awful lot of Alpha Linux stuff out there.
My understanding is it's very tied to OSF.
> (In fairness to Symbolics people who may be reading, I'll point out
> that this is still an entirely idle question - I doubt I'll be buying
> it any time soon no matter what OS it runs on.)
You mean both of them? Symbolics people that is. :-)
Mike McDonald
·······@mikemac.com
> But that's only the because they started with really slow Alphas so
they had
> to milk it for all it's worth. Personally, I'd love to get my hands on
the C
> version of the emulator. Then let me worry about finding a "fast enough"
> processor to make it "usable"! :-)
I think they started on a 150mhz alpha? From what I remember from
Withington's paper, they wrote a "prototype" emulator in C, then quickly
abandoned it and wrote the VLM in assembler. According to this paper,
the big problems with the C compiler were that it didn't take advantage
of the alpha's dual-issue capability, and they had to rearrange code to
optimize use of the direct-mapped cache.
It certainly seems like both of these issues might be greatly reduced on
a more modern CPU -- we've had nearly a decade of compiler improvements,
plus modern processors have much more hardware support for
multiple-issue, plus bigger set-associative caches. It'd be *really*
interesting to take that prototype VLM and recompile it for ultrasparc
or IA-64 (using Intel's magic compiler). I don't know if the VLM keeps
the tags separate from the 32-bit data, or if it just stores them in the
upper 32-bits of the 64-bit words, but if it keeps them separate then it
might even be possible to compile it on IA32 and still get xl1200+
performance (you might need a ghz processor, but that's not a big deal
nowadays).
Unfortunately, I suspect that Symbolics is in no shape to do anything of
the sort, and I doubt that they would be interested in open-sourcing the
C and Alpha VLMs, even if it meant a wider market for Genera.
It's sad, though, cause those xl1200's aren't gonna last forever, and
Alpha is (obviously) too small a market to keep Symbolics healthy, even
the greatly reduced Symbolics we have today.
Sent via Deja.com
http://www.deja.com/
On Sun, 28 Jan 2001 15:43:30 GMT, Michael Parker <··········@my-deja.com>
wrote:
>Unfortunately, I suspect that Symbolics is in no shape to do anything of
>the sort, and I doubt that they would be interested in open-sourcing the
>C and Alpha VLMs, even if it meant a wider market for Genera.
Why? I mean. why wouldn't they be interested in opensourcing the vlm _if_ it
meant a wider market? =:-O
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>,
Fernando Rodr�guez <·······@must.die> wrote:
> On Sun, 28 Jan 2001 15:43:30 GMT, Michael Parker <··········@my-
deja.com>
> wrote:
>
> >Unfortunately, I suspect that Symbolics is in no shape to do
anything of
> >the sort, and I doubt that they would be interested in open-sourcing
the
> >C and Alpha VLMs, even if it meant a wider market for Genera.
>
> Why? I mean. why wouldn't they be interested in opensourcing the vlm
_if_ it
> meant a wider market? =:-O
Well, they've been slowly withering on the vine for a decade now, while
the open-source movement has taken off, and haven't shown any interest
yet... Their website (when it was up ... it's been awhile) mentioned
some interest in porting the VLM to other processors, but hinted that
they would like a contract for this.
So basically, I was making an assumption that if they were willing,
they would have done so already, with some reinforcement from
Symbolics' historical abhorrence of open software dating back to their
earliest days.
Similarly, my statement that once those old Ivory systems start conking
out that people won't be upgrading to the Alpha VLM is based on the
fact that the Alpha VLM already offers much greater performance and
reliability than the XL1200 at a minor incremental cost, but Dave
Schmidt is still selling Ivory systems at a surprising rate, and lots
of people seem to be holding on to theirs instead of upgrading.
Sent via Deja.com
http://www.deja.com/
In article <··································@4ax.com>,
Fernando Rodr�guez <·······@must.die> writes:
> On Sun, 28 Jan 2001 15:43:30 GMT, Michael Parker <··········@my-deja.com>
> wrote:
>
>
>>Unfortunately, I suspect that Symbolics is in no shape to do anything of
>>the sort, and I doubt that they would be interested in open-sourcing the
>>C and Alpha VLMs, even if it meant a wider market for Genera.
>
> Why? I mean. why wouldn't they be interested in opensourcing the vlm _if_ it
> meant a wider market? =:-O
The whole reason there is a Free Software Foundation is because of
Symbolic's closed source, proprietary mindset. I've seen absolutely no
indication that its changed one iota in the last fifteen years or so.
Mike McDonald
·······@mikemac.com
On Mon, 29 Jan 2001 16:39:49 GMT, ·······@mikemac.com (Mike McDonald) wrote:
> The whole reason there is a Free Software Foundation is because of
>Symbolic's closed source, proprietary mindset. I've seen absolutely no
>indication that its changed one iota in the last fifteen years or so.
Don't you get the sourcecode for almost everything (os, apps) when you buy a
license of opengenera or a LM? O:-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>,
Fernando Rodr�guez <·······@must.die> writes:
> On Mon, 29 Jan 2001 16:39:49 GMT, ·······@mikemac.com (Mike McDonald) wrote:
>
>
>> The whole reason there is a Free Software Foundation is because of
>>Symbolic's closed source, proprietary mindset. I've seen absolutely no
>>indication that its changed one iota in the last fifteen years or so.
>
> Don't you get the sourcecode for almost everything (os, apps) when you buy a
> license of opengenera or a LM? O:-)
Yes, you get a LOT of the source code. And it's all covered by that license!
Just because you have access to some source code doesn't mean you can do
anything you want with it. The Symbolics license has a history of being very
restrictive. (It used to be non transferable. If you wanted to buy a used
machine from someone other than Symbolics, you legally had to pay them a
$10,000 relicensing fee before you could use the software that came on the
machine!
Mike McDonald
·······@mikemac.com
Michael Parker wrote:
>
> > But that's only the because they started with really slow Alphas so
> they had
> > to milk it for all it's worth. Personally, I'd love to get my hands on
> the C
> > version of the emulator. Then let me worry about finding a "fast enough"
> > processor to make it "usable"! :-)
>
> I think they started on a 150mhz alpha? From what I remember from
> Withington's paper, they wrote a "prototype" emulator in C, then quickly
> abandoned it and wrote the VLM in assembler. According to this paper,
> the big problems with the C compiler were that it didn't take advantage
> of the alpha's dual-issue capability, and they had to rearrange code to
> optimize use of the direct-mapped cache.
I asked Tucker, who responded as follows. Please don't ask me to
explain it!
P Tucker Withington wrote:
The cache is less of an issue on modern Alpha's, but we did try to
arrange
the code so that the core of the emulator and the most common
instructions
would stay in the instruction cache and the LispM "stack cache" would
stay
in the data cache. In effect we treated the Alpha instruction set as
microcode and the Alpha instruction cache as a writeable control store.
It
would be interesting to re-tune the emulator for the newer Alpha's (with
quad- or greater instruction parallelism).
There are some dramatic results regarding cache placement and code
performance in mainstream compilers. A profiler/compiler that let you
measure code usage and place it in a cache would address the problems we
had
with the Alpha cache.
If I were trying to write a "portable" version of the emulator, I would
take
the Alpha version and try to translate it back to C. Getting the
semantics
of the LispM instruction set right is _very_ tricky. The C prototype
was a
long way from that. Symbolics still occasionally finds errors in the
emulator (and even in the real machine's microcode, for that matter).
I'm not sure that all of the tricks we exploited in the Alpha
instruction
set (such as fetch and branch hints) could be written in portable C, or
if C
compilers would know how to use those tricks in compiling a portable
program, but it might be that the ridiculous processor speeds we have
today
will mask that.
> It certainly seems like both of these issues might be greatly reduced on
> a more modern CPU -- we've had nearly a decade of compiler improvements,
> plus modern processors have much more hardware support for
> multiple-issue, plus bigger set-associative caches. It'd be *really*
> interesting to take that prototype VLM and recompile it for ultrasparc
> or IA-64 (using Intel's magic compiler). I don't know if the VLM keeps
> the tags separate from the 32-bit data, or if it just stores them in the
> upper 32-bits of the 64-bit words, but if it keeps them separate then it
> might even be possible to compile it on IA32 and still get xl1200+
> performance (you might need a ghz processor, but that's not a big deal
> nowadays).
P Tucker Withington wrote:
The memory implementation is critical to the performance of the
emulator.
Tags and data are stored separately in the emulation of main memory, but
are
passed as 64-bit quantities inside the emulator. Much of the LispM's
instruction set power comes from the various "memory cycles" that it
implements, supporting invisible forwarding and garbage collection. The
memory reference subroutine was the most highly tuned piece of the
emulator.
In a normal cycle, it takes 6 Alpha clocks to emulate 1 LispM memory
fetch
(not including any cache stall).
The key trick used here is to take advantage of the 64-bit address space
to
directly map the LispM main memory emulation. This would not be
possible on
a 32-bit architecture. Having an indirect map (as the C prototype
emulator
did) would kill your performance.
> P Tucker Withington wrote:
>
> There are some dramatic results regarding cache placement and code
> performance in mainstream compilers. A profiler/compiler that let you
> measure code usage and place it in a cache would address the problems we
> had
> with the Alpha cache.
And on machines with set-associative caches, it isn't quite as
big of an issue anyway.
> If I were trying to write a "portable" version of the emulator, I would
> take
> the Alpha version and try to translate it back to C. Getting the
> semantics
> of the LispM instruction set right is _very_ tricky. The C prototype
> was a
> long way from that. Symbolics still occasionally finds errors in the
> emulator (and even in the real machine's microcode, for that matter).
OK. I didn't realize the C VLM was in that rough a state. It sounded
from your article that the C VLM was able to get Genera up and running,
it was just slow.
> I'm not sure that all of the tricks we exploited in the Alpha
> instruction
> set (such as fetch and branch hints) could be written in portable C, or
> if C
> compilers would know how to use those tricks in compiling a portable
> program, but it might be that the ridiculous processor speeds we have
> today
> will mask that.
You can't really add them to the C code, but some processors have
branch-
prediction caches to cope with this. Most modern processors have
non-stalling
data-prefetch instructions. There's no portable way to access these
features
from C, but since this affects efficiency and not correctness, it can be
can be #ifdef'ed in for the architectures that support it.
The Intel IA-64 has predicated execution where you can speculatively
execute
loads or stores in parallel with other operations, and check a bit later
to
see if it actually worked without dependency problems or some exception.
Between its predication system, huge register set, and VLIW-like
instruction
groups, the IA-64 architecture really looks like a dream-come-true for
VM writers.
> The memory implementation is critical to the performance of the
> emulator.
> Tags and data are stored separately in the emulation of main memory, but
> are
> passed as 64-bit quantities inside the emulator. Much of the LispM's
> instruction set power comes from the various "memory cycles" that it
> implements, supporting invisible forwarding and garbage collection. The
> memory reference subroutine was the most highly tuned piece of the
> emulator.
> In a normal cycle, it takes 6 Alpha clocks to emulate 1 LispM memory
> fetch
> (not including any cache stall).
The IA-32 probably wouldn't be that great at this bit, although it does
have a surprisingly effective memory system to help cope with the lack
of general-purpose registers. The IA-64 would really scream at this,
though. There was a paper in last month's ACM Memory Management
proceedings
by some Intel people about some garbage-collector work they did on the
IA-64 JVM. Lots of code and analysis of write and read barriers, etc.
I don't have the paper in front of me, but I think the barriers were
only
one or two cycles in the fast case, depending on which the context.
> The key trick used here is to take advantage of the 64-bit address space
> to
> directly map the LispM main memory emulation. This would not be
> possible on
> a 32-bit architecture. Having an indirect map (as the C prototype
> emulator
> did) would kill your performance.
So it sounds like the IA-32 architecture might not be able to deliver
high
performance, although with speeds that should hit 2ghz this year, it
might
still be able to beat an XL1200 handily.
>>>>> "Pierre" == Pierre R Mai <····@acm.org> writes:
Pierre> Fernando Rodr�guez <·······@must.die> writes:
>> >But Genera is not "the Lisp OS" - just one out of >several and
>> it has a special design - but it is an OS. >Everything in
>> Genera is written in Lisp
>> Would it be feasible to port that to Intel (if the source code is
>> available for this purpose)?
Pierre> The only thing that seems in any way a feasible approach to me
Pierre> would be to port the Alpha Ivory Emulator that underlies Open
Pierre> Genera to a more mainstream 64bit platform, once that exists.
Pierre> Of course even that seems quite tricky, given that the
Pierre> emulator makes very extensive use of Alpha-specific features
Pierre> (microcode, etc.).
Pierre> As long as the alpha market stays reasonably healthy, I don't
Pierre> think it makes much business sense to do the port, though.
Presumably the IA-64 platform would be an "interesting" platform to
port to, assuming it gets around to entering some sort of mainstream.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hyperusa.com/~cbbrowne/advocacy.html
"Huh? Windows was designed to keep the idiots away from Unix so we
could hack in peace. Let's not break that." -- Tom Christiansen
On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
<······@corporate-world.lisp.de> wrote:
> application areas and what not (can you write
> a window manager with CMUCL?).
It has been done:
ECLIPSE
http://www.emi.u-bordeaux.fr/~boninfan/TER
Paolo
From: ······@my-deja.com
Subject: Re: How Close Can We Get A Lisp OS
Date:
Message-ID: <951khl$7t$1@nnrp1.deja.com>
In article <····························@4ax.com>,
Paolo Amoroso <·······@mclink.it> wrote:
> On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
>
> > application areas and what not (can you write
> > a window manager with CMUCL?).
>
> It has been done:
>
> ECLIPSE
> http://www.emi.u-bordeaux.fr/~boninfan/TER
Interesting. Thanks.
I remember seeing the site... I've never used it, though.
Btw.:
Here is a paper that describes the "Rooms" concept of the
Xerox Lisp Machines. "Rooms" is a little bit similar to the
virtual screens you see often on X.
D. A. Henderson, Jr. and S. Card, K. (1986). Rooms: The Use of Multiple
Virtual Workspaces to Reduce Space Contention in a Window-Based
Graphical User Interface. ACM Transactions on Graphics 5(3, July): 211-
241.
http://www.parc.xerox.com/istl/projects/uir/pubs/pdf/UIR-R-1986-01-
Henderson-TOG-Rooms.pdf
Well, actually check out the rest of their papers, too.
http://www.parc.xerox.com/istl/projects/uir/pubs/default.html
AFAIK, quite a lot of the ultra cool 2d or 3d stuff you see
there has been done in Lisp (on SGIs).
Sent via Deja.com
http://www.deja.com/
Paolo Amoroso <·······@mclink.it> writes:
> On Sat, 27 Jan 2001 19:46:38 +0100, Rainer Joswig
> <······@corporate-world.lisp.de> wrote:
>
> > application areas and what not (can you write
> > a window manager with CMUCL?).
>
> It has been done:
>
> ECLIPSE
> http://www.emi.u-bordeaux.fr/~boninfan/TER
>
>
> Paolo
Thank you for that link! I'm running it now. It's rather cute.
Unfortunately, I don't read French so the manuals aren't much help,
but the code is quite small.
Peter