X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=src%2Fcompiler%2Fearly-assem.lisp;h=317b100981e94f0c40b4af4d06d886ac0d0384bc;hb=b83353d9f998e5c0e34604b5593df70c66d2c510;hp=08c5b952f6be964c4e02a4268899b5b33b505f55;hpb=a530bbe337109d898d5b4a001fc8f1afa3b5dc39;p=sbcl.git

diff --git a/src/compiler/early-assem.lisp b/src/compiler/early-assem.lisp
index 08c5b95..317b100 100644
--- a/src/compiler/early-assem.lisp
+++ b/src/compiler/early-assem.lisp
@@ -11,56 +11,41 @@
 
 (in-package "SB!ASSEM")
 
-(sb!int:file-comment
-  "$Header$")
-
-;;; FIXME: It might make sense to use SB!VM:BYTE-FOO values here instead of the
-;;; various ASSEMBLY-UNIT-FOO things. One problem: BYTE is exported from the CL
-;;; package, so ANSI says that we're not supposed to be attaching any new
-;;; meanings to it. Perhaps rename SB!VM:BYTE-FOO to SB!VM:VMBYTE-FOO or
-;;; SB!VM:VM-BYTE-FOO, and then define the SB!VM:VMBYTE or SB!VM:VM-BYTE types?
+;;; FIXME: It might make sense to use SB!VM:BYTE-FOO values here
+;;; instead of the various ASSEMBLY-UNIT-FOO things, and then define a
+;;; BYTE type. One problem: BYTE is exported from the CL package, so
+;;; ANSI says that we're not supposed to be attaching any new meanings
+;;; to it. Perhaps rename SB!VM:BYTE-FOO to SB!VM:VMBYTE-FOO or
+;;; SB!VM:VM-BYTE-FOO, and then define the SB!VM:VMBYTE or
+;;; SB!VM:VM-BYTE types?
 ;;;
 ;;; If this was done, some of this file could go away, and the rest
-;;; could probably be merged back into assem.lisp. (This file was created
-;;; simply in order to move the ASSEMBLY-UNIT-related definitions before
-;;; compiler/generic/core.lisp in the build sequence.
-
-;;; ASSEMBLY-UNIT-BITS -- the number of bits in the minimum assembly unit,
-;;; (also refered to as a ``byte''). Hopefully, different instruction
-;;; sets won't require changing this.
-(defconstant assembly-unit-bits 8)
-(defconstant assembly-unit-mask (1- (ash 1 assembly-unit-bits)))
-
-(deftype assembly-unit ()
+;;; could probably be merged back into assem.lisp. (This file was
+;;; created simply in order to move the ASSEMBLY-UNIT-related
+;;; definitions before compiler/generic/core.lisp in the build
+;;; sequence.)
+
+;;; ASSEMBLY-UNIT-BITS -- the number of bits in the minimum assembly
+;;; unit, (also referred to as a ``byte''). Hopefully, different
+;;; instruction sets won't require changing this.
+(def!constant assembly-unit-bits 8)
+(def!constant assembly-unit-mask (1- (ash 1 assembly-unit-bits)))
+
+(def!type assembly-unit ()
   `(unsigned-byte ,assembly-unit-bits))
 
 ;;; Some functions which accept assembly units can meaningfully accept
 ;;; signed values with the same number of bits and silently munge them
-;;; into appropriate unsigned values. (This is handy behavior e.g. when
-;;; assembling branch instructions on the X86.)
-(deftype possibly-signed-assembly-unit ()
+;;; into appropriate unsigned values. (This is handy behavior e.g.
+;;; when assembling branch instructions on the X86.)
+(def!type possibly-signed-assembly-unit ()
   `(or assembly-unit
        (signed-byte ,assembly-unit-bits)))
 
-;;; the maximum alignment we can guarantee given the object
-;;; format. If the loader only loads objects 8-byte aligned, we can't do
-;;; any better then that ourselves.
-(defconstant max-alignment 3)
+;;; the maximum alignment we can guarantee given the object format. If
+;;; the loader only loads objects 8-byte aligned, we can't do any
+;;; better then that ourselves.
+(def!constant max-alignment sb!vm:n-lowtag-bits)
 
-(deftype alignment ()
+(def!type alignment ()
   `(integer 0 ,max-alignment))
-
-;;; the maximum an index will ever become. Well, actually,
-;;; just a bound on it so we can define a type. There is no real hard
-;;; limit on indexes, but we will run out of memory sometime.
-(defconstant max-index (1- most-positive-fixnum))
-
-(deftype index ()
-  `(integer 0 ,max-index))
-
-;;; like MAX-INDEX, except for positions
-(defconstant max-posn (1- most-positive-fixnum))
-
-(deftype posn ()
-  `(integer 0 ,max-posn))
-