common-lisp/sbcl.sbcl
1
0
Fork 0
mirror of git://git.code.sf.net/p/sbcl/sbcl synced 2026-09-10 07:26:40 -04:00
Code Issues Actions 8 Packages Projects Releases Wiki Activity
sbcl.sbcl/stems-and-flags.lisp-expr
William Harold Newman befe933802 primarily intending to integrate Colin Walter's O(N) map code and 
fixing BUTLAST (but doing some other stuff too, since achieving the
primary objective involved a lot of inspecting other code):

another revision of MAP stuff, part I:
  * I switched over to code inspired by Colin Walters' O(N) MAP
    code (from the cmucl-imp mailing list 2000 Sep 02) for the
    general non-DEFTRANSFORM case.
  * HIGH-SECURITY-SUPPORT error checking logic goes away, pending
    part II
  * I made some  miscellaneous cleanups of old arity-1 code too.
  * The old MAP-FOR-EFFECT, MAP-TO-LIST, and MAP-TO-SIMPLE macros,
    and the old functions MAP-WITHOUT-ERRORCHECKING, and
    GET-MINIMUM-LENGTH-SEQUENCES go away.
  * The old #+!HIGH-SECURITY length-checking logic goes
    away, to be replaced by stuff in part II.
  * New O(N) functions %MAP-FOR-EFFECT, %MAP-TO-LIST, and
    %MAP-TO-VECTOR are added, and MAP is redefined in terms of them.
  * Add a note pointing out that since MAP-INTO has not been
    rewritten to take advantage of all the new mapping technology,
    it's still slow.
  * Delete no-longer-used ELT-SLICE macro.

