ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.12 - (show annotations)
Mon Jul 21 12:22:38 1997 UTC (16 years, 9 months ago) by pw
Branch: MAIN
CVS Tags: snapshot-2003-10, release-18e-base, remove_negative_zero_not_zero, dynamic-extent-base, LINKAGE_TABLE, PRE_LINKAGE_TABLE, sparc_gencgc_merge, release-18e-pre2, cold-pcl-base, snapshot-2003-11, sparc_gencgc, UNICODE-BASE, release-18e, lisp-executable-base, release-18e-pre1
Branch point for: sparc_gencgc_branch, RELENG_18, dynamic-extent, UNICODE-BRANCH, lisp-executable, release-18e-branch, cold-pcl
Changes since 1.11: +1 -2 lines
Remove blank first page from man pages.
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.12 1997/07/21 12:22:38 pw Exp $
10 .\"
11 .\" **********************************************************************
12 .\"
13 .\" Man page introduction to CMU CL.
14 .TH CMUCL 1 "October 15, 1991"
15 .AT 3
17 CMU Common Lisp
21 CMU Common Lisp is public domain "industrial strength" Common Lisp programming
22 environment. Many of the X3j13 changes have been incorporated into CMU CL.
23 Wherever possible, this has been done so as to transparently allow use of
24 either CLtL1 or proposed ANSI CL. Probably the new features most interesting
25 to users are SETF functions, LOOP and the WITH-COMPILATION-UNIT macro.
29 CMU CL is currently available for a variety of Unix workstations. See the
30 README file for current platforms. At least 16 megabytes of memory and 25
31 megabytes of disk space are recommended. As usual, more is better.
34 When compared other Common Lisp implementations, CMU CL has
35 two broad advantages:
36 .TP 3
37 \--
38 The new CMU CL compiler (Python) is more sophisticated than other
39 Common Lisp compilers. It both produces better code and is easier to use.
40 .TP 3
41 \--
42 The programming environment based on the Hemlock editor is better
43 integrated than gnu-emacs based environments. (Though you can still use
44 GNU if you want.)
45 .PP
47 CMU CL also has significant non-technical advantages:
48 .TP 3
49 \--
50 It has good local support for CMU users, and is well integrated with the
51 CMU CS environment.
52 .TP 3
53 \--
54 It is public domain, and is freely available to non-CMU sites that aren't
55 able to afford a site-license for a commercial Lisp.
60 The `Advanced Compiler' chapter of the User's manual extensively discusses
61 Python's optimization capabilities (See DOCUMENTATION below.) Here are a few
62 high points:
63 .TP 3
64 \--
65 Good efficiency and type-checking
66 .I at the same time.
67 Compiling code safe gives a 2x speed reduction at worst.
68 .TP 3
69 \--
70 In safe code, type declarations are verified, allowing declarations to
71 be debugged in safe code. When you go to compile unsafe, you know the
72 declarations are right.
73 .TP 3
74 \--
75 Full source level debugging of compiled code, including display of the
76 exact call that got an error.
77 .TP 3
78 \--
79 Good efficiency notes that tell you why an operation can't be open coded
80 or where you are number-consing, and that provide unprecedented source context
81 .TP 3
82 \--
83 Block compilation, partial evaluation, lightweight functions and proper
84 tail-recursion allow low-cost use of function call abstraction.
85 .PP
89 .B Important note:
90 Even debugged programs may contain type errors that remain undetected by
91 other compilers. When compiled with type checking suppressed using the
92 CMU Common Lisp compiler, these type errors may cause said debugged
93 programs to die strangely. If type checking is not suppressed, these
94 programs will die with an explicit type error.
96 The most visible way in which Python differs from previous Common Lisp
97 compilers is that it has a greater knowledge about types and a different
98 approach to type checking. In particular, Python implements type checking
99 which is `eager' and `precise':
100 .TP 3
101 \--
102 Eager in the sense that type checking is done immediately whenever there is
103 a declaration, rather than being delayed until the the value is actually
104 used. For example:
105 .nf
106 (let ((x ...))
107 .br
108 (declare (fixnum x))
109 .br
110 ...)
111 .br
112 .fi
113 Here, the type of the initial value of X must be a FIXNUM or an error will
114 be signalled.
115 .TP 3
116 \--
117 Precise in the sense that the exact type specified is checked. For
118 example, if a variable is declared to be of type (integer 3 7), then the
119 value must always be an integer between 3 and 7.
120 .PP
122 Since Python does more type checking, programs that work fine when compiled
123 with other compilers may get type errors when compiled with Python. It is
124 important to initially compile programs with the default (safe) policy, and
125 then test this version. If a program with an erroneous declaration is compiled
126 with type checking suppressed (due to the SAFETY optimize quality being
127 reduced), then the type error may cause obscure errors or infinite looping.
128 See the section `Getting Existing Programs to Run' (6.6) in the compiler
129 chapter of the user manual.
131 CMU CL adheres to the X3J13 function type cleanup, which means that quoted
132 lambda-lists are not of type FUNCTION, and are no longer directly callable.
133 Use COERCE with the FUNCTION result type.
137 Python does many optimizations that are absent or less general in other
138 Common Lisp compilers:
139 Proper tail recursion, lightweight function call, block compilation,
140 inter-procedural type inference, global flow analysis, dynamic type
141 inference, global register allocation, stack number allocation, control
142 optimization, integer range analysis, enhanced inline expansion, multiple
143 value optimization and source-to-source transforms.
145 Optimization and type-checking are controlled by the OPTIMIZE declaration. The
146 default compilation policy is type-safe.
150 Python is particular good at number crunching:
151 .TP 3
152 \--
153 Good inline coding of float and 32 bit integer operations, with no
154 number consing. This includes all the hardware primitives ROUND,
155 TRUNCATE, COERCE, as well as important library routines such as
156 SCALE-FLOAT and DECODE-FLOAT. Results that don't fit in registers go
157 on a special number stack.
158 .TP 3
159 \--
160 Full support for IEEE single and double (denorms, +-0, etc.)
161 .TP 3
162 \--
163 In block compiled code, numbers are passed as function arguments and
164 return values in registers (and without number consing.)
165 .TP 3
166 \--
167 Calls to library functions (SIN, ...) are optimized to a direct call to
168 the C library routine (with no number consing.) On hardware with
169 direct support for such functions, these operations can easily be
170 open-coded.
171 .TP 3
172 \--
174 Substantially better bignum performance than commercial implementations
175 (2x-4x). Bignums implemented in lisp using word integers, so you can roll your
176 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 Motif-based windowing interface and a basic command-line
187 interface, the debugger also has several 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 Compiled code can be stepped, stopping at each control transfer.
204 .TP 3
205 \--
206 Integration with the Hemlock editor. In a slave, the "edit" command causes the
207 editor edit the source for the current code location. The editor can also send
208 non-line-mode input to the debugger using C-M-H bindings. Try apropos "debug"
209 in Hemlock.
210 .PP
211 See the debugger chapter in the user manual for more details. We are working
212 on integrating the debugger with Hemlock and X windows.
216 CMU Common Lisp has an interface to Motif which is functionally similar to
217 CLM, but works better in CMU CL. See:
218 .IP "" .2i
219 .br
220 doc/motif-toolkit.doc
221 .br
222 doc/motif-internals.doc
223 .PP
225 This motif interface has been used to write the inspector and graphical
226 debugger. There is also a Lisp control panel with a simple file management
227 facility, apropos and inspector dialogs, and controls for setting global
228 options.
230 Call INTERFACE:LISP-CONTROL-PANEL to create the control panel. When
232 environment variable is defined, the graphical inspector and debugger will be
233 invoked by INSPECT or when an error is signalled. Possible values are
234 :GRAPHICS and :TTY. If the value is :GRAPHICS, but there is no X display,
235 then we quietly use the TTY interface.
239 As far as Common Lisp semantics are concerned, there is no interpreter; this is
240 effectively a compile-only implementation. Forms typed to the read-eval-print
241 loop or passed to EVAL are in effect compiled before being run. In
242 implementation, there is an interpreter, but it operates on the internal
243 representation produced by the compiler's font-end.
245 It is not recommended that programs be debugged by running the whole program
246 interpreted, since Python and the debugger eliminate the main reasons for
247 debugging using the interpreter:
248 .TP 3
249 \--
250 Compiled code does much more error checking than interpreted code.
251 .TP 3
252 \--
253 It is as easy to debug compiled code as interpreted code.
254 .PP
256 Note that the debugger does not currently support single-stepping. Also, the
257 interpreter's pre-processing freezes in the macro definitions in effect at the
258 time an interpreted function is defined. Until we implement automatic
259 reprocessing when macros are redefined, it is necessary to re-evaluate the
260 definition of an interpreted function to cause new macro definitions to be
261 noticed.
265 The CMU CL documentation is printed as tech reports, and is available (at CMU)
266 in the document room:
267 .IP "" .2i
268 .br
269 CMU Common Lisp User's Manual
270 .br
271 Hemlock User's Manual
272 .br
273 Hemlock Command Implementor's Manual
274 .PP
276 Non-CMU users may get documentation from the doc/ directory in the binary
277 distribution:
278 .TP 10n
279 .BR cmu-user.info
280 CMU CL User's Manual in Gnu Info format. The ``cmu-user.info-<N>'' files
281 are subfiles. You can either have your EMACS
282 maintainer install this in the info root, or you can use the info
283 ``g(...whatever.../doc/cmu-user.info)'' command.
284 .TP
285 .BR cmu-user.ps
286 The CMU CL User's Manual (148 pages) in postscript format. LaTeX source and
287 DVI versions are also available.
288 .TP
289 .BR release-notes.txt
290 Information on the changes between releases.
291 .TP
292 .BR hemlock-user.ps
293 Postscript version of the Hemlock User's Manual (124 pages.)
294 .TP
295 .BR hemlock-cim.ps
296 Postscript version of the Hemlock Command Implementor's Manual (96 pages).
297 .PP
298 \
302 Bug reports should be sent to cmucl-bugs@cs.cmu.edu. Please consult
303 your local CMU CL maintainer or Common Lisp expert to verify that
304 the problem really is a bug before sending to this list.
306 The CMU Common Lisp project is no longer funded, so only minimal support is
307 being done at CMU. There is a net community of \cmucl{} users and maintainers
308 who communicate via comp.lang.lisp and the cmucl-bugs@cs.cmu.edu mailing list.
312 CMU Common Lisp is a public domain implementation of Common Lisp. Both sources
313 and executables are freely available via anonymous FTP; this software is
314 "as is", and has no warranty of any kind. CMU and the authors assume no
315 responsibility for the consequences of any use of this software. See the
316 README file in the distribution for FTP instructions.
320 Organizationally, CMU Common Lisp was a small, mostly autonomous part within
321 the Mach operating system project. The CMU CL project was more of a tool
322 development effort than a research project. The project started out as Spice
323 Lisp, which provided a modern Lisp implementation for use in the CMU community.
324 CMU CL has been under continuous development since the early 1980's (concurrent
325 with the Common Lisp standardization effort.) Most of the CMU Common Lisp
326 implementors are now working on the Gwydion environment for Dylan (see
327 http://legend.gwydion.cs.cmu.edu:8001/gwydion/.)
329 CMU CL was funded by DARPA under CMU's "Research on Parallel Computing"
330 contract. Rather than doing pure research on programming languages and
331 environments, the emphasis was on developing practical programming tools.
332 Sometimes this required new technology, but much of the work was in creating a
333 Common Lisp environment that incorporates state-of-the-art features from
334 existing systems (both Lisp and non-Lisp.)
336 Because sources are freely available, CMU Common Lisp has been ported to
337 experimental hardware, and used as a basis for research in programming language
338 and environment construction.
341 lisp(1), README
342 .br
343 The ``CMU Common Lisp User's Manual'',
344 .br
345 the ``Hemlock User's Manual'', and
346 .br
347 the ``Hemlock Command Implementor's Manual''

  ViewVC Help
Powered by ViewVC 1.1.5