ViewVC logotype

Contents of /src/general-info/cmucl.1

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.4 - (hide annotations)
Fri Oct 18 18:41:17 1991 UTC (22 years, 6 months ago) by ram
Branch: MAIN
Changes since 1.3: +2 -2 lines
Changed section beading.
1 ram 1.1 .\" -*- Mode: Text -*-
2     .\"
3     .\" **********************************************************************
4     .\" This code was written as part of the CMU Common Lisp project at
5     .\" Carnegie Mellon University, and has been placed in the public domain.
6     .\" If you want to use this code or any part of CMU Common Lisp, please contact
7     .\" Scott Fahlman or slisp-group@cs.cmu.edu.
8     .\"
9 ram 1.4 .\"$Header: /tiger/var/lib/cvsroots/cmucl/src/general-info/cmucl.1,v 1.4 1991/10/18 18:41:17 ram Exp $
10 ram 1.1 .\"
11     .\" **********************************************************************
12     .\"
13     .\" Man page introduction to CMU CL.
15     .TH CMUCL 1 "October 15, 1991"
16     .AT 3
17     .SH NAME
18     CMU Common Lisp
22     CMU Common Lisp is public domain "industrial strength" Common Lisp programming
23 ram 1.2 environment. Many of the X3j13 changes have been incorporated into CMU CL.
24     Wherever possible, this has been done so as to transparently allow use of
25     either CLtL1 or proposed ANSI CL. Probably the new features most interesting
26     to users are SETF functions, LOOP and the WITH-COMPILATION-UNIT macro.
27 ram 1.1
29 ram 1.1
30 ram 1.2 CMU CL is currently available for Sparcstations and DECstations (pmaxes)
31     running Mach (or OSF/1). We are beta-testing a SunOS SPARC version and an IBM
32     RT Mach version. At least 16 megabytes of memory and 25 megabytes of disk
33     space are recommended. As usual, more is better.
35 ram 1.1 .SH OVERVIEW
36     When compared other Common Lisp implementations (such as Allegro), CMU CL has
37     two broad advantages:
38     .TP 3
39     \--
40 ram 1.3 The new CMU CL compiler (Python) is more sophisticated than other
41 ram 1.1 Common Lisp compilers. It both produces better code and is easier to use.
42     .TP 3
43     \--
44 ram 1.3 The programming environment based on the Hemlock editor is better
45 ram 1.1 integrated than gnu-emacs based environments. (Though you can still use
46     GNU if you want.)
47     .PP
49     CMU CL also has significant non-technical advantages:
50     .TP 3
51     \--
52     It has good local support for CMU users, and is well integrated with the
53     CMU CS environment.
54     .TP 3
55     \--
56     It is public domain, and is freely available to non-CMU sites that aren't
57     able to afford a site-license for a commercial Lisp.
62     The `Advanced Compiler' chapter of the User's manual extensively discusses
63     Python's optimization capabilities (See DOCUMENTATION below.) Here are a few
64     high points:
65     .TP 3
66     \--
67     Good efficiency and type-checking
68     .I at the same time.
69     Compiling code safe gives a 2x speed reduction at worst.
70     .TP 3
71     \--
72     In safe code, type declarations are verified, allowing declarations to
73     be debugged in safe code. When you go to compile unsafe, you know the
74     declarations are right.
75     .TP 3
76     \--
77     Full source level debugging of compiled code, including display of the
78     exact call that got an error.
79     .TP 3
80     \--
81     Good efficiency notes that tell you why an operation can't be open coded
82     or where you are number-consing, and that provide unprecedented source context
83     .TP 3
84     \--
85     Block compilation, partial evaluation, lightweight functions and proper
86     tail-recursion allow low-cost use of function call abstraction.
87     .PP
91     .B Important note:
92     Even debugged programs may contain type errors that remain undetected by
93     other compilers. When compiled with type checking suppressed using the
94     CMU Common Lisp compiler, these type errors may cause said debugged
95     programs to die strangely. If type checking is not suppressed, these
96     programs will die with an explicit type error.
98     The most visible way in which Python differs from previous Common Lisp
99     compilers is that it has a greater knowledge about types and a different
100     approach to type checking. In particular, Python implements type checking
101     which is `eager' and `precise':
102     .TP 3
103     \--
104     Eager in the sense that type checking is done immediately whenever there is
105     a declaration, rather than being delayed until the the value is actually
106     used. For example:
107     .nf
108     (let ((x ...))
109     .br
110     (declare (fixnum x))
111     .br
112     ...)
113     .br
114     .fi
115     Here, the type of the initial value of X must be a FIXNUM or an error will
116     be signalled.
117     .TP 3
118     \--
119     Precise in the sense that the exact type specified is checked. For
120     example, if a variable is declared to be of type (integer 3 7), then the
121     value must always be an integer between 3 and 7.
122     .PP
124     Since Python does more type checking, programs that work fine when compiled
125     with other compilers may get type errors when compiled with Python. It is
126     important to initially compile programs with the default (safe) policy, and
127     then test this version. If a program with an erroneous declaration is compiled
128     with type checking suppressed (due to the SAFETY optimize quality being
129     reduced), then the type error may cause obscure errors or infinite looping.
130     See the section `Getting Existing Programs to Run' (6.6) in the compiler
131     chapter of the user manual.
132 ram 1.2
133     CMU CL adheres to the X3J13 function type cleanup, which means that quoted
134     lambda-lists are not of type FUNCTION, and are no longer directly callable.
135     Use COERCE with the FUNCTION result type.
136 ram 1.1
139     Python does many optimizations that are absent or less general in other
140     Common Lisp compilers:
141     Proper tail recursion, lightweight function call, block compilation,
142     inter-procedural type inference, global flow analysis, dynamic type
143     inference, global register allocation, stack number allocation, control
144     optimization, integer range analysis, enhanced inline expansion, multiple
145     value optimization and source-to-source transforms.
147     Optimization and type-checking are controlled by the OPTIMIZE declaration. The
148     default compilation policy is type-safe.
152     Python is particular good at number crunching:
153     .TP 3
154     \--
155     Good inline coding of float and 32 bit integer operations, with no
156     number consing. This includes all the hardware primitives ROUND,
157     TRUNCATE, COERCE, as well as important library routines such as
158     SCALE-FLOAT and DECODE-FLOAT. Results that don't fit in registers go
159     on a special number stack.
160     .TP 3
161     \--
162     Full support for IEEE single and double (denorms, +-0, etc.)
163     .TP 3
164     \--
165     In block compiled code, numbers are passed as function arguments and
166     return values in registers (and without number consing.)
167     .TP 3
168     \--
169     Calls to library functions (SIN, ...) are optimized to a direct call to
170     the C library routine (with no number consing.) On hardware with
171     direct support for such functions, these operations can easily be
172     open-coded.
173     .TP 3
174     \--
175     Substantially better bignum performance than Allegro (2x-4x). Bignums
176     implemented in lisp using word integers, so you can roll your own.
177     .PP
179     Python's compiler warnings and efficiency notes are especially valuable in
180     numeric code. 50+ pages in the user manual describe Python's capabilities in
181     more detail.
186     In addition to a basic command-line interface, the debugger also has several
187     powerful new features:
188     .TP 3
189     \--
190     The "source" and "vsource" commands print the *precise* original source
191     form responsible for the error or pending function call. It is no longer
192     necessary to guess which call to CAR caused some "not a list" error.
193     .TP 3
194     \--
195     Variables in compiled code can be accessed by name, so the debugger always
196     evaluates forms in the lexical environment of the current frame. This
197     variable access is robust in the presence of compiler optimization ---
198     although higher levels of optimization may make variable values unavailable
199     at some locations in the variable's scope, the debugger always errs on the
200     side of discretion, refusing to display possibly incorrect values.
201     .TP 3
202     \--
203     Integration with the Hemlock editor. In a slave, the "edit" command causes the
204     editor edit the source for the current code location. The editor can also send
205     non-line-mode input to the debugger using C-M-H bindings. Try apropos "debug"
206     in Hemlock.
207     .PP
208     See the debugger chapter in the user manual for more details. We are working
209     on integrating the debugger with Hemlock and X windows.
213     As far as Common Lisp semantics are concerned, there is no interpreter; this is
214     effectively a compile-only implementation. Forms typed to the read-eval-print
215     loop or passed to EVAL are in effect compiled before being run. In
216     implementation, there is an interpreter, but it operates on the internal
217     representation produced by the compiler's font-end.
219     It is not recommended that programs be debugged by running the whole program
220     interpreted, since Python and the debugger eliminate the main reasons for
221     debugging using the interpreter:
222     .TP 3
223     \--
224     Compiled code does much more error checking than interpreted code.
225     .TP 3
226     \--
227     It is as easy to debug compiled code as interpreted code.
228     .PP
230     Note that the debugger does not currently support single-stepping. Also, the
231     interpreter's pre-processing freezes in the macro definitions in effect at the
232     time an interpreted function is defined. Until we implement automatic
233     reprocessing when macros are redefined, it is necessary to re-evaluate the
234     definition of an interpreted function to cause new macro definitions to be
235     noticed.
239     The CMU CL documentation is printed as tech reports, and is available (at CMU)
240     in the document room:
241     .IP "" .2i
242     .br
243     CMU Common Lisp User's Manual
244     .br
245     Hemlock User's Manual
246     .br
247     Hemlock Command Implementor's Manual
248     .PP
250     Non-CMU users may get postscript formatted documentation from the doc/
251     directory in the binary distribution:
252     .TP 10n
253     .BR cmu-user.ps
254     Postscript version of the CMU CL User's Manual (180 pages.)
255     .TP
256     .BR user.ps
257     Postscript version of the Hemlock User's Manual (124 pages.)
258     .TP
259     .BR cim.ps
260     Postscript version of the Hemlock Command Implementor's Manual (96 pages).
261     .TP
262     .BR release-notes.txt
263     Information on the changes between releases.
264     .PP
265     \
267     .SH SUPPORT
269     Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please consult
270     your local CMU CL maintainer or Common Lisp expert to verify that
271     the problem really is a bug before sending to this list.
273     We have insufficient staffing to provide extensive support to people outside of
274     CMU. We are looking for university and industrial affiliates to help us with
275     porting and maintenance for hardware and software that is not widely used at
276     CMU.
280     CMU Common Lisp is a public domain implementation of Common Lisp. Both sources
281     and executables are freely available via anonymous FTP; this software is
282     "as is", and has no warranty of any kind. CMU and the authors assume no
283     responsibility for the consequences of any use of this software. See the
284     README file in the distribution for FTP instructions.
287 ram 1.1
288     Organizationally, CMU Common Lisp is a small, mostly autonomous part within the
289     Mach operating system project. CMU CL is more of a tool development effort
290     than a research project. The project started out as Spice Lisp, which provided
291     a modern Lisp implementation for use in the CMU community. CMU CL has been
292     under continuous development since the early 1980's (concurrent with the Common
293     Lisp standardization effort.)
295     CMU CL is funded by DARPA under CMU's "Research on Parallel Computing"
296     contract. Rather than doing pure research on programming languages and
297     environments, our emphasis has been on developing practical programming tools.
298     Sometimes this has required new technology, but much of the work has been in
299     creating a Common Lisp environment that incorporates state-of-the-art features
300     from existing systems (both Lisp and non-Lisp.)
302     Because sources are freely available, CMU Common Lisp has been ported to
303     experimental hardware, and used as a basis for research in programming language
304     and environment construction.
306     .SH SEE ALSO
307     lisp(1), README
308     .br
309     The ``CMU Common Lisp User's Manual'',
310     .br
311     the ``Hemlock User's Manual'', and
312     .br
313     the ``Hemlock Command Implementor's Manual''

  ViewVC Help
Powered by ViewVC 1.1.5