/[cmucl]/src/general-info/cmucl.1
ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.4 - (show 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 .\" -*- 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 .\"$Header: /tiger/var/lib/cvsroots/cmucl/src/general-info/cmucl.1,v 1.4 1991/10/18 18:41:17 ram Exp $
10 .\"
11 .\" **********************************************************************
12 .\"
13 .\" Man page introduction to CMU CL.
14
15 .TH CMUCL 1 "October 15, 1991"
16 .AT 3
17 .SH NAME
18 CMU Common Lisp
19
20 .SH DESCRIPTION
21
22 CMU Common Lisp is public domain "industrial strength" Common Lisp programming
23 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
28 .SH HARDWARE REQUIREMENTS
29
30 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.
34
35 .SH OVERVIEW
36 When compared other Common Lisp implementations (such as Allegro), CMU CL has
37 two broad advantages:
38 .TP 3
39 \--
40 The new CMU CL compiler (Python) is more sophisticated than other
41 Common Lisp compilers. It both produces better code and is easier to use.
42 .TP 3
43 \--
44 The programming environment based on the Hemlock editor is better
45 integrated than gnu-emacs based environments. (Though you can still use
46 GNU if you want.)
47 .PP
48
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.
58
59
60 .SH COMPILER FEATURES
61
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
88
89 .SH TYPE SUPPORT
90
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.
97
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
123
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
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
137 .SH OPTIMIZATION
138
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.
146
147 Optimization and type-checking are controlled by the OPTIMIZE declaration. The
148 default compilation policy is type-safe.
149
150 .SH NUMERIC SUPPORT
151
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
178
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.
182
183
184 .SH THE DEBUGGER
185
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.
210
211 .SH THE INTERPRETER
212
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.
218
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
229
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.
236
237 .SH DOCUMENTATION
238
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
249
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 \
266
267 .SH SUPPORT
268
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.
272
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.
277
278 .SH DISTRIBUTION
279
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.
285
286 .SH ABOUT THE CMU COMMON LISP PROJECT
287
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.)
294
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.)
301
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.
305
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