ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.6 - (hide annotations)
Mon Jan 27 09:25:23 1992 UTC (22 years, 2 months ago) by ram
Branch: MAIN
Changes since 1.5: +3 -3 lines
Prefix Hemlock doc names with "hemlock-".
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.6 .\"$Header: /tiger/var/lib/cvsroots/cmucl/src/general-info/cmucl.1,v 1.6 1992/01/27 09:25:23 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 ram 1.5 When compared other Common Lisp implementations, CMU CL has
37 ram 1.1 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 ram 1.5
176     Substantially better bignum performance than commercial implementations
177     (2x-4x). Bignums implemented in lisp using word integers, so you can roll your
178     own.
179 ram 1.1 .PP
181     Python's compiler warnings and efficiency notes are especially valuable in
182     numeric code. 50+ pages in the user manual describe Python's capabilities in
183     more detail.
188     In addition to a basic command-line interface, the debugger also has several
189     powerful new features:
190     .TP 3
191     \--
192     The "source" and "vsource" commands print the *precise* original source
193     form responsible for the error or pending function call. It is no longer
194     necessary to guess which call to CAR caused some "not a list" error.
195     .TP 3
196     \--
197     Variables in compiled code can be accessed by name, so the debugger always
198     evaluates forms in the lexical environment of the current frame. This
199     variable access is robust in the presence of compiler optimization ---
200     although higher levels of optimization may make variable values unavailable
201     at some locations in the variable's scope, the debugger always errs on the
202     side of discretion, refusing to display possibly incorrect values.
203     .TP 3
204     \--
205     Integration with the Hemlock editor. In a slave, the "edit" command causes the
206     editor edit the source for the current code location. The editor can also send
207     non-line-mode input to the debugger using C-M-H bindings. Try apropos "debug"
208     in Hemlock.
209     .PP
210     See the debugger chapter in the user manual for more details. We are working
211     on integrating the debugger with Hemlock and X windows.
215     As far as Common Lisp semantics are concerned, there is no interpreter; this is
216     effectively a compile-only implementation. Forms typed to the read-eval-print
217     loop or passed to EVAL are in effect compiled before being run. In
218     implementation, there is an interpreter, but it operates on the internal
219     representation produced by the compiler's font-end.
221     It is not recommended that programs be debugged by running the whole program
222     interpreted, since Python and the debugger eliminate the main reasons for
223     debugging using the interpreter:
224     .TP 3
225     \--
226     Compiled code does much more error checking than interpreted code.
227     .TP 3
228     \--
229     It is as easy to debug compiled code as interpreted code.
230     .PP
232     Note that the debugger does not currently support single-stepping. Also, the
233     interpreter's pre-processing freezes in the macro definitions in effect at the
234     time an interpreted function is defined. Until we implement automatic
235     reprocessing when macros are redefined, it is necessary to re-evaluate the
236     definition of an interpreted function to cause new macro definitions to be
237     noticed.
241     The CMU CL documentation is printed as tech reports, and is available (at CMU)
242     in the document room:
243     .IP "" .2i
244     .br
245     CMU Common Lisp User's Manual
246     .br
247     Hemlock User's Manual
248     .br
249     Hemlock Command Implementor's Manual
250     .PP
252     Non-CMU users may get postscript formatted documentation from the doc/
253     directory in the binary distribution:
254     .TP 10n
255     .BR cmu-user.ps
256     Postscript version of the CMU CL User's Manual (180 pages.)
257     .TP
258 ram 1.6 .BR hemlock-user.ps
259 ram 1.1 Postscript version of the Hemlock User's Manual (124 pages.)
260     .TP
261 ram 1.6 .BR hemlock-cim.ps
262 ram 1.1 Postscript version of the Hemlock Command Implementor's Manual (96 pages).
263     .TP
264     .BR release-notes.txt
265     Information on the changes between releases.
266     .PP
267     \
269     .SH SUPPORT
271     Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please consult
272     your local CMU CL maintainer or Common Lisp expert to verify that
273     the problem really is a bug before sending to this list.
275     We have insufficient staffing to provide extensive support to people outside of
276     CMU. We are looking for university and industrial affiliates to help us with
277     porting and maintenance for hardware and software that is not widely used at
278     CMU.
282     CMU Common Lisp is a public domain implementation of Common Lisp. Both sources
283     and executables are freely available via anonymous FTP; this software is
284     "as is", and has no warranty of any kind. CMU and the authors assume no
285     responsibility for the consequences of any use of this software. See the
286     README file in the distribution for FTP instructions.
289 ram 1.1
290     Organizationally, CMU Common Lisp is a small, mostly autonomous part within the
291     Mach operating system project. CMU CL is more of a tool development effort
292     than a research project. The project started out as Spice Lisp, which provided
293     a modern Lisp implementation for use in the CMU community. CMU CL has been
294     under continuous development since the early 1980's (concurrent with the Common
295     Lisp standardization effort.)
297     CMU CL is funded by DARPA under CMU's "Research on Parallel Computing"
298     contract. Rather than doing pure research on programming languages and
299     environments, our emphasis has been on developing practical programming tools.
300     Sometimes this has required new technology, but much of the work has been in
301     creating a Common Lisp environment that incorporates state-of-the-art features
302     from existing systems (both Lisp and non-Lisp.)
304     Because sources are freely available, CMU Common Lisp has been ported to
305     experimental hardware, and used as a basis for research in programming language
306     and environment construction.
308     .SH SEE ALSO
309     lisp(1), README
310     .br
311     The ``CMU Common Lisp User's Manual'',
312     .br
313     the ``Hemlock User's Manual'', and
314     .br
315     the ``Hemlock Command Implementor's Manual''

  ViewVC Help
Powered by ViewVC 1.1.5