X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;ds=sidebyside;f=doc%2Fintro.sgml;h=0c4c1ee428ae54f2af48cf6cbb65b922a65cbd3f;hb=1462adfb42f8eceade5a5493d5ab91ee7838d423;hp=704532f48daf87a7155f175e84c80004da948361;hpb=64a50ee0d70f2e87f3d284d1c7a48a2e0762ea90;p=sbcl.git diff --git a/doc/intro.sgml b/doc/intro.sgml index 704532f..0c4c1ee 100644 --- a/doc/intro.sgml +++ b/doc/intro.sgml @@ -43,7 +43,6 @@ but need to learn about Lisp, three books stand out. you'll see in most OO systems, and there are a number of lesser differences as well. This book tends to help with the culture shock. - @@ -82,7 +81,7 @@ other &SBCL;-specific information is available: at their command prompts. The extensions for functions which don't have their own command prompt (like trace does) are described in their documentation strings, - unless your &SBCL was compiled with an option not + unless your &SBCL; was compiled with an option not to include documentation strings, in which case the doc strings are only readable in the source code. Some low-level information describing the @@ -107,9 +106,9 @@ known bugs, known performance problems, and missing extensions are likely to be fixed, tuned, or added. &SBCL; is descended from &CMUCL;, which is itself descended from -Spice Lisp. Early implementations for the Mach operating system on the -IBM RT, back in the 1980s. Design decisions from that time are still -reflected in the current implementation: +Spice Lisp, including early implementations for the Mach operating +system on the IBM RT, back in the 1980s. Design decisions from that +time are still reflected in the current implementation: The system expects to be loaded into a fixed-at-compile-time location in virtual memory, and also expects @@ -122,7 +121,8 @@ reflected in the current implementation: A word is a 32-bit quantity. The system has been ported to many processor architectures without altering this basic principle. Some hacks allow the system to run on the Alpha - chip (a 64-bit architecture) but the assumption that a word is + chip (a 64-bit architecture) but even there 32-bit words are + used. The assumption that a word is 32 bits wide is implicit in hundreds of places in the system. The system is implemented as a C program which is @@ -160,8 +160,8 @@ debugging) do not work particularly well there. &SBCL; should be able to improve in these areas (and has already improved in some other areas), but it takes a while. -The &SBCL; GC, like the GC on the X86 port of &CMUCL;, is -conservative. This means that it doesn't maintain a +On the x86, &SBCL; like the X86 port of &CMUCL;, uses a +conservative GC. This means that it doesn't maintain a strict separation between tagged and untagged data, instead treating some untagged data (e.g. raw floating point numbers) as possibly-tagged data and so not collecting any Lisp objects that they @@ -182,15 +182,16 @@ running system with new versions. This quasi-build procedure can cause various bizarre bootstrapping hangups, especially when a major change is made to the system. It also makes the connection between the current source code and the current executable more tenuous than in -any other software system I'm aware of -- it's easy to accidentally +other software systems -- it's easy to accidentally build a &CMUCL; system containing characteristics not reflected in the current version of the source code. Other major changes since the fork from &CMUCL; include &SBCL; has dropped support for many &CMUCL; extensions, - (e.g. remote procedure call, Unix system interface, and X11 - interface). + (e.g. IP networking, remote procedure call, Unix system interface, and X11 + interface). Some of these are now available as contributed or + third-party modules. &SBCL; has deleted or deprecated some nonstandard features and code complexity which helped efficiency at the price of maintainability. For example, the