Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CMUCL for PPC?

11 views
Skip to first unread message

Fernando Mato Mira

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to
I just got this VxWorks box with 8MB flash and 32MB RAM..

Anybody started playing around with a PPC backend?

Just for fun. I'm not going to use it, although seeing some config file
parsing utilities plus associated app code make me sooo itchy :-P
[For that, I could just go with the most inefficient Scheme around,
provided it lets me create and leave around some global C struct with
the parameters the real program should use (VxWorks is a shared memory
environment)]


Pierre R. Mai

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to

Didn't the NASA have a port of Harlequin's LispWorks to VxWorks
on PPC? IIRC that's the hardware that was used on the recent
experimental autonomous explorer mission. Members of this group which
were part of the effort will surely know more... ;)

Adapting Franz' ACL port to (Mk)Linux/PPC might also be feasible...

OTOH writing a new compiler backend to CMU CL would be very welcome,
though much more work (as has been discussed in recent and not-so
recent posts to this group). AFAIK there is currently no active
effort to port CMU CL to the PPC architecture...

Regs, Pierre.

--
Pierre Mai <pm...@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]

Erik Naggum

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to
* Pierre R. Mai

| Adapting Franz' ACL port to (Mk)Linux/PPC might also be feasible...

so feasible it has already been done. pick up Allegro CL 5.0.1 Trial
edition from ftp.franz.com:/pub/acl501trial/mklinux.tar and rejoice.

#:Erik

Pierre R. Mai

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to
Erik Naggum <er...@naggum.no> writes:

I was being to obscure again (my writing style seems to deteriorate
constantly!) Of course I meant taking the, as you say, existing
Franz' ACL port to (Mk)Linux/PPC and adapting that to VxWorks...

Chuck Fry

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to
In article <87puz8l...@orion.dent.isdn.cs.tu-berlin.de>,

Pierre R. Mai <pm...@acm.org> wrote:
>Fernando Mato Mira <mato...@iname.com> writes:
>> I just got this VxWorks box with 8MB flash and 32MB RAM..
>>
>> Anybody started playing around with a PPC backend?
>
>Didn't the NASA have a port of Harlequin's LispWorks to VxWorks
>on PPC? IIRC that's the hardware that was used on the recent
>experimental autonomous explorer mission. Members of this group which
>were part of the effort will surely know more... ;)

