[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 68060 stop gap for MCL
- To: firstname.lastname@example.org
- Subject: Re: 68060 stop gap for MCL
- From: Brad Miller <email@example.com>
- Date: Wed, 16 Mar 1994 19:42:32 -0500
- In-reply-to: <yostCMru2n.97F@netcom.com>
- Newsgroups: comp.lang.lisp.mcl
- Organization: University of Rochester Computer Science Dept
- References: <yostCMru2n.97F@netcom.com>
- Sender: firstname.lastname@example.org (Brad Miller)
Actually I think Macweek mentioned last week Daystar was looking at 060
cards for the ppc, precisely to improve non-native performance.
My larger concern isn't running mcl myself, it's delivering
applications, though, which is still problematic....
a) I don't know the status of features intended for 3.0; Apple demoed,
e.g. multitasking at LUV-93, and I can't deliver in Lisp without it
(because running multiple images is simply too large/clumsy for a
b) It's less than clear delivery images will have acceptable performance
in emulated mode on PPCs (we are talking about fast 68020 performance,
after all). In particular, I suspect running substantial MIDI systems
will simply not work in emulated mode.
c) It's less than clear that ongoing work on MCL 2 will include tracking
the forthcoming ANSI standard. That's a problem for me mostly because I
develop on more than one platform, and have been known to distribute to
users of more than one platform as well (source distribution).
Requiring customers of "inexpensive" software to purchase 060
accelerators seems extreme.... it's one thing to espouse that position
for development systems (and I think it is, indeed, a quite reasonable
stopgap), but not for delivery!
I am looking at CLiCC, however. To the extent CommonLisp0 tracks the
ANSI standard, and CLiCC implements more completely CL0 (the version of
CLiCC I have from January was fairly incomplete, at least wrt things I
use, like Conditions), it could make a reasonable delivery solution. It
does open the possiblility of separately optimizing the resultant C
code, though I expect it to be unreadable by humans :-).
Another alternative is to make your C environment more like Lisp, either
with the abberations used in GNU Emacs, or library functions to supply
hashtables, and replace e.g. malloc() with cons() and automatic gc. :-)
Actually if anyone knows of the existance of such libraries, I'd be glad
to hear of them... they may come in handy for a variety of projects.
Thanks for the post!
Computer Science Dept.
University of Rochester