another revision of MAP stuff, part II: Peter Van Eynde might go into
a killing frenzy, or at least his ansi-test suite will gnaw SBCL to
death, unless we raise type errors on length mismatches like
  (MAP '(SIMPLE-VECTOR 128) #'+ #(1 2) #(1 1)).
How to do this without clobbering efficiency? More DEFTRANSFORMs, I
think..
  * MAP becomes a wrapper around %MAP. %MAP doesn't do this
    kind of length checking, MAP does. The old DEFUN MAP,
    DEFKNOWN MAP, and DEFTRANSFORM MAP stuff all turns into
    corresponding definitions for %MAP. The wrapper is
    implemented both as a DEFUN MAP and a DEFTRANSFORM MAP.
  * Now make DEFTRANSFORM MAP smarter:
    ** If necessary, check at runtime that ARRAY-DIMENSION
       matches what we pull out of SPECIFIER-TYPE.
    ** No test is done when SPEED > SAFETY.
    ** No test is needed when we can tell at compile time that
       the result type doesn't specify the length of the result.
  * Also add the same kind of ARRAY-DIMENSION/SPECIFIER-TYPE runtime
    check to DEFUN MAP.
  * While I'm at it, since DEFTRANSFORM MAP needs to think hard about
    the type of the result anyway, it might as well declare what
    it's figured out (TRULY-THE) to benefit any code downstream.

Start playing with MAP regression tests. Add tests/assertoid.lisp to
support future regression tests.

Once I started using the QUIT :UNIX-CODE keyword argument in my test
cases, I could see that it isn't very mnemonic. So I changed it to the
more-descriptive name :UNIX-STATUS, leaving the old name supported but
deprecated.

Oops! The old DEFTRANSFORM MAP (now DEFTRANSFORM %MAP) should really
only be done when (>= SPEED SPACE), but it wasn't declared that way.

While looking for an example of a DEFTRANSFORM with &REST arguments
to use as a model for the code in the new DEFTRANSFORM from MAP to
%MAP, I noticed that the problem of taking a list of names and
generating a corresponding list of gensyms is solved in many different
places in the code, in several ways. Also, the related problem of just
creating a list of N gensyms is solved in several places in in the
code. This seems unnecessarily error-prone and wasteful, so I went
looking for such cases and turned them into calls to MAKE-GENSYM-LIST.

another revision of MAP stuff, part III:
  * Search for 'map' in the output from clocc ansi-tests/tests.lisp,
    to check that the new MAP code isn't too obviously broken.
  * Add some regression tests in test/map.impure.lisp.

Oops! The various %MAP-..-ARITY-1 helper functions expect a function
argument, but DEFTRANSFORM MAP can call them passing them a function
name instead.
  * Change the helper functions so that they can handle
    function names as arguments.
  * Define %COERCE-CALLABLE-TO-FUNCTION to help with this. Note that
    this seems to be what %COERCE-NAME-TO-FUNCTION meant long ago,
    judging from DEFTRANSFORM %COERCE-NAME-TO-FUNCTION; so
    appropriate that DEFTRANSFORM for %COERCE-CALLABLE-TO-FUNCTION.
  * Use %COERCE-CALLABLE-TO-FUNCTION elsewhere that expressions
    involving %COERCE-NAME-TO-FUNCTION were used previously.

deleted the old commented-out version of DEFMACRO HANDLER-CASE
(since it was marked "Delete this when the system is stable.":-)

deleted the old commented-out version of GEN-FORMAT-DEF-FORM,
since it was supposed to be safe to do so after sbcl-0.6.4

I removed the apology for not using PRINT-OBJECT everywhere in the
printer from the bugs list in the man page, since it seems to be
rather tricky to construct a test case which exposes the system's
non-PRINT-OBJECT-ness without the test case itself violating the ANSI
spec.

I updated, cleaned up, or removed outright some other outdated or
confusing entries in the BUGS file and from the bugs list on the man
page.

Now that BUTLAST no longer blows up on the new problem cases a la
(BUTLAST NIL -1), I wonder whether I could stop it from blowing
up on the old problem cases a la (BUTLAST NIL)? It looks like
a compiler problem, since the interpreted definition of BUTLAST works,
even though the compiled one doesn't. In fact, it's a declaration
problem, since LENGTH is set to -1 when LIST=NIL, but is declared
as an INDEX. (Of course it's likely also a compiler problem, since
the compiler is supposed to signal type errors for this kind of
declaration error.) I fixed the misdeclaration, and noted the
possible compiler bug in BUGS.

After writing the new revised weird type declarations for the
not-necessarily positive LENGTH, and writing explanatory comments,
  ;; (Despite the name, LENGTH can be -1 when when LIST is an ATOM.)
for each of the cut-and-pasted (LET ((LENGTH ..)) ..) forms in BUTLAST
and NBUTLAST, I said "screw it" -- no, that's not it, I quoted Martin
Fowler and Kent Beck: "If you see the same code structure in more than
one place, you can be sure that your program will be better if you
find a way to unify them," and "It's surprising how often you look at
thickly commented code and notice that the comments are there because
the code is bad." So I just rewrote BUTLAST and NBUTLAST. Hopefully
the new versions will be better-behaved than the old ones.

Now that the INDEX type is used in DEFUN MAKE-GENSYM-LIST, which
belongs in early-extensions.lisp, INDEX should be defined before
early-extensions.lisp, i.e. earlier than its current definition in
early-c.lisp. Move it to early-extensions.lisp. Then to make that
work, since DEF!TYPE is used to define INDEX, defbangtype.lisp needs
to precede early-extensions.lisp in stems-and-flags.lisp-expr; so move
it. Also, INDEX is defined in terms of SB!XC:ARRAY-DIMENSION-LIMIT, so
early-array.lisp needs to move before the new location of
defbangtype.lisp. And then early-vm.lisp needs to move before that, so
I might as well move the rest of the early-vm-ish stuff back too. And
then DEFTYPE is used before deftype.lisp, so I need to change DEFMACRO
DEF!TYPE to DEF!MACRO DEF!TYPE, so I need to move defbangmacro.lisp
before deftype.lisp. (This is like a trip down memory lane to the
endless tweaks and recompiles it took me to find and unravel the
twisted order dependencies which make CMU CL unbootstrappable. Ah,
those were the days..:-)

The DEFTYPEs for INDEX and POSN in early-assem.lisp duplicate
the functionality of the SB-KERNEL:INDEX type.
  * Change uses of the SB-ASSEM::POSN type to uses of the INDEX type.
  * Delete the SB-ASSEM::POSN type and the SB-ASSEM::MAX-POSN constant.
  * Move SB-KERNEL:INDEX into SB-INT, since it's not really
    just a kernel-level thing, but makes sense for implementing
    user-level stuff in SB-INT and SB-EXT and SB-C (and SB-ASSEM).
  * Grep for all '[a-z]:+index[^-a-z]' and rename them (or just
    remove prefixes) to match new SB-INT-ness of INDEX.
  * Make the SB-ASSEM package use the SB-INT package; delete
    the SB-ASSEM::INDEX type and SB-ASSEM::MAX-INDEX constant.
    And since as a rule anything which can see SB-INT deserves
    to see SB-EXT too, make SB-ASSEM use SB-EXT as well.
2000-09-22 14:36:24 +00:00

633 lines
21 KiB
Plaintext
Raw Blame History

;;;; build order
;;;; This software is part of the SBCL system. See the README file for
;;;; more information.
;;;;
;;;; This software is derived from the CMU CL system, which was
;;;; written at Carnegie Mellon University and released into the
;;;; public domain. The software is in the public domain and is
;;;; provided with absolutely no warranty. See the COPYING and CREDITS
;;;; files for more information.
;;; This is a linear ordering of system sources which works both to
;;; compile/load the cross-compiler under the host Common Lisp and to
;;; cross-compile the compiler into the under-construction target
;;; Common Lisp.
;;;
;;; Of course, it'd be very nice to have this be a dependency DAG
;;; instead, so that we could do automated incremental recompilation.
;;; But the dependencies are varied and subtle, and it'd be extremely
;;; difficult to extract them automatically, and it'd be extremely
;;; tedious and error-prone to extract them manually, so we don't
;;; extract them. (It would be nice to fix this someday. The most
;;; feasible approach that I can think of would be to make the
;;; dependencies work on a package level, not an individual file
;;; level. Doing it at the package level would make the granularity
;;; coarse enough that it would probably be pretty easy to maintain
;;; the dependency information manually, and the brittleness of the
;;; package system would help make most violations of the declared
;;; dependencies obvious at build time. -- WHN 20000803
;;;
;;; FIXME: Perhaps now that a significant number of files are built
;;; in warm load instead of cold load, this file should now be called
;;; cold-stems-and-flags.lisp-expr? Also, perhaps this file should move
;;; into the src/cold/ directory?
(
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; miscellaneous
;; This comes early because it's useful for debugging everywhere.
("code/show")
;; This comes early because the cross-compilation host's backquote logic
;; expand into something which can't be executed on the target Lisp (e.g.
;; in CMU CL where it expands into internal functions like BACKQ-LIST), and
;; by replacing the host backquote logic with our own as early as possible,
;; we minimize the chance of any forms referring to host Lisp internal
;; functions leaking into target Lisp code.
("code/backq")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; various DEFSETFs and/or other DEFMACROish things, defined as early as
;; possible so we don't need to fiddle with any subtleties of defining them
;; before any possible use
;; KLUDGE: It would be nice to reimplement most or all of these as
;; functions (possibly inlined functions) so that we wouldn't need to
;; worry so much about forcing them all to be defined before any possible
;; use. It might be pretty tedious, though, working through any
;; transforms and translators and optimizers and so forth to make sure
;; that they can handle the change. -- WHN 19990919
("code/defsetfs")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; cross-compiler-only replacements for stuff which in target Lisp would be
;;; supplied by basic machinery
("code/cross-misc" :not-target)
("code/cross-float" :not-target)
("code/cross-io" :not-target)
("code/cross-sap" :not-target)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; stuff needed early both in cross-compilation host and in target Lisp
("code/uncross")
("code/early-defbangmethod")
("code/defbangtype")
("code/defbangmacro")
;; for various constants e.g. SB!VM:*TARGET-MOST-POSITIVE-FIXNUM* and
;; SB!VM:LOWTAG-BITS, needed by "early-objdef" and others
("compiler/generic/early-vm")
("compiler/generic/early-vm-macs")
("compiler/generic/early-objdef")
("compiler/target/parms")
("code/early-array") ; needs "early-vm" numbers
("code/parse-body") ; on host for PARSE-BODY
("code/parse-defmacro") ; on host for PARSE-DEFMACRO
("code/early-defboot") ; on host for FILE-COMMENT, DO-ANONYMOUS, etc.
("code/boot-extensions") ; on host for COLLECT etc.
("code/early-extensions") ; on host for SYMBOLICATE etc.
("code/late-extensions") ; FIXME: maybe no longer needed on host now that
; we are no longer doing PRINT-HERALD stuff
("compiler/deftype") ; on host for SB!XC:DEFTYPE
("code/early-alieneval") ; for vars needed both at build time and at runtime
("code/specializable-array")
("code/early-cl")
("code/early-load")
;; mostly needed by stuff from comcom, but also used by "x86-vm"
("code/debug-var-io")
("code/cold-init-helper-macros")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; basic machinery for the target Lisp. Note that although most of these
;;; files are flagged :NOT-HOST, a few might not be.
("code/target-defbangmethod" :not-host)
("code/early-print" :not-host)
("code/early-pprint" :not-host)
("code/early-impl" :not-host)
("code/target-extensions" :not-host)
("code/early-defstructs" :not-host) ; gotta-be-first DEFSTRUCTs
("code/defbangstruct")
;; This needs DEF!STRUCT, and is itself needed early so that structure
;; accessors and inline functions defined here can be compiled inline
;; later. (Avoiding full calls not only increases efficiency, but also
;; avoids some cold init issues involving full calls to structure
;; accessors.)
("code/type-class")
("code/lisp-stream" :not-host)
("code/sysmacs" :not-host)
;; "assembly/assemfile" was here in the sequence inherited from
;; CMU CL worldcom.lisp, but also appears later in the sequence
;; inherited from CMU CL comcom.lisp. We shouldn't need two versions,
;; so I've deleted the one here. -- WHN 19990620
;; FIXME: There are lots of "maybe" notes in this file, e.g.
;; "maybe should be :BYTE-COMPILE T". Once the system is stable,
;; look into them.
("code/early-target-error" :not-host) ; maybe should be :BYTE-COMPILE T
;; FIXME: maybe should be called "target-error", with "late-target-error"
;; called "condition"
;; a comment from classic CMU CL:
;; "These guys can supposedly come in any order, but not really.
;; Some are put at the end so that macros don't run interpreted
;; and stuff."
;; Dunno exactly what this meant or whether it still holds. -- WHN 19990803
;; FIXME: more informative and up-to-date comment?
("code/globals" :not-host)
("code/kernel" :not-host)
("code/toplevel" :not-host)
("code/cold-error" :not-host)
("code/fdefinition" :not-host)
;; FIXME: Figure out some way to make the compiler macro for INFO
;; available for compilation of "code/fdefinition".
;; In classic CMU CL, code/type was here. I've since split that into
;; lots of smaller pieces, some of which are here and some of which
;; are handled later in the sequence, when the cross-compiler is
;; built. -- WHN 19990620
("code/target-type" :not-host)
("code/pred" :not-host)
("code/target-alieneval" :not-host)
("code/target-c-call" :not-host)
("code/target-sap" :not-host)
("code/array" :not-host)
("code/target-sxhash" :not-host)
("code/list" :not-host)
("code/seq" :not-host) ; "code/seq" should come after "code/list".
("code/coerce" :not-host)
("code/string" :not-host)
("code/mipsstrops" :not-host)
("code/unix" :not-host)
#!+mach ("code/mach" :not-host)
#!+mach ("code/mach-os" :not-host)
#!+sunos ("code/sunos-os" :not-host)
#!+hpux ("code/hpux-os" :not-host)
#!+osf1 ("code/osf1-os" :not-host)
#!+irix ("code/irix-os" :not-host)
#!+bsd ("code/bsd-os" :not-host)
#!+linux ("code/linux-os" :not-host)
;; KLUDGE: I'd prefer to have this done with a "code/target" softlink
;; instead of a bunch of reader macros. -- WHN 19990308
#!+pmax ("code/pmax-vm" :not-host)
#!+(and sparc svr4) ("code/sparc-svr4-vm" :not-host)
#!+(and sparc (not svr4)) ("code/sparc-vm" :not-host)
#!+rt ("code/rt-vm" :not-host)
#!+hppa ("code/hppa-vm" :not-host)
#!+x86 ("code/x86-vm" :not-host)
#!+alpha ("code/alpha-vm" :not-host)
#!+sgi ("code/sgi-vm" :not-host)
("code/target-signal" :not-host) ; needs OS-CONTEXT-T from x86-vm
("code/symbol" :not-host)
("code/bignum" :not-host)
("code/target-numbers" :not-host)
("code/float-trap" :not-host)
("code/float" :not-host)
("code/irrat" :not-host)
("code/char" :not-host)
("code/target-misc" :not-host)
("code/misc")
#!-gengc ("code/room" :not-host)
#!-gengc ("code/gc" :not-host)
#!-gengc ("code/purify" :not-host)
#!+gengc ("code/gengc" :not-host)
("code/stream" :not-host)
("code/print" :not-host)
("code/pprint" :not-host) ; maybe should be :BYTE-COMPILE T
("code/early-format")
("code/target-format" :not-host) ; maybe should be :BYTE-COMPILE T
("code/defpackage" :not-host)
("code/pp-backq" :not-host) ; maybe should be :BYTE-COMPILE T
("code/error-error" :not-host) ; needs WITH-STANDARD-IO-SYNTAX macro
("code/serve-event" :not-host)
("code/fd-stream" :not-host)
("code/module" :not-host) ; maybe should be :BYTE-COMPILE T
#!+sb-interpreter
("code/eval")
("code/target-eval" :not-host) ; FIXME: uses INFO, wants compiler macro
("code/interr" :not-host)
("code/query" :not-host) ; maybe should be :BYTE-COMPILE T
("code/sort" :not-host)
("code/time" :not-host)
("code/weak" :not-host)
("code/final" :not-host)
#!+mp ("code/multi-proc" :not-host)
("code/setf-funs" :not-host)
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;; compiler (and a few miscellaneous :NOT-HOST files whose
;;; dependencies make it convenient to stick them here)
("compiler/early-c")
("code/numbers")
("code/typedefs")
;; ("code/defbangmacro" was here until sbcl-0.6.7.3.)
("compiler/macros")
("compiler/generic/vm-macs")
;; needed by "compiler/vop"
("compiler/sset")
;; for e.g. BLOCK-ANNOTATION, needed by "compiler/vop"
("compiler/node")
;; for e.g. PRIMITIVE-TYPE, needed by "vmdef"
("compiler/vop")
;; needed by "vm" and "primtype"
("compiler/backend")
;; for e.g. MAX-VOP-TN-REFS, needed by "meta-vmdef"
("compiler/vmdef")
;; needs "backend"
("compiler/target/backend-parms")
;; for INFO and SB!XC:MACRO-FUNCTION, needed by defmacro.lisp
("compiler/globaldb")
("compiler/info-functions")
("code/defmacro")
("code/force-delayed-defbangmacros")
("compiler/late-macros")
;; for e.g. DEF-PRIMITIVE-TYPE, needed by primtype.lisp, and
;; DEFINE-STORAGE-CLASS, needed by target/vm.lisp
("compiler/meta-vmdef")
;; for e.g. DESCRIPTOR-REG, needed by primtype.lisp
("compiler/target/vm")
;; for e.g. SPECIFIER-TYPE, needed by primtype.lisp
("code/early-type")
;; FIXME: Classic CMU CL had SAFETY 2 DEBUG 2 set around the compilation
;; of "code/class". Why?
("code/class")
;; The definitions for CONDITION and CONDITION-CLASS depend on
;; SLOT-CLASS, defined in classes.lisp.
("code/late-target-error" :not-host) ; FIXME: maybe should be :BYTE-COMPILE T
("compiler/generic/primtype")
;; the implementation of the compiler-affecting part of forms like
;; DEFMACRO and DEFTYPE; must be loaded before we can start
;; defining types
("compiler/parse-lambda-list")
;; for DEFSTRUCT ALIEN-TYPE, needed by host-type.lisp
("code/host-alieneval")
;; can't be done until definition of e.g. DEF-ALIEN-TYPE-CLASS in
;; host-alieneval.lisp
("code/host-c-call")
;; SB!XC:DEFTYPE is needed in order to compile late-target-type
;; in the host Common Lisp, and in order to run, it needs
;; %COMPILER-DEFTYPE.
("compiler/compiler-deftype")
;; These appear here in the build sequence because they require
;; * the macro INFO, defined in globaldb.lisp, and
;; * the function PARSE-DEFMACRO, defined in parse-defmacro.lisp,
;; and because they define
;; * the function SPECIFIER-TYPE, which is used in fndb.lisp.
("code/late-type")
("code/deftypes-for-target")
;; The inline definition of TYPEP-TO-LAYOUT here needs inline
;; functions defined in classes.lisp, and is needed in turn by
;; the target version of "code/defstruct".
("code/target-defstruct" :not-host)
;; stuff needed by "code/defstruct"
("code/cross-type" :not-target)
("compiler/generic/vm-type")
;; The DEFSTRUCT machinery needs SB!XC:SUBTYPEP, defined in
;; "code/late-type", and SB!XC:TYPEP, defined in "code/cross-type",
;; and SPECIALIZE-ARRAY-TYPE, defined in "compiler/generic/vm-type".
("code/defstruct")
;; ALIEN-VALUE has to be defined as a class (done by DEFSTRUCT
;; machinery) before we can set its superclasses here.
("code/alien-type")
("compiler/knownfun")
;; needs IR1-ATTRIBUTES macro, defined in knownfun.lisp
("compiler/proclaim")
;; This needs not just the SB!XC:DEFSTRUCT machinery, but also
;; the TYPE= stuff defined in late-type.lisp, and the
;; CHECK-FUNCTION-NAME defined in proclaim.lisp.
("code/force-delayed-defbangstructs")
("code/typep")
("compiler/compiler-error")
("code/type-init")
;; These define target types needed by fndb.lisp.
("code/package")
("code/random")
("code/hash-table")
("code/readtable")
("code/pathname")
("compiler/lexenv")
;; KLUDGE: Much stuff above here is the type system and/or the INFO
;; system, not really the compiler proper. It might be easier to
;; understand the system if those things were split off into packages
;; SB-TYPE and SB-INFO and built in their own sections. -- WHN 20000124
;; In classic CMU CL (re)build order, these were done later, but
;; in building from scratch, these must be loaded before
;; "compiler/generic/objdef" in order to allow forms like
;; (DEFINE-PRIMITIVE-OBJECT (..) (CAR ..) ..) to work.
("compiler/fndb")
("compiler/generic/vm-fndb")
("compiler/generic/objdef")
("compiler/generic/interr")
("compiler/bit-util")
("compiler/early-assem") ; has ASSEMBLY-UNIT-related stuff needed by core.lisp
;; core.lisp contains DEFSTRUCT CORE-OBJECT, and "compiler/main.lisp"
;; does lots of (TYPEP FOO 'CORE-OBJECT), so it's nice to compile this
;; before "compiler/main.lisp" so that those can be coded efficiently
;; (and so that they don't cause lots of annoying compiler warnings
;; about undefined types).
("compiler/generic/core")
("code/load")
("code/fop") ; needs macros from code/host-load.lisp
("compiler/ctype")
("compiler/disassem")
("compiler/assem")
("compiler/trace-table") ; needs EMIT-LABEL macro from compiler/assem.lisp
;; Compiling this file requires fop definitions from code/fop.lisp
;; and trace table definitions from compiler/trace-table.lisp.
("compiler/dump")
("compiler/main") ; needs DEFSTRUCT FASL-FILE from compiler/dump.lisp
("compiler/target-main" :not-host)
("compiler/ir1tran")
("compiler/ir1util")
("compiler/ir1opt")
;; Compiling this file requires the macros SB!ASSEM:EMIT-LABEL and
;; SB!ASSEM:EMIT-POST-IT, defined in assem.lisp.
("compiler/late-vmdef")
("compiler/ir1final")
("compiler/array-tran")
("compiler/seqtran")
("compiler/typetran")
("compiler/generic/vm-typetran")
("compiler/float-tran")
("compiler/saptran")
("compiler/srctran")
("compiler/locall")
("compiler/dfo")
("compiler/checkgen")
("compiler/constraint")
("compiler/envanal")
("compiler/tn")
("compiler/life")
("code/debug-info")
("compiler/debug-dump")
("compiler/generic/utils")
("assembly/assemfile")
("compiler/fixup") ; for DEFSTRUCT FIXUP, used by insts.lisp
("compiler/target/insts")
("compiler/target/macros")
("assembly/target/support")
("compiler/target/move")
("compiler/target/float")
("compiler/target/sap")
("compiler/target/system")
("compiler/target/char")
("compiler/target/memory")
("compiler/target/static-fn")
("compiler/target/arith")
("compiler/target/subprim")
("compiler/target/debug")
("compiler/target/c-call")
("compiler/target/cell")
("compiler/target/values")
("compiler/target/alloc")
("compiler/target/call")
("compiler/target/nlx")
("compiler/target/show")
("compiler/target/array"
;; KLUDGE: Compiling this file raises alarming warnings of the form
;; Argument FOO to VOP CHECK-BOUND has SC restriction
;; DESCRIPTOR-REG which is not allowed by the operand type:
;; (:OR POSITIVE-FIXNUM)
;; This seems not to be something that I broke, but rather a "feature"
;; inherited from classic CMU CL. (Debian cmucl_2.4.8.deb compiling
;; Debian cmucl_2.4.8.tar.gz raises the same warning). Thus, even though
;; these warnings are severe enough that they would ordinarily abort
;; compilation, for now we blithely ignore them and press on to more
;; pressing problems. Someday, though, it would be nice to figure out
;; what the problem is and fix it.. -- WHN 19990323
:ignore-failure-p)
("compiler/target/pred")
("compiler/target/type-vops")
("assembly/target/assem-rtns" :assem)
("assembly/target/array" :assem)
("assembly/target/arith" :assem)
("assembly/target/alloc" :assem)
("compiler/pseudo-vops")
("compiler/aliencomp")
("compiler/ltv")
("compiler/gtn")
("compiler/ltn")
("compiler/stack")
("compiler/control")
("compiler/entry")
("compiler/ir2tran")
;; KLUDGE: This has #!+GENGC things in it which are intended to
;; overwrite code in ir2tran.lisp, so it has to come after ir2tran.lisp.
;;
;; FIXME: Those things should probably be ir2tran.lisp instead, and the
;; things they now overwrite should instead be #!-GENGC so they're never
;; generated in the first place.
("compiler/generic/vm-ir2tran")
("compiler/copyprop")
("compiler/represent")
("compiler/generic/vm-tran")
("compiler/pack")
("compiler/codegen")
("compiler/debug")
#!+sb-dyncount ("compiler/dyncount")
#!+sb-dyncount ("code/dyncount")
;; needed by OPEN-FASL-FILE, which is called by COMPILE-FILE
("code/format-time")
;; needed by various unhappy-path cases in the cross-compiler
("code/error")
;; This wasn't in classic CMU CL "comcom.lisp", but it has some stuff
;; that Python-as-cross-compiler has turned out to need.
("code/macroexpand")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; files which are only needed in the target system, and/or which are
;; only possible in the target system, and which depend in some way
;; (directly or indirectly) on stuff compiled as part of the compiler
("compiler/generic/target-core" :not-host) ; uses stuff from
; "compiler/generic/core"
("code/target-package" :not-host) ; needs "code/package"
("code/target-random" :not-host) ; needs "code/random"
("code/target-hash-table" :not-host) ; needs "code/hash-table"
("code/reader" :not-host) ; needs "code/readtable"
("code/target-pathname" :not-host) ; needs "code/pathname", maybe
; should be :BYTE-COMPILE T
("code/filesys" :not-host) ; needs HOST from "code/pathname",
; maybe should be :BYTE-COMPILE T
("code/save" :not-host) ; uses the definition of PATHNAME
; from "code/pathname"
("code/sharpm" :not-host) ; uses stuff from "code/reader"
;; stuff for byte compilation. This works only in the target system,
;; because fundamental BYTE-FUNCTION-OR-CLOSURE types are implemented
;; as nonportable FUNCALLABLE-INSTANCEs.
("code/byte-types" :not-host)
("compiler/byte-comp")
("compiler/target-byte-comp" :not-host)
;; FIXME: Could byte-interp be moved here? It'd be logical..
;; defines SB!DI:DO-DEBUG-FUNCTION-BLOCKS, needed by target-disassem.lisp
("code/debug-int" :not-host)
;; target-only assemblerish stuff
("compiler/target-disassem" :not-host)
("compiler/target/target-insts" :not-host)
;; the IR1 interpreter (as opposed to the byte code interpreter)
#!+sb-interpreter ("compiler/eval-comp" :not-host)
#!+sb-interpreter ("compiler/eval" :not-host)
("code/debug" :not-host) ; maybe should be :BYTE-COMPILE T
;; These can't be compiled until CONDITION and DEFINE-CONDITION
;; are defined, and they also use SB-DEBUG:*STACK-TOP-HINT*.
("code/parse-defmacro-errors" :not-host)
("code/bit-bash" :not-host) ; needs %NEGATE from assembly/target/arith
("code/byte-interp" :not-host) ; needs *SYSTEM-CONSTANT-CODES* from byte-comp
("code/target-load" :not-host) ; needs specials from code/load.lisp
;; FIXME: Does this really need stuff from compiler/dump.lisp?
("compiler/target-dump" :not-host) ; needs stuff from compiler/dump.lisp
("code/cold-init" :not-host) ; needs (SETF EXTERN-ALIEN) macroexpansion
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; target macros and DECLAIMs installed at build-the-cross-compiler time
;; Declare all target special variables defined by ANSI now, so that
;; we don't have to worry about any of them being bound incorrectly
;; when the compiler processes code which appears before the appropriate
;; DEFVAR or DEFPARAMETER.
("code/cl-specials")
;; fundamental target macros (e.g. CL:DO and CL:DEFUN) and support
;; for them
;;
;; FIXME: Since a lot of this code is just macros, perhaps it should be
;; byte compiled?
("code/defboot")
("code/destructuring-bind")
("code/early-setf")
("code/macros")
("code/loop")
("code/late-setf")
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; other target-code-building stuff which can't be processed until
;; machinery like SB!XC:DEFMACRO exists
("code/late-format") ; needs SB!XC:DEFMACRO
("code/sxhash") ; needs SB!XC:DEFINE-MODIFY-MACRO
("code/signal")
("code/late-defbangmethod"))
Reference in a new issue View git blame Copy permalink