On Fri, Sep 07, 2001 at 11:56:23AM +0100, Christophe Rhodes wrote:
> No, sorry, I'm not announcing the availability of the sparc linux
> port. Some of it compiles, but it's not yet really in a running
> However, I wish to ask for advice on a design matter. There are a lot
> of CPU-specific vops in the CMUCL tree, dependent on :sparc-v7,
> :sparc-v8, :sparc-v9 and :sparc-64 features. Currently, following the
> :pentium thing in compiler/x86/, I've changed calls to
> backend-featurep to #!+ read-macros, but I don't actually think that
> this is right.
> A sparc cmucl has the capability of generating instructions for
> particular CPUs, probably by binding *features* around calls to
> compile and/or compile-file; so
> (let ((*features* (pushnew :sparc-64 *features*)))
> (compile-file "foo"))
> would allow the use of sparc-64-specific instructions in the compiled
> code. However, changing
> ;;; CMUCL
> (:guard (backend-featurep :sparc-64))
> ;;; SBCL
> (:guard #!+:sparc-64 t #!-:sparc-64 nil)
> means that only if :sparc-64 is on the *shebang-features* at SBCL
> _build_ time will this VOP ever be used. (I think, anyway; I can't
> confess that I've traced the code paths to know for certain).
> This strikes me as slightly non-ideal; I think that the compiler ought
> to be able to decide at runtime (that's its runtime and end-user-code
> compile time) what variant of processor to optimize for; similarly for
> x86 should any PIII or MMX VOPs ever get written.
You're right about translating the CMU CL (BACKEND-FEATUREP X) into
#!+ readmacros: it doesn't allow much flexibility for e.g. using a
built-without-:SPARC-64 SBCL to compile code using the :SPARC-64
(Where you write "probably by binding *FEATURES* around calls to
compile" about CMU CL, I think it's actually (BACKEND-FEATURES ..)
that would be tweaked, not the ordinary global *FEATURES*.)
If this kind of dynamic control is necessary in SBCL, it might make
sense to control it with DECLAIM, e.g.
(DECLAIM (SB-EXT:TARGET :SPARC-V8))
(DECLAIM (SB-EXT:TARGET-HAS :SPARC-V7) (SB-EXT:TARGET-HASNT :SPARC-64))
Whatever mechanism you use, I'm not sure how cleanly it will work.
Lisp code tends to include some stuff executed at compile time, so I'd
be afraid of trying to e.g. build V9 code on your SPARC V7 and then
failing when you tried to execute a macro body during compilation.
I haven't looked at the SPARC conditionals, but some of the other
compile time conditionals were a poorly documented mess. If this is
the case for the SPARC conditionals, and you figure out what's going
on, please try to document what you find out. You might also consider
renaming things like :SPARC-V7 to :SPARC>=V7 if they mean "V7 or
William Harold Newman <william.newman@...>
"Sometimes if you have a cappuccino and then try again it will work OK."
-- Dr. Brian Reid, 1992, quoted by mjr
"Sometimes one cappucino isn't enough."
-- mjr = Marcus J. "will do TCP/IP for food" Ranum <mjr@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C