giant@lindy.Stanford.EDU (Buc Richards) (02/12/90)
KCL (Kyoto Common Lisp) translates programs from Lisp to C and then
compiles the C to generate compiled programs. Is the C code generated
complete? Can the intermediate C code be compiled on another machine,
say a 386 machine, and work? Or does the code require the KCL
environment?
Thanks.
Buc Richards @ @
Supercomputer Support Staff >
Stanford University -verket@venice.SEDD.TRW.COM (Paul Verket) (02/13/90)
From article <7993@lindy.Stanford.EDU>(Buc Richards): > > KCL (Kyoto Common Lisp) translates programs from Lisp to C and then > compiles the C to generate compiled programs. Is the C code generated > complete? No it's not complete. The C code is compiled into a .o which is then linked (by KCL) into the KCL image. Paul Verket
jeff@aiai.ed.ac.uk (Jeff Dalton) (02/13/90)
In article <7993@lindy.Stanford.EDU> giant@lindy.Stanford.EDU (Buc Richards) writes: > >KCL (Kyoto Common Lisp) translates programs from Lisp to C and then >compiles the C to generate compiled programs. >Is the C code generated complete? I'm not quite sure what you mean. It can be compiled by the C compiler. But it's a bunch of procedure definitions, not a complete program. >Can the intermediate C code be compiled on another machine, >say a 386 machine, and work? The intermediate code is fairly portable, so it will probably compile. >Or does the code require the KCL environment? It calls procedures that are part of the KCL system and it expects to be loaded into a running KCL. It would not be too hard to hard to link it together with the files that make up KCL instead. If you wanted to convert KCL into a library and have the compiler compile files that had to be linked with that library, it would probably be possible to do that. But that isn't how it works now. I would be surprised if any Lisp -> C generated C code that didn't even have to be linked with a library of procedures for manipulating Lisp data structures. -- Jeff
utility@quiche.cs.mcgill.ca (Ronald BODKIN) (02/13/90)
In article <7993@lindy.Stanford.EDU> giant@lindy.Stanford.EDU (Buc Richards) writes: > >KCL (Kyoto Common Lisp) translates programs from Lisp to C and then >compiles the C to generate compiled programs. Is the C code generated >complete? Can the intermediate C code be compiled on another machine, >say a 386 machine, and work? Or does the code require the KCL >environment? The code will compile, but you would need to at least emulate a number of fairly fundamental environmental assumptions (e.g. some lisp stacks, calling protocols, some functions) so essentially you do need the environment. It would be neat to have a LISP which could create complete, independent modules, but due to the way people write lisp it would probably still have to package in alot of LISP functions... Ron
field@sylvester.cs.pitt.edu (Gus) (02/15/90)
In article <1739@skye.ed.ac.uk> jeff@aiai.UUCP (Jeff Dalton) writes: >In article <7993@lindy.Stanford.EDU> giant@lindy.Stanford.EDU (Buc Richards) writes: >> >>KCL (Kyoto Common Lisp) translates programs from Lisp to C and then >>compiles the C to generate compiled programs. > >>Is the C code generated complete? > >I'm not quite sure what you mean. It can be compiled by the C >compiler. But it's a bunch of procedure definitions, not a complete >program. > >The intermediate code is fairly portable, so it will probably compile. > >>Or does the code require the KCL environment? > >It calls procedures that are part of the KCL system and it expects >to be loaded into a running KCL. It would not be too hard to hard >to link it together with the files that make up KCL instead. If you >wanted to convert KCL into a library and have the compiler compile >files that had to be linked with that library, it would probably be >possible to do that. But that isn't how it works now. > Has anyone done this? I would like to be able to run compiled lisp code outside of the KCL environment. Any info appreciated. Brian ----- field@cs.pitt.edu