From: Dmitri H. <hr...@co...> - 2007-05-27 14:35:25
|
Hello! Is it possible to cross-compile CLISP? Well, what I really want is the complete guide to CLISP cross-compilation :) Googled for it, but found little information. Are FAS-files processor-independent? If not, I guess it's not enough to just compile with, say, arm-gcc, it's necessary to tell CLISP to compile FASes also for ARM... Sincerely yours, Dmitri |
From: Sam S. <sd...@gn...> - 2007-05-29 18:35:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dmitri Hrapof wrote: > Is it possible to cross-compile CLISP? what for? historically, it was once possible to compile CLISP with GCL (for extremely weak machines where interpreted CLISP consumed all RAM), but it has been removed years ago (see src/ChangeLog): 2002-09-25 Sam Steingold <sd...@gn...> * compiler.lisp: removed the cross-compilation infrastructure, which was not used for over 10 years! > Are FAS-files processor-independent? yes. Sam. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXHJQPp1Qsf2qnMcRAowsAKCUx0+NlkAikp/hovhthPuJuJ0RnwCgoiRC lgW5SblYbGwun+5Uzbmfq8M= =S55s -----END PGP SIGNATURE----- |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2007-06-08 11:50:56
|
Hi, Sam steingold answered: >> Are FAS-files processor-independent?=20 >yes. This is an important feature to some, and I'm glad to see that Sam still is commited to portability of .fas files. Commiting to portability on user's .fas files has consequences on how CLISP implements some code. My pet example is: (defmacro ext:with-keyboard (&body body) ; in keyboard.lisp `(sys::exec-with-keyboard (lambda () (progn .,body)))) I.e. the body is wrapped in a thunk. WITH-KEYBOARD may not expand itself to some unwind-protect, because the details of the implementation vary across the supported platforms. Note however, that the .fas files that serve to build CLISP's image are not portable. They contain platform- and build-specific code. You are not guaranteed to be able to take e.g. init.fas from MS-Windows and use that on Linux. That implies that in a portability context, you'll need to have your future Zaurus lisp.run compile in interpreted mode all .lisp files that serve to build CLISP's lispinit.mem. That will need more RAM than when you start CLISP with a compiled lispinit.mem, so an emulator with plenty of RAM is a good thing. Some files may work. E.g. macros3.fas presumably, because it looks no different from user code. It does not depend on internals. Same for loop.fas. We simply do not want to specify exactly what file is portable and which is not. Regards, Jorg Hohle |
From: Sam S. <sd...@gn...> - 2007-06-08 13:33:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoehle, Joerg-Cyril wrote: > Commiting to portability on user's .fas files has consequences on how > CLISP implements some code. My pet example is: > (defmacro ext:with-keyboard (&body body) ; in keyboard.lisp > `(sys::exec-with-keyboard (lambda () (progn .,body)))) > I.e. the body is wrapped in a thunk. > WITH-KEYBOARD may not expand itself to some unwind-protect, because the > details of the implementation vary across the supported platforms. > > Note however, that the .fas files that serve to build CLISP's image are > not portable. They contain platform- and build-specific code. You are > not guaranteed to be able to take e.g. init.fas from MS-Windows and use > that on Linux. indeed, but the FILE FORMAT is the same, i.e., if you compile init.lisp or keyboard.lisp on Linux like this: (let ((*features* (cons :win32 (remove :unix *features*)))) (compile-file "init.lisp") (compile-file "keyboard.lisp")) the resulting FAS files should be usable on woe32 (but useless on Linux) > That implies that in a portability context, you'll need to have your > future Zaurus lisp.run compile in interpreted mode all .lisp files that > serve to build CLISP's lispinit.mem. I don't think so. I think all you need to do is to ensure that your *features* is correct for Zaurus when you cross-compile on (say) Linux. Sam. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGaVqNPp1Qsf2qnMcRAoJ7AJoDDm5gtoXFQuB8eVgT6jsj2Ws4rQCgjOr3 wsHQpa6/WvIRHgf3LdqQpAE= =CTXN -----END PGP SIGNATURE----- |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2007-06-22 21:24:45
|
Sam Steingold wrote: >(let ((*features* (cons :win32 (remove :unix *features*)))) >> That implies that in a portability context, you'll need to have your >> future Zaurus lisp.run compile in interpreted mode all .lisp=20 >> files that serve to build CLISP's lispinit.mem. >I don't think so. >I think all you need to do is to ensure that your *features* is correct >for Zaurus when you cross-compile on (say) Linux. Wasn't there a place where even C's sizeof(setjmp_buf) shines through to some Lisp structure? Or where was that? (walking the stack frames?) Regards, Jorg Hohle. |
From: Sam S. <sd...@gn...> - 2007-06-22 21:44:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoehle, Joerg-Cyril wrote: > Sam Steingold wrote: >> (let ((*features* (cons :win32 (remove :unix *features*)))) >>> That implies that in a portability context, you'll need to have your >>> future Zaurus lisp.run compile in interpreted mode all .lisp >>> files that serve to build CLISP's lispinit.mem. >> I don't think so. >> I think all you need to do is to ensure that your *features* is correct >> for Zaurus when you cross-compile on (say) Linux. > > Wasn't there a place where even C's sizeof(setjmp_buf) shines through to > some Lisp structure? Or where was that? (walking the stack frames?) system::*jmpbuf-size* indeed exists, but it is never used. system::*big-endian* is actually used in compiler.lisp, so you will need to set it in addition to *features* before compiling. at any rate, this is getting sufficiently interesting no, so that if the OP does try to do this, he should write a log for inclusion into the manual. it is mentioned in the bytecode spec doc/impbyte.xml though. I guess it is used for interpreting the bytecodes, which are platform independent. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGfEKzPp1Qsf2qnMcRAtOPAJ9Huuiph45CfVU//Sx50dxGevNd4gCfTxeJ Gbfy+l3ph3Kos2dSvcn1Fe0= =0XNn -----END PGP SIGNATURE----- |
From: Dmitri H. <hr...@co...> - 2007-05-30 04:46:22
|
Sam Steingold пишет: >> Is it possible to cross-compile CLISP? >> > what for? In order to put it on a smartphone (OpenMoko). As I understand it, I have two options: either compile it right inside the phone (or inside the emulator), using native gcc; or cross-compile it (--build=i386, --host=arm). There is CLISP package for Zaurus, but it seems to me author had to compile it on the PDA, which is rather awkward IMHO. >> Are FAS-files processor-independent? >> > yes. O, eto uze cto-to! Spasibo za otvet, Dmitri |
From: Sam S. <sd...@gn...> - 2007-05-30 14:25:53
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dmitri Hrapof wrote: > O, eto uze cto-to! Spasibo za otvet, [this is at least something! thanks for answering,] daber anglit! Please write here in English. While the CLISP project was started in Germany (and there are still many German comments and variable names in the code), the official language of the project is English. Using other languages in the mailing lists and patches is actively discouraged because it reduces their usefulness to most of us. If you would like to write something in a "foreign" (== non-English :-)) language (you will often see French and German phrases around here), please provide an English translation so that non-polyglots will not feel excluded (no, a link to babelfish is not good enough :-)). Sam. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXYlYPp1Qsf2qnMcRAoQDAJ4ghR0WI+S6jIx5GpZunB/YatmEegCdF6w8 /EKhbAY+oJQu65OD24R+7cw= =v1hn -----END PGP SIGNATURE----- |
From: Dmitri H. <hr...@co...> - 2007-05-30 07:03:31
|
Konovalov, Vadim Vladimirovich (Vadim)** CTR ** пишет: >> emulator), using native gcc; or cross-compile it >> (--build=i386, --host=arm). >> > Did you mean --target=arm ? --host=i386 > Hm, IMHO '--target=x' means "produce compiler that makes executables for x", '--host=x' means "produce program that is able to run on x" and '--build=x' means "we are building on x". As FAS files are processor-independent and CLISP is practically a virtual machine, we need '--host', not '--target'. Am I wrong? >> O, eto uze cto-to! Spasibo za otvet, >> > Minu so~naraamat on va:ike, sinu so~naraamat on suur! > Ma oskan eesti keelt natukene, hakkame ra:a:gima! > Yn wir? Mae llawer o ieithoedd 'da chi, mae'n dda iawn! Voobse-to Sam znaet russkij :) S uvazeniem, Dmitri |