ViewVC logotype

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

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1.12 - (hide 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 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 pw 1.12 .\"$Header: /tiger/var/lib/cvsroots/cmucl/src/general-info/cmucl.1,v 1.12 1997/07/21 12:22:38 pw Exp $
10 ram 1.1 .\"
11     .\" **********************************************************************
12     .\"
13     .\" Man page introduction to CMU CL.
14     .TH CMUCL 1 "October 15, 1991"
15     .AT 3
16     .SH NAME
17     CMU Common Lisp
21     CMU Common Lisp is public domain "industrial strength" Common Lisp programming
22 ram 1.2 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.
26 ram 1.1
28 ram 1.1
29 ram 1.11 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.
32 ram 1.2
33 ram 1.1 .SH OVERVIEW
34 ram 1.5 When compared other Common Lisp implementations, CMU CL has
35 ram 1.1 two broad advantages:
36     .TP 3
37     \--
38 ram 1.3 The new CMU CL compiler (Python) is more sophisticated than other
39 ram 1.1 Common Lisp compilers. It both produces better code and is easier to use.
40     .TP 3
41     \--
42 ram 1.3 The programming environment based on the Hemlock editor is better
43 ram 1.1 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.
130 ram 1.2
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.
134 ram 1.1
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     \--
173 ram 1.5
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 ram 1.1 .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 ram 1.10 In addition to a Motif-based windowing interface and a basic command-line
187     interface, the debugger also has several powerful new features:
188 ram 1.1 .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 ram 1.10 Compiled code can be stepped, stopping at each control transfer.
204     .TP 3
205     \--
206 ram 1.1 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.
213 ram 1.10
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
231     INTERFACE:*INTERFACE-STYLE* is :GRAPHICS (the default) and the DISPLAY
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.
236 ram 1.1
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 ram 1.7 Non-CMU users may get documentation from the doc/ directory in the binary
277     distribution:
278 ram 1.1 .TP 10n
279 ram 1.7 .BR cmu-user.info
280 ram 1.8 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 ram 1.7 maintainer install this in the info root, or you can use the info
283     ``g(...whatever.../doc/cmu-user.info)'' command.
284     .TP
285 ram 1.9 .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 ram 1.1 .TP
289 ram 1.7 .BR release-notes.txt
290     Information on the changes between releases.
291     .TP
292 ram 1.6 .BR hemlock-user.ps
293 ram 1.1 Postscript version of the Hemlock User's Manual (124 pages.)
294     .TP
295 ram 1.6 .BR hemlock-cim.ps
296 ram 1.1 Postscript version of the Hemlock Command Implementor's Manual (96 pages).
297     .PP
298     \
300     .SH SUPPORT
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 ram 1.11 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.
309 ram 1.1
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.
319 ram 1.1
320 ram 1.11 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/.)
328 ram 1.1
329 ram 1.11 CMU CL was funded by DARPA under CMU's "Research on Parallel Computing"
330 ram 1.1 contract. Rather than doing pure research on programming languages and
331 ram 1.11 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.)
335 ram 1.1
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.
340     .SH SEE ALSO
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