* Janine <·····@bellatlantic.net>
| Does anyone know where I can get download clos for linux?
if it is for non-commercial use, see ftp.franz.com/pub/linux/acl50.
also get the patches in pub/patches/5.0/x86-linux/redhat[45].
#:Erik
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.
* ·····@sip.medizin.uni-ulm.de (kp gores)
| most people think about linux as linux running on a ibm-pc compatible.
| but what about linux running on a powerpc processor..e.g. a macintosh?
right, this is an important oversight. Franz Inc does refer to it as
x86-linux in the patch directory, but just as "redhatn", n in [4,5], on
the CD-ROMs.
| AFAIK there is no lisp for linux on powerpc processors. am i wrong?
I have not seen any Linux Lisp offerings for other than Intel, either.
#:Erik
--
SIGTHTBABW: a signal sent from Unix to its programmers at random
intervals to make them remember that There Has To Be A Better Way.
> | AFAIK there is no lisp for linux on powerpc processors. am i wrong?
>
> I have not seen any Linux Lisp offerings for other than Intel, either.
Well, AFAIK no native compilers. But all the interpreters (including
CLISP and lots of scheme implementations) should work nonetheless.
I guess the compilers which work by translating Lisp to C (GCL, Clicc,
Ecolisp) could probably convinced to function with little or no
work.
AFAIK the only 'free' Common Lisp native compiler is CMUCL and that's
only for Sparc and Intel. Heck, there aren't much more free C
compilers either and I assume a good Common Lisp is even more
complicated to implement.
...Michael...
In article <·················@mindless.com>, Michael Dingler <········@mindless.com> wrote:
> > | AFAIK there is no lisp for linux on powerpc processors. am i wrong?
> >
> > I have not seen any Linux Lisp offerings for other than Intel, either.
>
> Well, AFAIK no native compilers. But all the interpreters (including
> CLISP and lots of scheme implementations) should work nonetheless.
> I guess the compilers which work by translating Lisp to C (GCL, Clicc,
> Ecolisp) could probably convinced to function with little or no
> work.
> AFAIK the only 'free' Common Lisp native compiler is CMUCL and that's
> only for Sparc and Intel. Heck, there aren't much more free C
> compilers either and I assume a good Common Lisp is even more
> complicated to implement.
>
> ...Michael...
I recently read about the following strategy for writing
a compiler - would it be useful in a Lisp context?
- first a Lisp-to-C compiler generates C code for a specific collection
of code snippets
- one then compiles this C code to native code
- the native code then is freed from all C specific stuff
- the raw code then is being packaged in a way that
a Lisp-to-native compiler can issue these instructions directly
without the further need of the C compiler
1st version: Lisp code -> C code -> native code -> raw native code
2nd version: Lisp code -> native code
--
http://www.lavielle.com/~joswig
In article <·······················@194.163.195.67>,
Rainer Joswig <······@lavielle.com> wrote:
>In article <·················@mindless.com>, Michael Dingler <········@mindless.com> wrote:
>> work.
>> AFAIK the only 'free' Common Lisp native compiler is CMUCL and that's
...
>I recently read about the following strategy for writing
>a compiler - would it be useful in a Lisp context?
>
>- first a Lisp-to-C compiler generates C code for a specific collection
> of code snippets
Errr, shouldn't some small OS specific runtime kernel be required?
At some point the rubber has to hit the road. Usually the Lisp-2-C
process involves some "sidecar" library that does the runtime stuff.
Therein lies the rub.
If you want to bootstrap someones preexisting library then fine. If
it isn't already there... you haven't solved the problem. I think
for the most part CMUCL is largely written in CL. However, there
is a small kernel you must get up ( which may consist of making the
right set of foreign function calls).
>- the raw code then is being packaged in a way that
> a Lisp-to-native compiler can issue these instructions directly
> without the further need of the C compiler
Yeah but the code generator needs to know what "opcodes" to generate.
That is specific to the platform. You can have a framework for this.
I think the CMUCL generates "micro operations" which later, after
some platform independent optimization, get translated
to the native code. So all you have to do is provide a mapping from
"micro ops" to native code fragments. The layer of abstraction
eases the "pain"... it doesn't quite make it go away.
CLISP negates this by always compiling to a common code. It is
probably easier to write a platform independent code interpreter engine.
--
Lyman S. Taylor "The Borg -- party poopers of the Galaxy. "
(·····@cc.gatech.edu) EMH Doctor Star Trek Voyager.
Michael Dingler <········@mindless.com> writes:
> AFAIK the only 'free' Common Lisp native compiler is CMUCL and
> that's only for Sparc and Intel. Heck, there aren't much more free C
> compilers either and I assume a good Common Lisp is even more
> complicated to implement.
It might be an interesting project to look into reusing the Gcc
"backend" stuff. For example, the C++, ObjectiveC, FORTRAN, and
Pascal compilers are hooking their code into Gcc's native compilation
facilities, thus in effect getting a native code compiler without the
weary porting to all those platforms.
I wonder if Gcc is generic enough to allow this to be done for Lisp.
Hrvoje Niksic <·······@srce.hr> writes:
[...]
> It might be an interesting project to look into reusing the Gcc
> "backend" stuff. For example, the C++, ObjectiveC, FORTRAN, and
> Pascal compilers are hooking their code into Gcc's native compilation
> facilities, thus in effect getting a native code compiler without the
> weary porting to all those platforms.
>
> I wonder if Gcc is generic enough to allow this to be done for Lisp.
"Matthew X. Economou" <········@irtnog.org> writes:
[...]
> (The reason I'm asking is that I noticed a Java front end in the EGCS
> code repository. My assumption, possibly incorrect, is that the Java
> front end generates the usual output that can be fed to standard tools
> like as, ar, and ld, just like GCC and G++. If Java -- a (in my mind)
> primarily interpreted language, but with features like just-in-time
> compilation and byte compilation -- if Java can be compiled into
> object files, then linked into programs or libraries just like any C
> or C++ program, why couldn't the same be done with Lisp or Scheme?
The GCJ Java front end being worked on for EGCS compiles both class
files and java files to native code, and the runtime support libraries
and GDB related stuff are also being worked on. When all of this is
completed, Linux (and all of EGCS's targets) will be killer Java
platforms.
The GCC/EGCS front end converts source to RTL. RTL is, from the GCC
docs:
RTL Representation
******************
Most of the work of the compiler is done on an intermediate
representation called register transfer language. In this
language, the instructions to be output are described, pretty much
one by one, in an algebraic form that describes what the
instruction does.
RTL is inspired by Lisp lists.
Here's part of the RTL dump from "Hello World" (use the -dr flag):
(call_insn 10 8 11 (set (reg:SI 0 %eax)
(call (mem:QI (symbol_ref:SI ("printf")))
(const_int 4))) -1 (nil)
(nil)
(nil))
A Common Lisp -> RTL front end to EGCS could be written, and runtime
shared libraries that work in the ar/ld way could be implemented for
Lisp as they are finally doing for Java, but there would have to be
considerable interest in such a thing, and sadly there isn't.
There are Common Lisp -> C compilers, and these (AFAIK) provide a Lisp
runtime in the form of a C library that contains the definitions to
things like EVAL that you link to the compiler's output to produce
your executable.
Personally, I prefer the traditional Lisp compiler invocation method
and runtime system anyways.
Christopher
>>>>> "Hrvoje" == Hrvoje Niksic <·······@srce.hr> writes:
Hrvoje> It might be an interesting project to look into reusing
Hrvoje> the Gcc "backend" stuff.... I wonder if Gcc is generic
Hrvoje> enough to allow this to be done for Lisp.
My recent questions regarding Lisp compilers has been driven by
similar thoughts. I've started to examine GCC's back end code, and it
seems to me that a Lisp front end would be possible. I am still
trying to understand how GCC works, though, so I have no code to show
anyone yet.
(The language front ends for GCC generate a kind of abstract syntax
tree. They pass this completed tree to the back end for
transformation into an intermediate language called RTL, which is then
transformed into macro assembler code. Standard assembler and linker
utilities, e.g. UNIX's as(1) and ld(1), actually generate object code.
Currently, the Enhanced GNU Compiler System, EGCS, has front ends for
C, Objective-C, C++, Fortran-77, and Java. There are also ADA and
Pascal front ends that aren't currently in CVS.)
--
"It's not procrastination, it's my new Just-In-Time Workload Management
System!" --Jim Paradis on axp-list
Michael Dingler <········@mindless.com> writes:
> AFAIK the only 'free' Common Lisp native compiler is CMUCL and that's
> only for Sparc and Intel. Heck, there aren't much more free C
Well, CMUCL is also available for DEC Alpha running Digital Unix and
IIRC for some versions of HP-UX. There is always some kind of
time-lag between the Intel/Sparc versions and the other ones, since
most active CMUCL developers are on Intel/Sparc, ...
Regs, Pierre.
--
Pierre Mai <····@acm.org> http://home.pages.de/~trillian/
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
>>>>> "Clemens" == Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
Clemens> Michael Dingler <········@mindless.com> writes:
[snip[
>> AFAIK the only 'free' Common Lisp native compiler is CMUCL and that's
>> only for Sparc and Intel. Heck, there aren't much more free C
>> compilers either and I assume a good Common Lisp is even more
>> complicated to implement.
Clemens> Porting CMUCL to a PowerPC platform would be a major task.
That would be true, but there used to be a version for the RS/6000,
which uses some type of Power architecture. It might be close enough
that the port may not be too difficult. I think this version also ran
on Mach, so you'd have to remove that dependency as well.
A big task to be sure, but I would think it would be easier than the
original port of CMUCL to FreeBSD.
Ray
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> wrote:
>>>>>> "Clemens" == Clemens Heitzinger <········@rainbow.studorg.tuwien.ac.at> writes:
>
> Clemens> Michael Dingler <········@mindless.com> writes:
>[snip[
...
>
> Clemens> Porting CMUCL to a PowerPC platform would be a major task.
>
>That would be true, but there used to be a version for the RS/6000,
>which uses some type of Power architecture. It might be close enough
>that the port may not be too difficult.
Errr, I think that there was a version for the IBM RT workstations.
Those had ROMP processors. Not exactly Power and definately
not PowerPC. ROMP was a processor aimed at wordprocessors that
IBM tried to perpetrate as a viable engine for a workstation.... NOT!
The RT was the generation before the RS/6000 series.
There may be some similiarities, so it perhaps could serve
as a starting point. If the porter knows one of the more actively
maintained target arch as well as PowerPC, those too may serve as
"templates".
See Part III: on the following link
http://www2.ssd.sscc.ru/microprocessor/great/s5.html
--
Lyman S. Taylor "The Borg -- party poopers of the Galaxy. "
(·····@cc.gatech.edu) EMH Doctor Star Trek Voyager.