I think it is one of these stupid questions, as there is CMU CL for Linux
glibc2, so I presume it should work, but I am not convinced yet. So?
> There is no port of CMU CL for LinuxPPC, as far as I know, but did anyone
> try to buld one? Any success?
>
> thanks!
> r
>
>
>
In article <············@oyez.ccc.nottingham.ac.uk> on
<············@oyez.ccc.nottingham.ac.uk>, "Barney" <······@members.com>
wrote:
> I think it is one of these stupid questions, as there is CMU CL for
> Linux glibc2, so I presume it should work, but I am not convinced yet.
> So?
>
>> There is no port of CMU CL for LinuxPPC, as far as I know, but did
>> anyone try to buld one? Any success?
>>
There's no backend to the compiler for the PPC processor, so you'd need
to write one before you could cross-compile to linuxppc (or MacOS X).
I know many people have asked for cmucl on PPC here before, so it might
be a worthy project to pursue. Are any of the cmucl authors working on a
PPC backend?
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
In article <············@joe.rice.edu>, "Rahul Jain" <·····@rice.edu>
wrote:
> In article <············@oyez.ccc.nottingham.ac.uk> on
> <············@oyez.ccc.nottingham.ac.uk>, "Barney" <······@members.com>
> wrote:
>
> > I think it is one of these stupid questions, as there is CMU CL for
> > Linux glibc2, so I presume it should work, but I am not convinced yet.
> > So?
> >
> >> There is no port of CMU CL for LinuxPPC, as far as I know, but did
> >> anyone try to buld one? Any success?
> >>
>
> There's no backend to the compiler for the PPC processor, so you'd need
> to write one before you could cross-compile to linuxppc (or MacOS X).
Hasn't CMUCL also have a byte-code mode?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> > There's no backend to the compiler for the PPC processor, so you'd need
> > to write one before you could cross-compile to linuxppc (or MacOS X).
>
> Hasn't CMUCL also have a byte-code mode?
It does have the possibility to compile to byte-codes in order to save
space in certain cases. But that doesn't buy you much, since
something must exist that interprets the byte-codes, and this facility
is again written in CL, and would have to be compiled to native code
in some way, which would again necessitate a native-backend for PPC,
etc.
If you take SBCL, the CMU CL off-spring which can be bootstrapped
using other Common Lisp implementations, you might theoretically have
a chance relying on a byte-code only mode (though I'm not very
confident it would be easy to do).
The problem here is that you need a CL implementation that targets
LinuxPPC, _and_ which is sufficiently close to ANSI CL that it can
be used to bootstrap SBCL. Since that rules out CLISP (and in all
likelihood AKCL-derivatives like GCL, ECLS, etc.), only Allegro CL
and some (never-released?) version of LispWorks seem to remain.
Since boot-strapping SBCL requires a lot of heap, the free versions
will most likely not work...
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> wrote:
> > Hasn't CMUCL also have a byte-code mode?
>
> It does have the possibility to compile to byte-codes in order to save
> space in certain cases. But that doesn't buy you much, since
> something must exist that interprets the byte-codes, and this facility
> is again written in CL, and would have to be compiled to native code
> in some way, which would again necessitate a native-backend for PPC,
> etc.
The byte-code interpreter is written in CL (and not C or Assembler)?
Wow. Interesting.
Sent via Deja.com
http://www.deja.com/
······@my-deja.com writes:
> The byte-code interpreter is written in CL (and not C or Assembler)?
Yes. Indeed everything except the initial core loader, the core of
the garbage-collector/allocator, the low-level interrupt handling,
some low-level OS-interfacing code and some low-level debugging aids
(LDB monitor), which are written in C, is written in (CMU) CL
(possibly utilizing the lisp-based assembler, e.g. for support
functions and code-emitters).
Which IMHO isn't that unusual, since I'd guess that most of the
commercial Lisp implementations are written the same way. Of course
this introduces some non-trivial bootstrapping issues when porting to
another processor/os (nothing insurmountable, but definitely more than
typing make after adjusting some files).
WRT the byte-code compiler: In contrast to implementations like
CLISP, which use byte-codes and a virtual-machine written in C to offer
better portability, the goal of the byte-code compiler in CMU CL was
not portability, but space-efficiency for little-used and/or non-speed
critical code, like e.g. macro-expanders, etc. That was in times when
CMU CL's demand for 16-20 MB RAM minimum seemed very large ;).
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> If you take SBCL, the CMU CL off-spring which can be bootstrapped
> using other Common Lisp implementations, you might theoretically have
> a chance relying on a byte-code only mode (though I'm not very
> confident it would be easy to do).
>
> The problem here is that you need a CL implementation that targets
> LinuxPPC, _and_ which is sufficiently close to ANSI CL that it can
> be used to bootstrap SBCL. Since that rules out CLISP (and in all
> likelihood AKCL-derivatives like GCL, ECLS, etc.), only Allegro CL
> and some (never-released?) version of LispWorks seem to remain.
>
> Since boot-strapping SBCL requires a lot of heap, the free versions
> will most likely not work...
It *should* be possible (may require some additional work,
though) to bootstrap SBCL on a new machine via a cross-compiler. The
build script is separated into 4 parts, named make-host-{1,2}.sh and
make-target-{1,2}.sh. The make-host-* scripts are meant to be run from
the cross-compiler host, while the make-target-* should be run on the
target.
--
Raymond Wiker
·············@fast.no
"Pierre R. Mai" <····@acm.org> wrote in message
···················@orion.bln.pmsf.de...
>The problem here is that you need a CL implementation that targets
>LinuxPPC, _and_ which is sufficiently close to ANSI CL that it can
>be used to bootstrap SBCL.
IIRC, Digitool did a port of MCL to LinuxPPC for NASA, so that could be used
(technically).
However, I doubt Digitool would have much interest in bootstrapping a free
competitor to their commercial product...
Raf
In article <·····················@typhoon.ne.mediaone.net>,
Raffael Cavallaro <·······@pop.ne.mediaone.net> wrote:
>IIRC, Digitool did a port of MCL to LinuxPPC for NASA, so that could be used
>(technically).
I don't remember hearing about that. I do recall that NASA had obtained
the rights to the MCL sources, and one of the staff (Gary Byers), and
ported MCL to *VxWorks*, which is a whole different kind of OS from
LinuxPPC. Erann Gat would have the details. You still out there,
Erann?
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ······@tsoft.com (MIME enabled)
Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
The addresses above are real. All spammers will be reported to their ISPs.
http://x65.deja.com/[ST_rn=ps]/getdoc.xp?AN=510541584&search=thread&CONTEXT=
981412302.1955135522&HIT_CONTEXT=981412269.1953497204&hitnum=7
I guess I was basing my memory on a posting [see link above] of Rainer
Joswig's (and possibly some traffic on the info-mcl mailing list - I seem to
remember someone from Digitool mentioning a LinuxPPC port done either by or
for NASA.) As you say, Eran Gat would know.
Raf
"Chuck Fry" <······@best.com> wrote in message
·················@nntp1.ba.best.com...
> In article <·····················@typhoon.ne.mediaone.net>,
> Raffael Cavallaro <·······@pop.ne.mediaone.net> wrote:
> >IIRC, Digitool did a port of MCL to LinuxPPC for NASA, so that could be
used
> >(technically).
>
> I don't remember hearing about that. I do recall that NASA had obtained
> the rights to the MCL sources, and one of the staff (Gary Byers), and
> ported MCL to *VxWorks*, which is a whole different kind of OS from
> LinuxPPC. Erann Gat would have the details. You still out there,
> Erann?
>
> -- Chuck
> --
> Chuck Fry -- Jack of all trades, master of none
> ······@chucko.com (text only please) ······@tsoft.com (MIME enabled)
> Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
> The addresses above are real. All spammers will be reported to their
ISPs.
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <············@joe.rice.edu>, "Rahul Jain" <·····@rice.edu>
> wrote:
>> There's no backend to the compiler for the PPC processor, so you'd need
>> to write one before you could cross-compile to linuxppc (or MacOS X).
>
> Hasn't CMUCL also have a byte-code mode?
>
I don't know if you can compile the entire system using only byte codes.
Even if you could, you still have to write the OS interface portion of the
boot code. Granted, that should be an easier task than writing a backend too.
Being able to do such a thing might actually make it easier to port CMUCL to
new platforms. Hmm, I'll have to think about that some more. Why am I
thinking about it? I don't have time for all of the other projects Rainer has
gotten me thinking about! :-) Maybe some of the CMUCL gurus can think about
this.
Mike McDonald
·······@mikemac.com
In article <····················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> > Hasn't CMUCL also have a byte-code mode?
> >
>
> I don't know if you can compile the entire system using only byte codes.
Good question.
> Even if you could, you still have to write the OS interface portion of the
> boot code. Granted, that should be an easier task than writing a backend too.
> Being able to do such a thing might actually make it easier to port CMUCL to
> new platforms. Hmm, I'll have to think about that some more.
I was thinking that this might be a way to make CMUCL more
portable - trading for speed. SQUEAK (a free Smalltalk implementation,
which is quite nice) for example has a VM too,
and as I understand they have written it in Smalltalk. Maybe
there is a design lesson one can look at. SQUEAK is widely available,
runs on many kinds of machines, and there is even a bare-metal
version, IIRC.
ftp://st.cs.uiuc.edu/Smalltalk/Squeak/docs/OOPSLA.Squeak.html
> Why am I thinking about it? I don't have time for all of the other projects
> Rainer has gotten me thinking about! :-)
can you send me a list? just to stay in sync. ;-)
> Maybe some of the CMUCL gurus can think about
> this.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> writes:
> I was thinking that this might be a way to make CMUCL more
> portable - trading for speed. SQUEAK (a free Smalltalk implementation,
> which is quite nice) for example has a VM too,
> and as I understand they have written it in Smalltalk.
Isn't the language used to write the Squeak VM actually just a trivial
subset of Smalltalk which is easily (machine) translatable to C? I
believe the Smalltalk-subset to C translater was written in (the real)
Smalltalk.
Does anyone out there have any documentation which describes the
Symbolics Lisp-like Implementation Language? That would be a really
nifty language to do grody things like bootstrap Lisp systems and
write device drivers with. It should be easily translatable to C as
well.
On 28 Jan 2001 23:41:26 -0500, Carl Shapiro <········@panix.com> wrote:
> Does anyone out there have any documentation which describes the
> Symbolics Lisp-like Implementation Language? That would be a really
As far as I know, it was the same Lisp used for application development.
Paolo
In article <····························@4ax.com>,
Paolo Amoroso <·······@mclink.it> wrote:
>On 28 Jan 2001 23:41:26 -0500, Carl Shapiro <········@panix.com> wrote:
>
>> Does anyone out there have any documentation which describes the
>> Symbolics Lisp-like Implementation Language? That would be a really
>
>As far as I know, it was the same Lisp used for application development.
Not so. LIL was Pascalish semantics under a Lisp-like syntax, with the
advantage that you could use macros to massage the code prior to
compilation. On the 3600 family, it compiled into 68K machine code for
the Front-End Processor (FEP).
I don't know if LIL was used on the Ivories. If it was, it was probably
Lisp with restricted semantics (due to the lack of many advanced
facilities at cold boot time).
I once wrote a microcode RAM test in LIL for the factory's use. You
could probably count all the people who ever wrote code in LIL on one
hand, and you might have fingers left over. :-) David Linden (ne
Plummer) was the only one (besides me) I'm aware of offhand.
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ······@tsoft.com (MIME enabled)
Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
The addresses above are real. All spammers will be reported to their ISPs.
In article <···············@panix3.panix.com>, Carl Shapiro
<········@panix.com> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > I was thinking that this might be a way to make CMUCL more
> > portable - trading for speed. SQUEAK (a free Smalltalk implementation,
> > which is quite nice) for example has a VM too,
> > and as I understand they have written it in Smalltalk.
>
> Isn't the language used to write the Squeak VM actually just a trivial
> subset of Smalltalk which is easily (machine) translatable to C? I
> believe the Smalltalk-subset to C translater was written in (the real)
> Smalltalk.
>
> Does anyone out there have any documentation which describes the
> Symbolics Lisp-like Implementation Language?
I don't think the Symbolics Lisp machine has such a language.
It has it partly. It is for the FEP - but after
the OS has been booted, Genera takes over - AFAIK. I guess it
could be compared to the OpenBoot system on some traditional
computers (SUN, Apple, ...).
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···············@panix3.panix.com>, Carl Shapiro
> <········@panix.com> wrote:
>> Does anyone out there have any documentation which describes the
>> Symbolics Lisp-like Implementation Language?
>
> I don't think the Symbolics Lisp machine has such a language.
> It has it partly. It is for the FEP - but after
> the OS has been booted, Genera takes over - AFAIK. I guess it
> could be compared to the OpenBoot system on some traditional
> computers (SUN, Apple, ...).
My understanding was the FEP was written in LIL, a static, lisp like
language. I don't think it was documented anywhere other than as source.
As for Genera, the docs take up about 16 inches on my bookshelf.
Mike McDonald
·······@mikemac.com
* Mike McDonald wrote:
> My understanding was the FEP was written in LIL, a static, lisp like
> language. I don't think it was documented anywhere other than as source.
I think that's right. I have some early blurb for the 3600 which
describe this. Whether they actually *did* it that way I'm not sure.
--tim
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <····················@typhoon.aracnet.com>,
> ·······@mikemac.com wrote:
>
>> > Hasn't CMUCL also have a byte-code mode?
>> >
>>
>> I don't know if you can compile the entire system using only byte codes.
>
> Good question.
I never got an answer to that part, other than the byte code interpreter
can't be.
>> Even if you could, you still have to write the OS interface portion of the
>> boot code. Granted, that should be an easier task than writing a backend too.
>> Being able to do such a thing might actually make it easier to port CMUCL to
>> new platforms. Hmm, I'll have to think about that some more.
>
> I was thinking that this might be a way to make CMUCL more
> portable - trading for speed. SQUEAK (a free Smalltalk implementation,
> which is quite nice) for example has a VM too,
> and as I understand they have written it in Smalltalk.
I asked on the cmucl-imp mailing list. Even though the responses were very
sparse, the consenses was that it wasn't an easy thing to do. The existing
byte code interpreter takes full advantage of being compiled by a native
backend. It's evidentally not written in a small subset of CL. The CMUCL
python gurus thought it'd be just as easy and more productive to just write a
native backend. (You have to keep in mind that they're interested in speed and
they know how to write a native backend.)
So anyway, I don't think it's going to be done by anyone soon.
Mike McDonald
·······@mikemac.com
>>>>> "Mike" == Mike McDonald <·······@mikemac.com> writes:
Mike> I asked on the cmucl-imp mailing list. Even though the responses were very
Mike> sparse, the consenses was that it wasn't an easy thing to do. The existing
Mike> byte code interpreter takes full advantage of being compiled by a native
Mike> backend. It's evidentally not written in a small subset of CL. The CMUCL
Mike> python gurus thought it'd be just as easy and more productive to just write a
Mike> native backend. (You have to keep in mind that they're interested in speed and
Mike> they know how to write a native backend.)
Mike> So anyway, I don't think it's going to be done by anyone soon.
I think it would be hard, but not impossible. I think the majority of
the work would be describing the machine instructions, writing all of
the vops (virtual ops), making the alien interface use the right
calling conventions, and porting the C code over. This sounds more
tedious than difficult. PPC is a reasonably clean RISC architecture,
right?
But what do I know? I've never had to write a backend.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
>>>>>> "Mike" == Mike McDonald <·······@mikemac.com> writes:
> Mike> I asked on the cmucl-imp mailing list. Even though the responses were very
> Mike> sparse, the consenses was that it wasn't an easy thing to do. The existing
> Mike> byte code interpreter takes full advantage of being compiled by a native
> Mike> backend. It's evidentally not written in a small subset of CL. The CMUCL
> Mike> python gurus thought it'd be just as easy and more productive to just write a
> Mike> native backend. (You have to keep in mind that they're interested in speed and
> Mike> they know how to write a native backend.)
> Mike> So anyway, I don't think it's going to be done by anyone soon.
>I think it would be hard, but not impossible. I think the majority of
>the work would be describing the machine instructions, writing all of
>the vops (virtual ops), making the alien interface use the right
>calling conventions, and porting the C code over. This sounds more
>tedious than difficult. PPC is a reasonably clean RISC architecture,
>right?
If you want to go that far, the JVM may be a more worthwhile target.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
>>>>> "Martin" == Martin Cracauer <········@counter.bik-gmbh.de> writes:
Martin> Raymond Toy <···@rtp.ericsson.se> writes:
>> I think it would be hard, but not impossible. I think the majority of
>> the work would be describing the machine instructions, writing all of
>> the vops (virtual ops), making the alien interface use the right
>> calling conventions, and porting the C code over. This sounds more
>> tedious than difficult. PPC is a reasonably clean RISC architecture,
>> right?
Martin> If you want to go that far, the JVM may be a more worthwhile target.
Why would I want to do that? I'd rather run Clisp or port gcl over to
PPC.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
>>>>>> "Martin" == Martin Cracauer <········@counter.bik-gmbh.de> writes:
> Martin> Raymond Toy <···@rtp.ericsson.se> writes:
> >> I think it would be hard, but not impossible. I think the majority of
> >> the work would be describing the machine instructions, writing all of
> >> the vops (virtual ops), making the alien interface use the right
> >> calling conventions, and porting the C code over. This sounds more
> >> tedious than difficult. PPC is a reasonably clean RISC architecture,
> >> right?
> Martin> If you want to go that far, the JVM may be a more worthwhile target.
>Why would I want to do that? I'd rather run Clisp or port gcl over to
>PPC.
It's of course just theory, but:
- The JVMs with their JITs will probably be faster than a simple
bytecode machine.
- The CMUCL compiler will generate more efficient code for a bytecode
machine, most notable overhead-free layout of arrays of self-defined
data structures (something that Java - the language - does not have).
- The design of Java class files allows for automatic interfacing to
the then-alien Java code. See the Kawa scheme interpreter, the
power it gains from instant access to all Java libraries is
amazing.
- Some JVMs have natives threads, which make them SMP-capable.
I'm not really thrilled about the overall speed aspect of such a
project and would prefer a real native compiler any day, though.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
* Martin Cracauer wrote:
> - Some JVMs have natives threads, which make them SMP-capable.
I don't know of any that have as parallel GC though, so Amdahl's law
will get them for more than a few processors.
--tim
>>>>> "mc" == Martin Cracauer <········@counter.bik-gmbh.de> writes:
mc> Some JVMs have natives threads, which make them SMP-capable.
>>>>> "tb" == Tim Bradshaw <···@cley.com> writes:
tb> I don't know of any that have as parallel GC though, so Amdahl's
tb> law will get them for more than a few processors.
according to [1] the IBM JVMs on S/390 and OS/400 use an on-the-fly
concurrent GC, with an algorithm based on [2]. The research version of
Sun's JVM uses [3] a generational mostly-concurrent GC (Boehm et al's
algorithm).
[1] <URL:http://www.haifa.il.ibm.com/projects/systems/Runtime_Subsystems.html>
[2] <URL:http://citeseer.nj.nec.com/doligez94portable.html>
[3] <URL:http://www.sun.com/research/techrep/2000/abstract-88.html>
[4] <URL:http://citeseer.nj.nec.com/baker78list.html>
[5] <URL:http://citeseer.nj.nec.com/383386.html>
[6] <URL:http://citeseer.nj.nec.com/361444.html>
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
In article <··············@rtp.ericsson.se>,
Raymond Toy <···@rtp.ericsson.se> writes:
>>>>>> "Mike" == Mike McDonald <·······@mikemac.com> writes:
>
> Mike> I asked on the cmucl-imp mailing list. Even though the responses were very
> Mike> sparse, the consenses was that it wasn't an easy thing to do. The existing
> Mike> byte code interpreter takes full advantage of being compiled by a native
> Mike> backend. It's evidentally not written in a small subset of CL. The CMUCL
> Mike> python gurus thought it'd be just as easy and more productive to just write a
> Mike> native backend. (You have to keep in mind that they're interested in speed and
> Mike> they know how to write a native backend.)
>
> Mike> So anyway, I don't think it's going to be done by anyone soon.
>
> I think it would be hard, but not impossible. I think the majority of
> the work would be describing the machine instructions, writing all of
> the vops (virtual ops), making the alien interface use the right
> calling conventions, and porting the C code over. This sounds more
> tedious than difficult. PPC is a reasonably clean RISC architecture,
> right?
Nothing's impossible since this is only software and we're just dreaming. :-)
Would a byte compiled version actually need alien support?
> But what do I know? I've never had to write a backend.
>
> Ray
Me neither!
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> Nothing's impossible since this is only software and we're just
> dreaming. :-)
>
> Would a byte compiled version actually need alien support?
Well you still would need some way to access the functionality of the
underlying operating system, for things like file services,
networking, etc. Either you support the CMU CL alien interface, or
you have to provide these functionalities through the virtual machine,
rewriting all of the lisp-side code to cope with that new mechanism.
But I don't really know what would be the purpose of severely
crippling CMU CL, and expending much effort in the process, for what
still seems like a rather elusive goal, namely that of easy
portability.
There is already CLISP, which is much more portable than CMU CL (even
crippled) will probably ever be, _and_ it is designed around
byte-compilation, portability and ease of bootstrapping through the
use of C, etc. And then there seems to be renewed interest in one of
the KCL-decendants, namely EcoLisp-Spain, with progress being made of
bringing that one up to ANSI compliance, which would seem both easier
to port, and would leverage the C compiler as its compiler backend,
for native compilation.
And once one of those implementations is sufficiently close to ANSI
CL, this would also ease the porting of SBCL.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> writes:
> ·······@mikemac.com (Mike McDonald) writes:
>
>> Nothing's impossible since this is only software and we're just
>> dreaming. :-)
>>
>> Would a byte compiled version actually need alien support?
>
> Well you still would need some way to access the functionality of the
> underlying operating system, for things like file services,
> networking, etc. Either you support the CMU CL alien interface, or
> you have to provide these functionalities through the virtual machine,
> rewriting all of the lisp-side code to cope with that new mechanism.
>
> But I don't really know what would be the purpose of severely
> crippling CMU CL, and expending much effort in the process, for what
> still seems like a rather elusive goal, namely that of easy
> portability.
Compiling CMUCL requires a running CMUCL, preferably of the same version.
Native compiling is easier for most than cross compiling. So if a "portable"
subset of CMUCL existed that was sufficient to do a native compile, then maybe
it make the overall porting process easier.
But mostly, it's an intellectual exercise. "What if?" exercises can be fun
and illuminating. IMNSHO.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> Compiling CMUCL requires a running CMUCL, preferably of the same version.
> Native compiling is easier for most than cross compiling. So if a
> "portable" subset of CMUCL existed that was sufficient to do a
> native compile, then maybe it make the overall porting process
> easier.
For that particular purpose it seems to me that the approach taken by
SBCL is a much better approach. Or making the cross-compilation
process easier to do.
But if one was really serious about making an easily portable version
of CMU CL, I'd write a new compiler backend that emits suitable
opcodes for one of the virtual machines or portable object-code
formats that already exist.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article
<····················@typhoon.aracnet.c
om>,
·······@mikemac.com wrote:
> In article
<····························@news.is-
europe.net>,
> Rainer Joswig
<······@corporate-world.lisp.de> writes:
> > In article <············@joe.rice.edu>,
"Rahul Jain" <·····@rice.edu>
> > wrote:
>
> >> There's no backend to the compiler for
the PPC processor, so you'd need
> >> to write one before you could
cross-compile to linuxppc (or MacOS X).
> >
While working at JPL in the fall of 1997, I
ported CMUCL to LinuxPPC (and of course, in
the process, wrote a PPC backend.) The
result was very rough around the edges, but it
worked well enough to compile itself.
That's the good news. The bad news is that
this was a fairly old version of CMUCL
(pre-18a, if memory serves) and a very old
version of Linux (MkLinux DR3 or thereabouts
- not quite libc6.) The resulting binary doesn't
run on more modern versions of LinuxPPC.
The work I did then might still be a useful
starting point to someone who wanted to port
a more modern version of CMUCL to a more
modern verion of LinuxPPC. Cross-compiling
and bootstrapping CMUCL is still likely to be a
significant amount of work for anyone
interested, and there are some PPC Linux
kernel issues that make debugging the
process more difficult than it needs to be.
About a year ago, I offered (on a cmucl mailing
list) to make the broken port available to
anyone interested, but indicated that I didn't
have time to sort through everything and
package it very well, and that I might not be
able to offer much help or support. The only
response I remember receiving suggested
that I take some time to package my changes.
That's certainly a reasonable suggestion, but
it wasn't practical for me at the time.
I'll repeat the (admittedly somewhat
unreasonable) offer here: if anyone wants a
20MB compressed (70MB uncompressed) tar
file containing a broken port of an old version
of CMUCL to an old version of LinuxPPC, it
just so happens that I have one. If someone
wants to accept it "as is" - ideally, someone
who's familiar with cross-compilation and
bootstrapping in CMUCL in general - let me
know via email and we'll figure out what to do
with that archive.
I hope that this offer is reasonable enough to
be useful.
------------
Gary Byers
············@clozure.com
Sent via Deja.com
http://www.deja.com/
I ported CMUCL to LinuxPPC while working at JPL in the fall of
1997 (and of course wrote a PPC backend in the process.) The
port was pretty rough around the edges, but it was at least able to
compile itself.
That's the good news. The bad news is that this was an old
version of CMUCL (pre 18a, if I recall correctly) and an old version
of LinuxPPC (MkLinux DR3 or thereabouts, with a not-quite-libc6 C
library.) The resulting binary doesn't run under more modern
versions of PPC Linux. (In fact, it crashes rather spectacularly as I
recall.)
Anyone working on porting a more modern version of CMUCL to a
more modern version of LinuxPPC might find the work that I did
then helpful. Cross-compiling and bootstrapping a new port of
CMUCL can be a significant undertaking, and there are some PPC
Linux kernel issues that can make debugging this process more
difficult than it needs to be.
Around a year ago, I offered (on a CMUCL mailing list) to make the
broken PPC port available to interested parties, but indicated that I
didn't have time to package it reasonably and probably wouldn't be
able to offer much in the way of support. The only response I
remember suggested that I take some time to package it sensibly.
That's certainly a reasonable suggestion, but it wasn't practical for
me at the time.
I'll repeat the (admittedly somewhat unreasonable) offer here: if
someone - preferably someone who's familiar with CMUCL
bootstrapping and cross-compilation in general - wants a 20MB
compressed (70MB uncompressed) tar file that contains a
once-working-but-currently-broken port of CMUCL to LinuxPPC, it
just so happens that I have one. If anyone's interested in this
archive "as is" - or wants to suggest an FTP site where I could put
it - please contact me via email at the address below (with
"dont-spam-" removed, of course.)
I hope that this offer is reasonable enough to be useful.
------
Gary Byers
············@clozure.com
In article <············@joe.rice.edu>,
"Rahul Jain" <·····@rice.edu> wrote:
> In article <············@oyez.ccc.nottingham.ac.uk> on
> <············@oyez.ccc.nottingham.ac.uk>, "Barney"
<······@members.com>
> wrote:
>
> > I think it is one of these stupid questions, as there is CMU CL
for
> > Linux glibc2, so I presume it should work, but I am not
convinced yet.
> > So?
> >
> >> There is no port of CMU CL for LinuxPPC, as far as I know,
but did
> >> anyone try to buld one? Any success?
> >>
>
> There's no backend to the compiler for the PPC processor, so
you'd need
> to write one before you could cross-compile to linuxppc (or
MacOS X).
>
> I know many people have asked for cmucl on PPC here before,
so it might
> be a worthy project to pursue. Are any of the cmucl authors
working on a
> PPC backend?
>
> --
> -> -/- - Rahul Jain - -\- <-
> -> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/-
<-
> -> -/- "I never could get the hang of Thursdays." - HHGTTG by
DNA -\- <-
> |--|--------|--------------|----|-------------|------|---------|-----|-|
> Version 11.423.999.220020101.23.50110101.042
> (c)1996-2000, All rights reserved. Disclaimer available upon
request.
>
Sent via Deja.com
http://www.deja.com/
··········@my-deja.com writes:
[...]
>Around a year ago, I offered (on a CMUCL mailing list) to make the
>broken PPC port available to interested parties, but indicated that I
>didn't have time to package it reasonably and probably wouldn't be
>able to offer much in the way of support. The only response I
>remember suggested that I take some time to package it sensibly.
[...]
I remember your mail. Not to defend anyone, there is always a clash
in answers to such offers, noone wants to lean out of the window and
then doing nothing. The CMUCL lists have an execellent promised/done
ratio, but the nagativ part of it is that people tend to keep quite.
[...]
>I'll repeat the (admittedly somewhat unreasonable) offer here: if
>someone - preferably someone who's familiar with CMUCL
>bootstrapping and cross-compilation in general - wants a 20MB
>compressed (70MB uncompressed) tar file that contains a
>once-working-but-currently-broken port of CMUCL to LinuxPPC, it
>just so happens that I have one. If anyone's interested in this
>archive "as is" - or wants to suggest an FTP site where I could put
>it - please contact me via email at the address below (with
>"dont-spam-" removed, of course.)
If you want that, I will of cours put it into the main CMUCL archives
on cons.org so that anyone can pick it up (anonymously :-) and look
into it.
>I hope that this offer is reasonable enough to be useful.
Of course it is, please don't be discouraged by a lack of response.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Gary has been so friendly to send us his work and Douglas Crosher
integrated it into the cmucl CVS Tree, including some tools like
crosscompilers.
That does not mean we have a working version now, but anyone with a
suitable machine faces a puzzle(*), not a montain of work.
I quote from Douglas announcement:
> A port of CMUCL to the PowerPC (linux) has been contributed by Gary Byers.
> The compiler has been integrated into the main CMUCL source, and updated
> for changes since it was written. A PPC cross compiler can be
> build and the source compiled for the PPC using one of the other
> current (18c) ports. The C code and some of the supporting lisp code
> has not yet been integrated and may need some work to get running.
> For the source code, old build FASL files and binaries, and an example
> cross compile from the x86 port see the experimental/ppc/ directory
> at the CMUCL home site.
(*) A real puzzle, though. Previous experience in building CMUCL
using a crosscompiler is needed, as is familiarity is Linux and the
PowerPC architecture to work on things like signal contexts etc.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
"Barney" <······@members.com> writes:
> I think it is one of these stupid questions, as there is CMU CL for
> Linux glibc2, so I presume it should work, but I am not convinced
> yet. So?
No, you would be incorrect there. CMU CL has its own code generator,
a compiler called "Python," and depends not a whit on GCC.
Hopefully the SBCL project can revitalize some of the Python work,
perhaps leading to it being available on some newer platforms, such as
Linux/Alpha and Linux/PPC. It's Not There Yet.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://vip.hyperusa.com/~cbbrowne/sap.html
Rules of the Evil Overlord #44. "I will only employ bounty hunters who
work for money. Those who work for the pleasure of the hunt tend to do
dumb things like even the odds to give the other guy a sporting
chance." <http://www.eviloverlord.com/>
········@hex.net writes:
> Hopefully the SBCL project can revitalize some of the Python work,
> perhaps leading to it being available on some newer platforms, such as
> Linux/Alpha and Linux/PPC. It's Not There Yet.
I seem to remember that some time ago, someone on cmucl-imp did seem
to report success in cross-compiling CMU CL to Linux/Alpha (this is a
much easier undertaking than porting CMU CL to Linux/PPC, since CMU CL
already has a back-end for Alpha processors, and runs on Tru64/Alpha).
Regs, Pierre.
PS: Work on Python and CMU CL is quite vital in the CMU CL community,
too.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> ········@hex.net writes:
>
> > Hopefully the SBCL project can revitalize some of the Python work,
> > perhaps leading to it being available on some newer platforms, such as
> > Linux/Alpha and Linux/PPC. It's Not There Yet.
>
> I seem to remember that some time ago, someone on cmucl-imp did seem
> to report success in cross-compiling CMU CL to Linux/Alpha (this is a
> much easier undertaking than porting CMU CL to Linux/PPC, since CMU CL
> already has a back-end for Alpha processors, and runs on Tru64/Alpha).
>
> Regs, Pierre.
>
> PS: Work on Python and CMU CL is quite vital in the CMU CL community,
> too.
This was commented on some time ago in the cmucl-imp mailing list. As
long as the information flows in both directions (as it has, AFAICS) I
will be happy.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
> > Hopefully the SBCL project can revitalize some of the Python work,
> > perhaps leading to it being available on some newer platforms, such as
> > Linux/Alpha and Linux/PPC. It's Not There Yet.
thanks to all. This resolves my problem which notebook to buy: powerbook g4
or sony z600... Or maybe there are any other free (and good) CL
implementations with CLX interface for LinuxPPC? (i know about MCL for MacOS
and Mac Emacs, but I'd prefer working in LinuxPPC).
thanks
r
In article <············@oyez.ccc.nottingham.ac.uk>,
Barney <······@members.com> wrote:
>thanks to all. This resolves my problem which notebook to buy: powerbook g4
>or sony z600... Or maybe there are any other free (and good) CL
>implementations with CLX interface for LinuxPPC? (i know about MCL for MacOS
>and Mac Emacs, but I'd prefer working in LinuxPPC).
I believe Franz had an Allegro CL port for LinuxPPC at one point.
Duane, is that history, or is there a current version?
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ······@tsoft.com (MIME enabled)
Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
The addresses above are real. All spammers will be reported to their ISPs.
······@best.com (Chuck Fry) writes:
> In article <············@oyez.ccc.nottingham.ac.uk>,
> Barney <······@members.com> wrote:
> >thanks to all. This resolves my problem which notebook to buy: powerbook g4
> >or sony z600... Or maybe there are any other free (and good) CL
> >implementations with CLX interface for LinuxPPC? (i know about MCL for MacOS
> >and Mac Emacs, but I'd prefer working in LinuxPPC).
>
> I believe Franz had an Allegro CL port for LinuxPPC at one point.
> Duane, is that history, or is there a current version?
History, current, and future.
Also, trial version is downloadable. See the website...
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
>
> ······@best.com (Chuck Fry) writes:
>
> > I believe Franz had an Allegro CL port for LinuxPPC at one point.
> > Duane, is that history, or is there a current version?
>
> History, current, and future.
>
> Also, trial version is downloadable. See the website...
>
Will there be a version for MacOS X? Between the existing freebsd/x86
and linuxppc versions, you ought to have almost all the pieces you
need. I'm in the process of moving from my HP-UX box to a dual G4, and
I'd dearly love to take Allegro along with me.
--
Remove obvious stuff to e-mail me.
Bob Bane
Bob Bane <····@removeme.gst.com> writes:
> Duane Rettig wrote:
> >
> > ······@best.com (Chuck Fry) writes:
> >
> > > I believe Franz had an Allegro CL port for LinuxPPC at one point.
> > > Duane, is that history, or is there a current version?
> >
> > History, current, and future.
> >
> > Also, trial version is downloadable. See the website...
> >
>
> Will there be a version for MacOS X?
Probably, eventually. But there are no current official plans to
do so.
> Between the existing freebsd/x86
> and linuxppc versions, you ought to have almost all the pieces you
> need.
Actually, this is not the case. The MacOS X calling convention is
more similar to the AIX calling convention than to the linuxppc version.
When I did the linuxppc port (as a port to mkLinux, at the time), I
started by modifying the AIX port, whose Power instruction set was
related and similar enough to the PowerPC instruction set to be useful.
However, the extreme differences in calling conventions caused me
grief, and I ended up cloning the sources and creating a different
"target class". It was on that new set of machine-dependent sources
that I was able to finish the mklinux/linuxppc port. Back to the
MacOSX port: it is hung on the same target class as AIX, and has
nothing to do with LinuxPPC (except that both operating systems tend
to reside on the same hardware).
The BSD connection is fairly solid, but there are issues there, as
well. NFS does not work on HFS+ filesystems in one direction (I forgot
whether it was in the server or client direction), so in order to get
the full unix file sharing capabilities the system must be installed
at least partially on a UFS file system. Also, dlopen/dlsym has been
removed, in favor of the dyld() style dynamic-loading. I have a pretty
good idea, but haven't yet sorted out for sure how many of these and
other differences are Apple-isms, NeXT-isms, or simply differences
between BSD flavors.
> I'm in the process of moving from my HP-UX box to a dual G4, and
> I'd dearly love to take Allegro along with me.
But would you be content with just the programming environment, with
no connection to the window toolkits?
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Duane Rettig wrote:
>
> Bob Bane <····@removeme.gst.com> writes:
>
> > Between the existing freebsd/x86
> > and linuxppc versions, you ought to have almost all the pieces you
> > need.
>
> Actually, this is not the case. ...
*sigh* I was hoping it would be straightforward. Nothing is
straightforward when you're talking about low-level Un*x and C
compatibility, I guess.
> > I'm in the process of moving from my HP-UX box to a dual G4, and
> > I'd dearly love to take Allegro along with me.
>
> But would you be content with just the programming environment, with
> no connection to the window toolkits?
>
*I* would, but then I do as little GUI development as I can get away
with - my user-interface taste is all in my mouth.
--
Remove obvious stuff to e-mail me.
Bob Bane
"Barney" <······@members.com> writes:
>There is no port of CMU CL for LinuxPPC, as far as I know, but did anyone
>try to buld one? Any success?
CMUCL is a native compiler (with assembler) and needs a backend (a
description of the machine code (not description of assembly
language!)) for PPC. AFAIK, noone started working on one.
There is a (probably not functional anymore) backend for the IBM
PC/RT, which had some architectural influence on PowerPC (via RS/6000
and IBM Power), that is probably a bit of help when starting one. Not
that it is more than a few percent of the multiple man-months required
to write a backend...
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>, Martin Cracauer wrote:
> ...
>There is a (probably not functional anymore) backend for the IBM
>PC/RT, which had some architectural influence on PowerPC (via RS/6000
>and IBM Power), that is probably a bit of help when starting one. Not
not very likely. the architecture of RT and RS6000 have very little in
common. about the only think i can think of is that both used registers
of 32 bits
hs
··@paradise.nirvananet (Hartmann Schaffer) writes:
>In article <·············@counter.bik-gmbh.de>, Martin Cracauer wrote:
>> ...
>>There is a (probably not functional anymore) backend for the IBM
>>PC/RT, which had some architectural influence on PowerPC (via RS/6000
>>and IBM Power), that is probably a bit of help when starting one. Not
>not very likely. the architecture of RT and RS6000 have very little in
>common. about the only think i can think of is that both used registers
>of 32 bits
ACK. My comment was based on thin impressions, probably from an IBM
advertising paper...
Never mind.
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/