Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!bill From: bill@ibmpcug.co.uk (Bill Birch) Newsgroups: comp.realtime,connect.audit Subject: Re: "Easy" way to put "AI" in realtime embedded systems? Keywords: realtime, ai, c++, lisp, embedded Message-ID: <1991Apr18.172535.3570@ibmpcug.co.uk> Date: 18 Apr 91 17:25:35 GMT Organization: The IBM PC User Group, UK. Lines: 36 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. --