Xref: utzoo comp.realtime:1264 comp.ai:9040 comp.lang.lisp:4782 comp.lang.c++:12893 comp.robotics:803
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!varvel
From: varvel@cs.utexas.edu (Donald A. Varvel)
Newsgroups: comp.realtime,comp.ai,comp.lang.lisp,comp.lang.c++,comp.robotics
Subject: Re: "Easy" way to put "AI" in realtime embedded systems?
Keywords: realtime, ai, c++, lisp, embedded
Message-ID: <1334@muleshoe.cs.utexas.edu>
Date: 16 Apr 91 21:49:28 GMT
References: <1991Mar26.163917.14641@unhd.unh.edu> <4471@skye.ed.ac.uk> <1234@telesoft.com>
Followup-To: comp.realtime
Organization: U. Texas CS Dept., Austin, Texas
Lines: 38

In article <1234@telesoft.com> rlk@telesoft.com (Bob Kitzberger @sation) writes:

>I missed the original post, but if the poster wants to embed LISP in a hard
>real-time application, there are valid engineering questions that need
>to be asked.

>I don't prefess to be anything near a LISP expert, but I'll toss out
>a few questions you need to ask yourself.  Can you calculate guaranteed 
>worst-case times for LISP routines in the presence of interrupts?  How 
>about the dynamic memory allocation algorithms used in LISP -- are they 
>non-deterministic?   How can you protect LISP data structures in the 
>presence of concurrency?  Is reclamation of stale heap space performed?
>I don't mean to imply that LISP fails in these areas.

>Worst-case analysis is necessary for hard real-time applications.  You're
>charting new territory if you use LISP in hard real-time, IMHO.

Funny you should mention it.  Yesterday I happened to be
at TI Dallas.  Folks there mentioned with some pride a
hard real-time system being developed in LISP.  They didn't
seem to want to talk much about details, but two points
that were mentioned were incremental garbage collection
and worst-case time guarantees for functions.

Very few off-the-shelf systems of any sort are suitable
for hard real-time applications.  Hardware designers seem
particularly prone to confuse *fast* with *guaranteed worst-
case performance*.  That tends to land us with "real-time"
processors with 17-level caches.

"Robotics" is often done by AI sorts, in LISP.  "Equipment
control" is often done by real-time sorts, in assembly.
It is clear to *me*, at least, that the two must eventually
evolve together.  If the worst problem we have in finding 
a reasonable meeting ground is producing a real-time LISP, 
we should count ourselves lucky.

-- Don Varvel (varvel@cs.utexas.edu)