[Sbcl-commits] CVS: sbcl/src/compiler/sparc insts.lisp,1.8,1.8.2.1

[Christophe R. <cr...@us...>]

Update of /cvsroot/sbcl/sbcl/src/compiler/sparc
In directory sc8-pr-cvs1:/tmp/cvs-serv9771/src/compiler/sparc

Modified Files:
      Tag: vector_nil_string_branch
	insts.lisp 
Log Message:
0.8.0.78.vector-nil-string.1:
        As noted with horror between myself and pfdietz on #lisp,
        vectors specialized on NIL are strings.

This patch implements (VECTOR NIL) as subtype of STRING with no
regressions in either our regression test suite or pfdietz' test suite. 

However, this notwithstanding, there are a number of issues that need to
be resolved before this hits HEAD.  (Why would it hit HEAD, you ask?   
Well, it /is/ an ANSI issue, but in this case that would probably just  
merit it an entry in BUGS, were it not for the fact that a Unicode
implementation is likely to have several string representations, so most
of the issues that we're addressing here will have to be dealt with in
any case; the use of (ARRAY NIL) as a "poison pill" to investigate
string routines and the like is probably a good thing.  Note that this
is only a half-way house; while STRING is no longer the same type as
BASE-STRING, which is one portion of the Unicode battle, CHARACTER 
remains equivalent to BASE-CHAR).

Brokennesses:
* STRING= and similar functions may work by accident for (VECTOR NIL 0), 
  but they're unlikely to be robustly working;
* FFI and ALIEN: we need at the very least (a) to ensure that C-STRINGs 
  get turned into a useful string type, not (VECTOR NIL) and (b) to 
  install a conversion routine for the other direction, so that the Lisp 
  string #.(make-array 0 :element-type nil) becomes the C string "";
* Filesystem access and SB-UNIX is completely unaudited.  This may be 
  similar to the above issue;
* SXHASH-SIMPLE-STRING tries to access string elements, and promptly 
  errors on a (VECTOR NIL) with non-zero length.  This also breaks 
  TYPE-OF;
* INTERN currently takes only a BASE-STRING;
* [ probably others.  Should examine Brian Spilsbury's Unicode patch for
    some more gotchas. ]

Suboptimalities:
* 10% slowdown in self-compilation, probably mostly caused by 
  CONCATENATE (not transformed away for general SIMPLE-STRINGs any more)
  and HAIRY-DATA-VECTOR-{REF,SET} (type dispatch unavoidable for the
  latter on STRING-typed objects).  We can mitigate the latter issue by, 
  for STRINGlike types including (VECTOR NIL), having a vector nil type 
  test branching to an array-nil-accessed error clause if true, then 
  retrying the hairy-data-vector optimization;
* throughout the codebase, string and base-string have been 
  interchangeably used for a number of years; we need to look at them 
  all and fix them if necessary.



Index: insts.lisp
===================================================================
RCS file: /cvsroot/sbcl/sbcl/src/compiler/sparc/insts.lisp,v
retrieving revision 1.8
retrieving revision 1.8.2.1
diff -u -d -r1.8 -r1.8.2.1
--- insts.lisp	6 Jun 2003 12:52:53 -0000	1.8
+++ insts.lisp	18 Jun 2003 15:16:07 -0000	1.8.2.1
@@ -120,74 +120,6 @@
       (- val (ash 1 13))
       val))
 
-;;; Oh, come on, this is ridiculous. I'm not going to solve
-;;; bootstrapping issues for a disassembly note. Does this make me
-;;; lazy? Christophe, 2001-09-02. FIXME
-#+nil
-(macrolet
-    ((frob (&rest names)
-       (let ((results (mapcar (lambda (n)
-				  (let ((nn (intern (concatenate 'string (string n)
-								 "-TYPE"))))
-				    `(,(eval nn) ,nn)))
-			      names)))
-	 `(eval-when (:compile-toplevel :load-toplevel :execute)
-	   (def!constant header-word-type-alist
-	     ',results)))))
-  ;; This is the same list as in objdefs.
-  (frob bignum
-	ratio
-	single-float
-	double-float
-	#!+long-float long-float
-	complex
-	complex-single-float
-	complex-double-float
-	#!+long-float complex-long-float
-  
-	simple-array
-	simple-string
-	simple-bit-vector
-	simple-vector
-	simple-array-unsigned-byte-2
-	simple-array-unsigned-byte-4
-	simple-array-unsigned-byte-8
-	simple-array-unsigned-byte-16
-	simple-array-unsigned-byte-32
-	simple-array-signed-byte-8
-	simple-array-signed-byte-16
-	simple-array-signed-byte-30
-	simple-array-signed-byte-32
-	simple-array-single-float
-	simple-array-double-float
-	#!+long-float simple-array-long-float
-	simple-array-complex-single-float
-	simple-array-complex-double-float
-	#!+long-float simple-array-complex-long-float
-	complex-string
-	complex-bit-vector
-	complex-vector
-	complex-array
-  
-	code-header
-	function-header
-	closure-header
-	funcallable-instance-header
-	byte-code-function
-	byte-code-closure
-	closure-function-header
-	#!-gengc return-pc-header
-	#!+gengc forwarding-pointer
-	value-cell-header
-	symbol-header
-	base-char
-	sap
-	unbound-marker
-	weak-pointer
-	instance-header
-	fdefn
-	#!+(or gengc gencgc) scavenger-hook))
-
 ;; Look at the current instruction and see if we can't add some notes
 ;; about what's happening.