Re: CMUCL 18c building on tru64 5.1
Fausto Saporito <[email protected]> Wed, 3 Sep 2014 08:29:39 +0200
| Newsgroups | gmane.lisp.cmucl.general |
|---|---|
| Message-ID | <CAF1zXh=+Vxjx74X1wBpzg6CpGiVqRhD79N3G3irjeAgcV57bNA@mail.gmail.com> |
Hello Ray, I started with 19d, but I have this strange error: ; Error: (during macroexpansion) ; ; Error in function META-SC-OR-LOSE: ; DOUBLE-DOUBLE-REG is not a defined storage class. ; ; ; Error: (during macroexpansion) ; ; Error in function META-SC-OR-LOSE: ; COMPLEX-DOUBLE-DOUBLE-REG is not a defined storage class. but in 19d there shouldn't be support for DOUBLE-DOUBLE ... correct ? I'm using 19d binaries to cross-build 19d 2014-09-03 4:17 GMT+02:00 Raymond Toy <[email protected]>: > > > > On Tue, Sep 2, 2014 at 4:53 PM, Fausto Saporito <[email protected]> > wrote: >> >> Hello Raymond, >> >> thanks for these hints about cross.lisp >> I put in the proper section the unwanted feature. >> >> So, if I force the redefinition of those symbols at the end of >> alpha-cross compiling phase, alpha-target starts but I noticed this >> error among the others: >> >> ; File: /home/fausap/CMUCL/git-ver/cmucl/src/code/lispinit.lisp >> >> ; In: DEFUN SLEEP >> >> ; (ERROR 'SIMPLE-TYPE-ERROR >> ; :FORMAT-CONTROL "Invalid argument to SLEEP: ~S.~%~ >> ; Must be a non-negative, non-complex number." >> ; :FORMAT-ARGUMENTS ...) >> ; Note: Deleting unreachable code. >> ; >> >> DOUBLE-DOUBLE-FLOAT fell through ECASE expression. >> Wanted one of (REAL FLOAT OR SINGLE-FLOAT DOUBLE-FLOAT RATIONAL INTEGER). >> >> it's very strange... I disabled double-double... why I have this error ? > > > I think it's a mismatch between what the cross compiler has and what the > host compiler has. I've never figured this out. > > So, I think it's best to start with a lisp without double-double support. > > Support for double-double was apparently done by 19e, so your best bet is to > do a checkout from 19d. I think everything that you've done up to now still > applies. > > Once that is done, we can consider adding double-double for alpha. It's > relatively easy, but you'll have to write a bunch of vops. They can probably > be copied almost verbatim from the sparc or ppc ports with small changes in > the actual instructions. > >> >> This is my features list in cross.lisp (I removed extern-alien-name, >> fixup, etc... I don't know what they are doing... so maybe I can put >> back later) >> >> ;;; Cross-compile script to build a alpha core using x86 as the >> ;;; compiling system. This needs work! >> >> (in-package :cl-user) >> >> ;;; Rename the X86 package and backend so that new-backend does the >> ;;; right thing. >> (rename-package "X86" "OLD-X86" '("OLD-VM")) >> (setf (c:backend-name c:*native-backend*) "OLD-X86") >> >> (c::new-backend "ALPHA" >> ;; Features to add here >> '(:alpha >> :relative-package-names ; Relative package names from >> Allegro >> :conservative-float-type >> :hash-new >> :random-mt19937 ; MT-19937 generator >> :cmu ; Announce this is CMUCL >> :cmu20 :cmu20b ; Current version identifier >> :osf1 >> :bsd >> :unix >> ) >> ;; Features to remove from current *features* here >> '(:sparc-v8 :sparc-v7 :sparc-v9 :sparc >> ;; Other architectures we aren't using. Particularly important >> ;; to get rid of sse2 and x87 so we don't accidentally try to >> ;; compile the x87/sse2 float support on sparc, which won't work. >> :x86 :x86-bootstrap :sse2 :x87 :i486 >> :mips :complex-fp-vops >> ;; Really old stuff that should have been removed long ago. >> :propagate-fun-type :propagate-float-type :constrain-float-type >> :double-double >> :linkage-table >> :stack-checking ; Throw error if we run out of >> stack >> :heap-overflow-check ; Throw error if we run out of >> ; heap (This requires gencgc!) >> :gencgc ; Generational GC >> :modular-arith ; Modular arithmetic >> :executable >> ;; Other OSes were not using >> :openbsd :freebsd :glibc2 :linux :mach-o :darwin :sunos :svr4 >> :solaris :sun4 >> :pentium >> :long-float >> :new-random >> :small >> :mp)) > > > One last thing: remove :alien-callback too. Alpha doesn't support that. > > Hopefully this will get us farther along.... > > -- > Ray > > _______________________________________________ cmucl-help mailing list [email protected] http://lists.zs64.net/mailman/listinfo/cmucl-help