Yes, NASA commissioned a VxWorks port of Harlequin Common Lisp (we
didn't need the X Windows interface to LW on a spacecraft :-).

>Adapting Franz' ACL port to (Mk)Linux/PPC might also be feasible...

ACL is already available for Linux on PPC, and freely distributed for
non-commercial (and non-governmental) uses. See www.franz.com to get a
copy.

Thanks to Erann Gat and Gary Byers, NASA has VxWorks and Linux ports of
MCL, though they're only available for NASA internal use.

>OTOH writing a new compiler backend to CMU CL would be very welcome,
>though much more work (as has been discussed in recent and not-so
>recent posts to this group). AFAIK there is currently no active
>effort to port CMU CL to the PPC architecture...

If it's not insanely difficult, I think it should be done. While I'm
interested in the work, I doubt that I'll have any time to volunteer to
help.

-- Chuck, again not speaking for NASA
--
Chuck Fry -- Jack of all trades, master of none
chu...@chucko.com (text only please) chuc...@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.

Kent M Pitman

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to
chu...@best.com (Chuck Fry) writes:

> Thanks to Erann Gat and Gary Byers, NASA has VxWorks and Linux ports of
> MCL, though they're only available for NASA internal use.

Seems to me kind of a shame there wasn't "Lisp Onboard" for the guidance
system on the Mars Climate Orbiter.

Having being out-of-touch with earth spell automatic failure is sad indeed.
Any way we can use this unfortunate event to push for more presence of
"smart" technology, especially technology that's been around and getting
rigorously stessed in tons of hard application areas for, say, 40-odd years...?

Those who don't know about MCO's sad news should see:
http://www.jpl.nasa.gov/releases/99/mcolost.html

Chuck Fry

unread,
Sep 24, 1999, 3:00:00 AM9/24/99
to
In article <sfwk8pg...@world.std.com>,

Kent M Pitman <pit...@world.std.com> wrote:
>chu...@best.com (Chuck Fry) writes:
>> Thanks to Erann Gat and Gary Byers, NASA has VxWorks and Linux ports of
>> MCL, though they're only available for NASA internal use.
>
>Seems to me kind of a shame there wasn't "Lisp Onboard" for the guidance
>system on the Mars Climate Orbiter.

Um, well, even on New Millenium Deep Space One, the onboard autonomous
navigation software was written in C. But I do wonder if Mars Climate
Orbiter could have reached Martian orbit successfully had it done its
own navigation.

>Having being out-of-touch with earth spell automatic failure is sad indeed.

As I understood the situation, the navigational error was of terrestrial
origin. MCO may have been slightly off course since its last mid-course
correction over a week ago.

In defense of the folks at JPL, please remember that a 56-mile error on
an object many millions of miles away is an awfully small error! But it
is enough to spell the difference between success and utter failure.

>Any way we can use this unfortunate event to push for more presence of
>"smart" technology, especially technology that's been around and getting
>rigorously stessed in tons of hard application areas for, say, 40-odd years...?

To me, one of the key reasons for autonomous spacecraft is the potential
to avoid human operational errors. I would bet that JPL management is
taking a hard look at on-board navigation right about now!

-- Chuck, *definitely* not speaking for NASA

Fernando Mato Mira

unread,
Sep 27, 1999, 3:00:00 AM9/27/99
to
Chuck Fry wrote:

> Yes, NASA commissioned a VxWorks port of Harlequin Common Lisp (we
> didn't need the X Windows interface to LW on a spacecraft :-).

That would give a whole new meaning to LBX.. ;-)

Erann Gat

unread,
Sep 27, 1999, 3:00:00 AM9/27/99
to
In article <sfwk8pg...@world.std.com>, Kent M Pitman
<pit...@world.std.com> wrote:

> Seems to me kind of a shame there wasn't "Lisp Onboard" for the guidance
> system on the Mars Climate Orbiter.
>

> Having being out-of-touch with earth spell automatic failure is sad indeed.

> Any way we can use this unfortunate event to push for more presence of
> "smart" technology, especially technology that's been around and getting
> rigorously stessed in tons of hard application areas for, say, 40-odd
> years...?

We're working on it :-)

Actually, in the case of MCO Lisp would probably not have helped much.
The problem there was in the actual mathematics of calculating the
spacecraft's position based on the available observations. Here's
the story as told to me by an experienced senior JPL engineer for
those who are interested.

Figuring out where a spacecraft actually is is done primarily by
measuring the doppler shift of the spacecraft downlink radio beacon.
This gives a direct measurement of one component of the spacecraft's
velocity relative to the Earth (the component parallel to the radio
beam). This single measurement is then run through a mathematical
model to figure out where the spacecraft is most likely to
be given where it was known to be earlier and the physics of
spaceflight. These models take into account such things as
general-relativistic time dilation effects, the effect of solar
wind pressure, etc. The calculations are unbelievably hairy.
The net effect is that the "navigation solution" is effectively
an integration of multiple doppler measurements taken over long
periods of time. This integration usually converges to a very
precise value.

One thing that makes the process more difficult is the effects of
the spacecraft's thrusters. These can change the spacecraft's
trajectory in ways that are not accounted for in the model and
thus can cause the nav solution not to converge. If you *know*
how the thrusters are firing then you can work those into the model.
Alternatively you can use "balanced" pairs of thrusters that turn
the spacecraft without accelerating it. Unfortunately, balanced
thrusters cost more than unbalanced ones, and in these days of
better-faster-cheaper, balanced thrusters are a luxury.

Then there was MCO's physical configuration: it had a single
solar panel sticking out one side, making it very lopsided, which
made it very succeptible to torques caused by solar wind pressure,
which made it necessary to fire the thrusters more often to keep
the spacecraft in the correct attitude, which caused the nav
solution to not converge. So we hit the planet. :-(

Erann Gat
g...@jpl.nasa.gov

Tim Bradshaw

unread,
Sep 27, 1999, 3:00:00 AM9/27/99
to
* Erann Gat wrote:
> These models take into account such things as
> general-relativistic time dilation effects, the effect of solar
> wind pressure, etc. The calculations are unbelievably hairy.

I seem to remember that the famous `real programmers' text went on at
some length about how no one would trust Pascal or Pascal programmers
to navigate a spacecraft to Mars. Presumably the people who wrote it
would have a seizure if anyone suggested using *Lisp* to navigate a
spacecraft to Mars.

--tim

.. Although, actually Lisp is much less of a quiche-eaters' language
than Pascal.


Chuck Fry

unread,
Sep 27, 1999, 3:00:00 AM9/27/99
to
In article <ey33dw0...@lostwithiel.tfeb.org>,

Tim Bradshaw <t...@tfeb.org> wrote:
>I seem to remember that the famous `real programmers' text went on at
>some length about how no one would trust Pascal or Pascal programmers
>to navigate a spacecraft to Mars. Presumably the people who wrote it
>would have a seizure if anyone suggested using *Lisp* to navigate a
>spacecraft to Mars.
>
>--tim
>
>.. Although, actually Lisp is much less of a quiche-eaters' language
>than Pascal.

Yeah, I can still use a 'goto' (GO) in Lisp! :-)

-- Chuck, who *doesn't* use GO except in extreme circumstances

Christopher R. Barry

unread,
Sep 28, 1999, 3:00:00 AM9/28/99
to
Tim Bradshaw <t...@tfeb.org> writes:

> I seem to remember that the famous `real programmers' text went on at
> some length about how no one would trust Pascal or Pascal programmers
> to navigate a spacecraft to Mars. Presumably the people who wrote it
> would have a seizure if anyone suggested using *Lisp* to navigate a
> spacecraft to Mars.

The text can be found at:
http://www.datamation.com/PlugIn/issues/bestof/classics.html

The specific excerpt:

Some of the most awesome real programmers of all work at the Jet
Propulsion Laboratory in California. Many of them know the entire
operating system of the Pioneer and Voyager spacecraft by heart.
With a combination of large ground-based FORTRAN programs and
small spacecraft-based assembly language programs, they are able
to do incredible feats of navigation and improvisation - hitting
ten-kilometer wide windows at Saturn platforms, radios, and
batteries. Allegedly, one real programmer managed to tuck a
pattern-matching program into a few hundred bytes of unused
memory in a Voyager spacecraft that searched for, located, and
photographed a new moon of Jupiter.

The current plan for the Galileo spacecraft is to use a gravity
assist trajectory past Mars on the way to Jupiter. This
trajectory passes within 80 +/-3 kilometers of the surface of
Mars. Nobody is going to trust a Pascal program (or a Pascal
programmer) for navigation to these tolerances.

Christopher

0 new messages