[connect.audit] "Easy" way to put "AI" in realtime embedded systems?

bill@ibmpcug.co.uk (Bill Birch) (04/19/91)

In article <11080@uwm.edu> markh@csd4.csd.uwm.edu (Mark William Hopkins) writes:
> In article <1334@muleshoe.cs.utexas.edu> varvel@cs.utexas.edu (Donald A. Varvel) writes:
> >"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.
> 
> The meeting ground is doing robotics in assembly too.  Different languages
> are good for different things, and assembly is well-suited for bare to the
> metal hardware tasks.  LISP (the first language I learned after BASIC) I think
> is just too roundabout.
> 
> Generally, though, the meeting ground is right here at my place. :)

Some work has been done on "real-time" LISP systems. Most of the problems are to do with garbage collection. Also some production LISP systems are rather large
hence difficult to imbed. 

I've developed a LISP interpreter which has deterministic response times
because it uses reference counting garbage collection. It is in 'C' and
will run on an ATARI-ST. I guess you could embed it in a ROM-based system
.. er, yes, that would work. Email me for the source.

Otherwise you could translate LISP/scheme to C. 

I hear that the highly succesful real-time expert system "G2" from GENSYM 
uses LISP at base.  They will be releasing a C version soon.

So real-time AI is not so infeasible!

-- 
Automatic Disclaimer:
The views expressed above are those of the author alone and may not
represent the views of the IBM PC User Group.
--