sgc@msel.unh.edu (Steven G. Chappell) (03/27/91)
Hi
Over the years we have been working on an experimental autonomous
vehicle (EAVE) of the submersible persuasion. In the early stages, effort was
centered on the "traditional" robotics issues of positioning and motion
control, with a very heavy emphasis directed at the real-time aspects of same.
Subsequent work centered on an architecture which provides the capability for
adding new functionality to the already existing vehicle system. Recent work
dealt with the business of incorporating concepts from the AI community into
the vehicle runtime system so as to render it more "intelligent" (less stupid).
This is a nontrivial business since traditional embedded systems don't support
symbolic programming environments and such environments don't mix well with
"real-time" operation. Thus, my general information request:
By what methods can "AI" algorithms be installed in an embedded system?
Methods we have examined or heard about:
software:
augment embedded system with library which supports symbolic functionality
develop in some extension of C, compile, download, run
automated translation of symbolic code to supported code (C)
develop in LISP, translate, compile, download, run
utilize C++ (is C++ an adequate "AI" environment?)
develop in C++, compile, download, run
rehost the symbolic environment to the embedded system
develop in LISP, download, run
hardware: (is this really possible?)
install LISP capable subsystem in target bus
In particular, we went the "rehost" route: transporting the University of
Utah's Portable Common LISP Subset from an HP Bobcat to our particular
development system and subsequently to our vehicle system. This has worked
to a degree, but it is not without its warts.
What experiences have you all had or heard about in regards to this?
Please email responses.
--
Marine Systems Engineering Laboratory
Marine Program Building
University of New Hampshire
sgc@msel.unh.edu Durham, NH 03824-3525sgc@msel.unh.edu (Steven G. Chappell) (03/27/91)
Hi
Over the years we have been working on an experimental autonomous
vehicle (EAVE) of the submersible persuasion. In the early stages, effort was
centered on the "traditional" robotics issues of positioning and motion
control, with a very heavy emphasis directed at the realtime aspects of same.
Subsequent work centered on an architecture which provides the capability for
adding new functionality to the already existing vehicle system. Recent work
dealt with the business of incorporating concepts from the AI community into
the vehicle runtime system so as to render it more "intelligent" (less stupid).
This is a nontrivial business since traditional embedded systems don't support
symbolic programming environments and such environments don't mix well with
"realtime" operation. Thus, my general information request:
By what methods can "AI" algorithms be installed in an embedded system?
Methods we have examined or heard about:
software:
augment embedded system with library which supports symbolic functionality
develop in some extension of C, compile, download, run
automated translation of symbolic code to supported code (C)
develop in LISP, translate, compile, download, run
utilize C++ (is C++ an adequate "AI" environment?)
develop in C++, compile, download, run
rehost the symbolic environment to the embedded system
develop in LISP, download, run
hardware: (is this really possible?)
install LISP capable subsystem in target bus
In particular, we went the "rehost" route: transporting the University of
Utah's Portable Common LISP Subset from an HP Bobcat to our particular
development system and subsequently to our vehicle system. This has worked
to a degree, but it is not without its warts.
What experiences have you all had or heard about in regards to this?
Please email responses.
--
Marine Systems Engineering Laboratory
Marine Program Building
University of New Hampshire
sgc@msel.unh.edu Durham, NH 03824-3525sfp@mars.ornl.gov (Phil Spelt) (03/27/91)
In article 777, Steven Chappell inquires about embedded AI, suggesting
several possible alternatives, and reports choosing "rehost" as their
solution. My question: Why stay with LISP?????
Concerning "embedded architecture" robotic control, we here at the Center
for Engineering Systems Advanced Research (CESAR) have been using just
such an architecture for our autonomous mobile robots for the past 4 or 5
years. We have chosen the "rehost" solution, also, but with entirely different directions:
Our hardware configuration is: IBM PC/AT (industrialized), so that there is an 80286 host running 16 nodes of an NCube hypercube parallel computer. All code
is written in 'C' (er, well, ONE program on the host is in FORTRAN). We use
an expert system to control both naviagtion and machine learning. This is
created in CLIPS, which runs in two versions on two different nodes (one for navigation and one for Learning). CLIPS provides the source code, which we then
ported to the node environment. It also provides "LISP-like" rule construction,
but with (IMHO 8=) ) much better mathematical computation ability on the RHS.
Our robot runs around in an "unstructured", dynamic environment, locates a
control panel, and learns to manipulate the panel to shut off a "DANGER" light.
All this is in "real time" -- the limiting factors are the speed of the arms and of the vision processing. The ESs perform at a MUCH faster speed than the
mechanical parts of the robot.
I repeat my question: WHY insist on LISP?????
Phil Spelt, Cognitive Systems & Human Factors Group sfp@epm.ornl.gov
============================================================================
Any opinions expressed or implied are my own, IF I choose to own up to them.
============================================================================smith@sctc.com (Rick Smith) (03/28/91)
sgc@msel.unh.edu (Steven G. Chappell) writes: >By what methods can "AI" algorithms be installed in an embedded system? The same way as any other algorithm... Once you know how you want the system to operate there's nothing to prevent you from porting your ideas from LISP to a conventional embedded programming language. It's the approach I used when I did thesis research in robotics. On the other hand, if you don't know what '"AI" algorithms' you want to use, you'll produce at best illusory progress pouring effort into developing a platform with an "embedded LISP" environment. When I think of '"AI" algorithms' I think of things like rule based systems, constraint systems, heuristic search strategies, frame systems, etc. Any or all of these can be implemented just fine in non-LISP environments. Personally, I believe that it's better not to use LISP since LISP can mask some resource issues (i.e. memory usage) that you should be sure to solve if you're applying such algorithms to an embedded system problem. A potential weakness to my arguments is that '"AI" algorithms' are most often described using LISP, so you need to know how to see "under" the LISP in order to implement them in a non-LISP environment. Still, I encourage this since it forces you to understand what you're doing... and believe me, you _can_ do AI work even if you do understand what you're doing! Rick. smith@sctc.com Arden Hills, Minnesota
jax@well.sf.ca.us (Jack J. Woehr) (03/28/91)
sgc@msel.unh.edu (Steven G. Chappell) writes: >symbolic programming environments and such environments don't mix well with >"realtime" operation. Thus, my general information request: >By what methods can "AI" algorithms be installed in an embedded system? There have been several succesful ports LISP >> Forth. GE's DELTA and somebody's (NASA?) autorouter (Symbolics>>RTX2000) to name two. Performance vastly increased in both cases. -- <jax@well.{UUCP,sf.ca.us} >< Member, > /// ///\\\ \\\ /// <well!jax@lll-winken.arpa >< X3J14 TC > /// /// \\\ \\\/// <JAX on GEnie >< for ANS > \\\ /// ///====\\\ ///\\\ <SYSOP RCFB (303) 278-0364>< Forth > \\\/// /// \\\ /// \\\
baker@csl.dl.nec.com (Larry Baker) (03/30/91)
There's a recent article in CACM that may be of interest here. "Real-time Data Acquisition at Mission Control," Muratore, Heindel, Murphy, Rasmussen and McFarland; CACM December 1990, v33 no 12. One of the issues they faced was integrating "expert systems" (using CLIPS) and a fairly hardcore realtime data acquisition problem. I don't know the details (e.g. how CLIPS compares to the other so-called "AI" tools), though. -- Larry E. Baker, Jr. NEC America, Inc. C&C Software Laboratories 1525 Walnut Hill Ln., Irving, TX (214) 518-3489 baker@texas.csl.dl.nec.com -or- cs.utexas.edu!necssd!baker
jeff@aiai.ed.ac.uk (Jeff Dalton) (04/11/91)
In article <1991Mar27.151129.8754@cs.utk.edu> sfp@mars.epm.ornl.gov (Phil Spelt) writes: >In article 777, Steven Chappell inquires about embedded AI, suggesting >several possible alternatives, and reports choosing "rehost" as their >solution. My question: Why stay with LISP????? Why not? Some people like Lisp. Since we don't insist that you use the language we like, why give us a hard time for not using the language you like? >It also provides "LISP-like" rule construction, but with (IMHO 8=) ) >much better mathematical computation ability on the RHS. It's not clear what this means, since Lisp doesn't have rules.
rlk@telesoft.com (Bob Kitzberger @sation) (04/13/91)
In article <4471@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: > > Why not? Some people like Lisp. Since we don't insist that you use > the language we like, why give us a hard time for not using the > language you like? It doesn't seem to me like it's a quiestion of 'liking' a language or not. Jeez, we're supposed to be _engineers_ with the wisdom to select the correct tool for its merits, not because of our subjective preferences. 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. .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West, San Diego, CA 92121-9891 (619) 457-2700 x163 ------------------------------------------------------------------------------ "Wretches, utter wretches, keep your hands from beans!" -- Empedocles
Nick_Janow@mindlink.UUCP (Nick Janow) (04/13/91)
Forth might be a good choice for adding AI to embedded systems. Forth is widely used in embedded systems, and is also used in robotics and AI research. Using Forth for all parts of the project would save time, money, system resources and complexity compared with using, say, C for one part and Lisp for the AI.
Nick_Janow@mindlink.UUCP (Nick Janow) (04/14/91)
kube@cs.UAlberta.CA (Ron Kube) writes: > Nick_Janow@mindlink.UUCP (Nick Janow) writes: > >+ Forth might be a good choice for adding AI to embedded systems. Forth is >+ widely used in embedded systems, and is also used in robotics and AI >+ research. > > Do you have an example of Forth's use in AI research? I don't have the references for that; I do remember reading that Forth definitely was being used for AI work. The FORML (Forth Modification Laboratory)--a forum for sharing and discussing new ideas for Forth--proceedings contains some discussion about AI, expert systems, neural networks, etc. The Rochester Proceedings, sponsored by the Institute for Applied Forth Research, Inc., had "Real-Time Artificial Intelligence" as the title for the 1986 conference. The Journal of Forth Applications and Research has issues with contents like, "Expert Systems in Forth", "Forth-based Prolog for Real-Time Expert Systems" and "Symbolic Stack Addressing". These proceedings can be ordered through the Forth Interest Group (order forms in Forth Dimensions magazine). If you can't find Forth Dimensions in your university library, you can try a local FIG Chapter (the N. Alta. Inst. of Tech. (403-486-6666 day, 403-962-2203 night) is probably the closest to you.) If you would like more information about Forth in AI work, post a query on comp.lang.forth. Hopefully, someone there can help you further.
Nick_Janow@mindlink.UUCP (Nick Janow) (04/14/91)
jm59@prism.gatech.EDU (MILLS,JOHN M.) writes: > I haven't used Forth, but it has some attractive qualities for this: > (1) [SUPPOSED to be] Inherently "clean" for real-time-interrupts, True; Forth is used extensively in real-time applications. > (2) Inherently extensible (but if you "extend" an existing function, > you probably lose the original definition), Nope, you don't have to lose the earlier definition. Forth is extensible in many ways. You can add new data structures and manipulation tools with ease; if your work deals with floating-point vectors, you can extend Forth to handle them. You can change existing definitions if you want to; you could have "+" mean "subtract 5 and multiply by 7" if you _really_ wanted to. :) All it takes is : + 5 - 7 * ; > (3) Inherently recursive, Yes, useful at times. > (4) Assembly-language sources available for several common processors, Yes, there's quite a list. Forth is quite easy to write compilers for and can fit on small (<2kbytes) systems, so it's often used as the first language. All SPARC stations use Forth as their boot core and is available for regular use. There are also several microprocessors that are designed to run Forth. The RTX (real-time express) series and the SC32 are high-performance risc chips that run Forth as native code. These are probably ideal for running AI-Forth software. > (5) Small but [fairly] visible body of experienced users. > I understand that Forth was invented for telescope control in a lab setting, > which sounds like a comparable set of problems viz. hardware driving. Yes, Forth was developed to run hardware and is still one of the best choices for that, especially real-time control. Assembler could give slightly higher performance, but Forth is so much more productive. :) Forth is presently in the process of becoming ANSI-approved. Having this standard Forth will make programs and programmers even more portable than they are now. > (Also, Forth tends to parenthesize, making LISPers feel comfortable: > LISP :: "Lots of Irritating Single Parentheses" M. Waite, _Software for > Non-Numerical Applications_ [8->). Now that I have to disagree with. I chose Forth because it didn't have those irritating parentheses and you didn't have to declare every single variable (tedious). The only thing I use parentheses for is for stack comments (documentation). Contrary to popular misconception, Forth can be quite readable and--depending on the programmer's style--self-documenting. I'm not an expert on AI research, but Forth sounds well-suited for that. Its extensibility, modularity and interactiveness makes it ideal for experimentation. One Forth'er uses it for exploring mathematics, since he can extend the language to with mathematical constructs.
Nick_Janow@mindlink.UUCP (Nick Janow) (04/15/91)
sfp@mars.ornl.gov ( Phil Spelt) writes: > Everything cited above for Forth is doable in 'C', and there is a really > LARGE body of users to whom one can turn for help. Well, yes. In fact, you could probably do everything in machine code too; the difference is in productivity. Forth, due to its simple, extensible, interactive compiler, is generally considered much more productive than 'C', especially for experimental work. I have to agree that there are more 'C' users to turn to for help. I'm not sure how useful that help is, but it's there. The relative numbers of users don't accurately reflect the relative quality (power?, usefulness?) of languages. Do the relative numbers of ms-dos users _really_ say that it's the best OS ever developed? :)
jm59@prism.gatech.EDU (MILLS,JOHN M.) (04/15/91)
In article <5478@mindlink.UUCP> Nick_Janow@mindlink.UUCP (Nick Janow) writes: >Forth might be a good choice for adding AI to embedded systems. Forth is >widely used in embedded systems, and is also used in robotics and AI research. >Using Forth for all parts of the project would save time, money, system >resources and complexity compared with using, say, C for one part and Lisp for >the AI. I haven't used Forth, but it has some attractive qualities for this: (1) [SUPPOSED to be] Inherently "clean" for real-time-interrupts, (2) Inherently extensible (but if you "extend" an existing function, you probably lose the original definition), (3) Inherently recursive, (4) Assembly-language sources available for several common processors, and (5) Small but [fairly] visible body of experienced users. I understand that Forth was invented for telescope control in a lab setting, which sounds like a comparable set of problems viz. hardware driving. (Also, Forth tends to parenthesize, making LISPers feel comfortable: LISP :: "Lots of Irritating Single Parentheses" M. Waite, _Software for Non-Numerical Applications_ [8->). On the other front (built-in LISP): XLISP for the MS-DOS PC is distributed in source form, in C. This is a PD offering; check local BBSs. You have to decide whether to field the MS-DOS environment, or embed the LISP, but you've got the LISP to start with, or Some LISP systems can (I understand) compile user programs to C. This would require a two-stage crossing (LISP->C; C->embedded env.). (I have heard this claim for Symbolics, I think.) I haven't done these things, and the Forth comments were gratuitous, but since noone had mentioned either PD XLISP or cross-compilation, I hoped this might start some ideas. I _did_ play with a Forth-like "Threaded Interpretive Language" for CP/M, called "STOIC." CPMUG distribution. It would probably work, but FORTH is more common and users at least _exist_. -- MILLS,JOHN M. Georgia Institute of Technology, Atlanta Georgia, 30332 uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!jm59 Internet: jm59@prism.gatech.edu
kube@cs.UAlberta.CA (Ron Kube) (04/15/91)
Nick_Janow@mindlink.UUCP (Nick Janow) writes: >Forth might be a good choice for adding AI to embedded systems. Forth is >widely used in embedded systems, and is also used in robotics and AI research. Do you have an example of Forth's use in AI research?
sfp@mars.ornl.gov (Phil Spelt) (04/16/91)
In article <5478@mindlink.UUCP> Nick_Janow@mindlink.UUCP (Nick Janow) writes: >Forth might be a good choice for adding AI to embedded systems. Forth is >widely used in embedded systems, and is also used in robotics and AI research. >Using Forth for all parts of the project would save time, money, system >resources and complexity compared with using, say, C for one part and Lisp for >the AI. Seems to me that one could do everything in 'C' by using CLIPS [C Language Integrated Production System]. This system has been ported to, and compiled on, M68020/30 processors, NCube hypercupe nodes, PC clones, Macs, and I'm sure other machines here in our lab. We use it for "real-time" autonomous robotic control, including system intgerrupts to deal with moving objects in the robot's environment. Everything cited above for Forth is doable in 'C', and there is a really LARGE body of users to whom one can turn for help. ============================================================================= MIND. A mysterious form of matter secreted by the brain. Its chief activity consists in the endeavor to asscertain its own nature, the futility of the attempt being due to the fact that it has nothing but itself to know itself with. -- Ambrose Bierce ============================================================================= Phil Spelt, Cognitive Systems & Human Factors Group sfp@epm.ornl.gov ============================================================================ Any opinions expressed or implied are my own, IF I choose to own up to them. ============================================================================
misha@ai.mit.edu (Mike Bolotski) (04/16/91)
In article <5494@mindlink.UUCP>, Nick_Janow@mindlink.UUCP (Nick Janow) writes: |> I don't have the references for that; I do remember reading that Forth |> definitely was being used for AI work. Here's a data point. The only application of Forth that I'm aware of at the AI Lab is programming a single-board 6811 computer for low-level operations such as motor control. The language is not used for any other purposes, including research on core AI. -- Mike Bolotski Artificial Intelligence Laboratory, MIT misha@ai.mit.edu Cambridge, MA
jeff@aiai.ed.ac.uk (Jeff Dalton) (04/16/91)
In article <1234@telesoft.com> rlk@telesoft.com (Bob Kitzberger @sation) writes: >In article <4471@skye.ed.ac.uk>, jeff@aiai.ed.ac.uk (Jeff Dalton) writes: >> >> Why not? Some people like Lisp. Since we don't insist that you use >> the language we like, why give us a hard time for not using the >> language you like? > >It doesn't seem to me like it's a quiestion of 'liking' a language or not. >Jeez, we're supposed to be _engineers_ with the wisdom to select the correct >tool for its merits, not because of our subjective preferences. Unfortunately, engineering reasons seldom tell you the single right tool to use. This doesn't stop some people from claiming that they do or from being convinced themselves. In the end, it often comes down to whether you value, say, a certain degress of flexibility over a certain degree of efficiency, or vice versa, and to what you're used to. In many cases, some people will find Lisp better than C and others will find C better than Lisp. This doesn't mean one of them must be wrong. This is not entirely subjective, but neither is it entirely objective. >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. Just so, and for embedded real time it may be that Lisp is unsuitable. >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. I will leave this to the experts on various Lisp systems. Lisp can certainly come close, but few if any implementations aim to be suitable for embedded real-time use. -- Jeff
monty@sagpd1 (04/16/91)
I may be totally wrong in this but aren't FORTH and LISP close relatives? It seems to me that FORTH was the foundation of LISP. Now as I said before I may be remembering wrong or have the wrong "child" of FORTH in mind, or I may just be remembering a LISP that was developed from FORTH as an exercise by some one I knew or read about. Is there anyone out there that can set me straight or re-enforce this?? Thanks, Monty Saine
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (04/16/91)
In article <5478@mindlink.UUCP>, Nick_Janow@mindlink.UUCP (Nick Janow) writes: > Forth might be a good choice for adding AI to embedded systems. Forth is > widely used in embedded systems, and is also used in robotics and AI research. > Using Forth for all parts of the project would save time, money, system > resources and complexity compared with using, say, C for one part and Lisp for > the AI. Having done sensor based mobile platforms, Conveyor/changer mechanisms, motion controls/incl ramp/dampnimg, and numerous other projects in FORTH i can vouch for the claims made above. I've done so many projects that relied on closing reality loops that without the interactive real-time nature of FORTH I'd have done less than half half as well. I let engineering guideline guide my selection and have done some "simple" embedded controls with PC SBC's in Tubo C, but that is the only decent alternative and matches only a narrow range of embedded applications. It sure isn't as easy to determine what's wrong in the C/PC environment, but then again without a strong grounding in engineering using FORTH can be just as hard. FORTH as a language to *use* is really easy, but embedded systems are not so easy and the overhead of a compiler-universe can be another not so easy realm that complicates the solution of embedded control realm products. This can be a classic engineering mistake. Since it costs me I don't do it often. 8^) Clyde
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (04/16/91)
In article <kube.671722611@menaik>, kube@cs.UAlberta.CA (Ron Kube) writes: > Nick_Janow@mindlink.UUCP (Nick Janow) writes: > > >Forth might be a good choice for adding AI to embedded systems. Forth is > >widely used in embedded systems, and is also used in robotics and AI research. > ???: > Do you have an example of Forth's use in AI research? I don't have anything one hand, but I know lot's is out there. The above have some papers and Published Journals that address AI in Real Time. One Large Train Engine MFG has an operational Engine Diagnostics Expert System they are very happy with. The International Forth Interest Group has other resources. There is a package called Expert-2 by Parks that is elementary. The U.R. Laboratory is doing Laser work for Fusiuon and other projects in forth. I don't know but some nice RT dynamic network routing work that's been done might be considered AI... Clyde
smith@sctc.com (Rick Smith) (04/17/91)
>Nick_Janow@mindlink.UUCP (Nick Janow) writes: >>Forth might be a good choice for adding AI to embedded systems. Forth is >>widely used in embedded systems, and is also used in robotics and AI >>research. This thread would make more sense if the buzz-acronym "AI" had been replaced by something more specific. Personally, I think that "AI" in robotics consists of trying to connect the quantitative world of sensors and control with a more qualitative world of goals, meanings, and intentions. But other people think it means other things (expert systems, usually). I don't think there *is* an "easy" way to put AI in an embedded system. You can probably take any specific technique that is/has been assocated with AI and implement it in C or Forth or Lisp, or whatever, but then it's a question of the "easy way to put software in an embedded system". On the other hand, if you're doing exploratory work in sensor interpretation, you don't necessarily know a priori what the system needs to do to solve the problem. Of course, classical FORTH has the embedded dictionary and interpreter that give it some LISPish features missing in C, making it easier to extend in novel, unexpected ways. That's a plus in such work. And kube@cs.UAlberta.CA (Ron Kube) writes: >Do you have an example of Forth's use in AI research? There is/used to be a lab full of FORTH hackers at UMass doing robotics research. I don't know if any of their work was AI work. Rick. smith@sctc.com Arden Hills, Minnesota
varvel@cs.utexas.edu (Donald A. Varvel) (04/17/91)
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)
yoshi@nocusuhs.nnmc.navy.mil (Dojun Yoshikami) (04/17/91)
In article <1991Apr16.155126.5186@sagpd1> monty@sagpd1.UUCP (Monty Saine) writes: > > I may be totally wrong in this but aren't FORTH and LISP close relatives? >It seems to me that FORTH was the foundation of LISP. Now as I said before >I may be remembering wrong or have the wrong "child" of FORTH in mind, or I >may just be remembering a LISP that was developed from FORTH as an exercise >by some one I knew or read about. Is there anyone out there that can set me >straight or re-enforce this?? > >Thanks, > >Monty Saine Ho boy, here we go. Don't feel bad, FORTH and LISP are quite different. The first difference is FORTH is Postfix and LISP is prefix. The Second is FORTH allows one to bind at any time (using the words : CREATE and DOES>) either early or late (which is why it's so d*mn fast!) whereas LISP (for the most part) tends to be late binding and does not allow one to control binding as easily. FORTH is easily extensible, for instance, FORTH doesn't have a GOTO but if you want it, you can program it in. (Now how many languages can you do that in? Yes, Virginia, there are places where you want GOTO's, particularly where state transitions are concerned). Forth allows you to extend your language to create your own defining words. The main defining word : (pronounced Colon) which you use to define other words is defined in Forth. In Forth you can De-compile definitions to see what they are, run non-preemptive multitasking, and have assembly code assembled right in front of your eyes, fully integrated with Forth code. Forth happily works with Assembler (it's very very easy) and many Forths have a built in assembler (for particularly tight code). FORTH makes a terrific microprocessor architecture (you can make one within 4000 gates) which runs at blinding speeds. Indeed, a 4mhz Novix ran 8088 code using a 8088 simulator faster than an 8088 at a slightly higher speed (6mhz, I believe). A FORTH chip can run 100-1000 times faster than a 80386 running at twice the clock speed. Why? Someone once told me that FORTH makes a terrific microcode language. A bit of trivia: some time ago, there was a survey asking compiler writers what kind of machine they'd like to write for. They wanted a stack based machine which turned out to be unusually close to the Forth machine. It seems that stack based machines are a lot better than register based machines for traversing DAGs. From the very beginning FORTH has had multi-tasking (some FORTH systems omit it, in particular, FIG-forth) which is something most languages don't have. (Ada has NOTHING NEW, and besides, FORTH's multi-tasking algorithm (non-premptive) is geared for real-time multi-tasking). FORTH and LISP developed quite separately. Forth has one word called ' (pronounced TICK) which I believe was descended from LISP's single quote. But other than that, the architecture and thought processes between the two are completely separate. In fact, ' (tick) works completely differently. You can write a LISP interpreter in FORTH, but you'd be rather hard pressed to write a FORTH interperter in LISP. The term FORTH INTERPETER is actually a bit misleading, FORTH will interpret, compile, or (in many cases) assemble depending on what you want. Assemble code at run time? No problem! Compile on the fly during run time? No problem! Forth encourages you to figure out how the innards work and fiddle with the insides and extend it and change it as you wish. How many other languages do this? C certainly doesn't! (Ever try to extend a C compiler? It's not that easy. You can learn the innards of forth and fiddle with it within a week or two). Forth is easily ROM-mable within 1-2k for a bare bones interpreter (a good choice for those robotic things which wander around) and you can buy FORTH chips off the shelf (From Silicon Composers, or Harris semiconductor). It is practially the EASIEST language for controlling hardware. Now for the problems. Forth is not standardized, indeed there are many dialects out there (FIG, Forth-79, Forth-83, PolyForth, etc.) Many FORTH's didn't have floating point numbers (fix point integer math is usually faster), there is a big need for libraries (for databases, windowing, data structres, whatnot) that other languages (such as C) already have. True, you can create these functions in Forth, but who has the time? Another problem is most people don't understand Forth, which really is so different than anything else, you have to re-think some things. Also FORTH does not have all those nice syntax-analysis and software development tools that C has now days (things like YACC and LEX, source code analyzers, &c) Finally, FORTH leaves a LOT in the programmer's hands that could be standardized; for instance, data abstraction and encapsulation are easily accomplished, but since those are not standard, everone has his own way of doing it. (I don't mind standardization, as long as they continue to allow everyone to fiddle under the hood when necessary). Too much in the FORTH world is non-standard. ANSI standardization is a good idea, I just hope they don't hose things too badly. Anyways, to answer your question (finally) Forth is about as related to Lisp as the Metro-Goldwyn Lion is related to Calvin Cooledge. Sure, they're both mammals, both are male, but there the resemblences stop. Both Forth and Lisp are Programming languages, they can run on the same machines, but I wouldn't substitute one for the other. (Can you imagine a Lion in the Oval Office and a President in a cage? Hey! I heard that!!!! No comments from the Peanut Gallery!!) If you're wondering why I'm so interested in Forth, currently I'm in the process of making a few small microprocessor controlled robotics projects, and the easiest way to program them is in Forth. If there's anyone who knows where to get a ROM-able Z80 Interpreter, Let me know (I'm too lazy to write my own!) May the Forth be with you!!!!!! FORTH LOVE IF HONK THEN DY =-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= D M Yoshikami :-) ;-) :-) | Internet: yoshikami@usuhsb.ucc.usuhs.nnmc.navy.mil May the Forth be with you! | Bitnet : yoshikami@usuhsb.bitnet *** !!xob X*NU V METSYS T&TA eht ni renosirp dleh gnieb m`I !pleH !pleH *** =-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= P.s. I program in practically any language I can get my hands on, including Ada, C, and, on rare occasions (!) COBOL (arrgh!). I figure, each language has some reason for existing, so I try to exploit that, especially if the language is tailored to a certain problem. I will not write windowy SQL databasey things in Forth, just like I would REFUSE to write small rommable hardware control (robotics) projects in RPG.
rdominy@kong.gsfc.nasa.gov (Robert Dominy) (04/17/91)
In article <1991Apr16.155126.5186@sagpd1> monty@sagpd1 writes: > I may be totally wrong in this but aren't FORTH and LISP close relatives? > It seems to me that FORTH was the foundation of LISP. Now as I said before > I may be remembering wrong or have the wrong "child" of FORTH in mind, or I You are wrong. LISP is much older than FORTH is, having been developed around the FORTRAN time -- 1950's! ------------------------------- Robert Dominy NASA Goddard Space Flight Center
wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) (04/17/91)
> I may be totally wrong in this but aren't FORTH and LISP close relatives? The two languages have many similar properties. But they were designed for different purposes and their foundations are different. Postscript is much closer to Forth. >It seems to me that FORTH was the foundation of LISP. Now as I said before >I may be remembering wrong or have the wrong "child" of FORTH in mind, or I >may just be remembering a LISP that was developed from FORTH as an exercise >by some one I knew or read about. Is there anyone out there that can set me >straight or re-enforce this?? Forth was born later than LISP. I don't think the designer of LISP knew anything about Forth when he designed LISP. Because of the simplicity of Forth, many people had developed variants of Forth, such as Fifth, Sixth, ... . I don't know any LISP written in Forth. But I do know there is Prolog written in Forth.
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (04/18/91)
In article <11106@uwm.edu>, wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) writes: > > I may be totally wrong in this but aren't FORTH and LISP close relatives? > > The two languages have many similar properties. But they were designed for > different purposes and their foundations are different. Postscript is much > closer to Forth. > Charles Moore, the designer of FORTH did incorporate a bit of Lisp-isms in FORTH, notably extension to the base langauge. > >It seems to me that FORTH was the foundation of LISP. Now as I said before > >I may be remembering wrong or have the wrong "child" of FORTH in mind, or I > >may just be remembering a LISP that was developed from FORTH as an exercise > >by some one I knew or read about. Is there anyone out there that can set me > >straight or re-enforce this?? > > Forth was born later than LISP. I don't think the designer of LISP knew > anything about Forth when he designed LISP. Because of the simplicity of > Forth, many people had developed variants of Forth, such as Fifth, Sixth, > ... . I don't know any LISP written in Forth. But I do know there > is Prolog written in Forth. > As a FORTH interest group ( FIG ) leader who shared sessions with a LISP group in the original Chacago Area Computer Hobbyist Exchange ( C.A.C.H.E. ) along with Ward Christenson ( XMODEM fame ), our group did a Lisp in FORTH called FLISP. It was my first stab at RT AI and man was it something. I won't say what but for being in 1980-81 it was *early*. Another thing FORTH and LISP share is simple internals that provide hugely poweful externals, or usage. Today's need are better suited to FORTH and the AI chips. See my recent post... Clyde
cwpjr@cbnewse.att.com (clyde.w.jr.phillips) (04/18/91)
In article <1991Apr17.143949.25843@nocusuhs.nnmc.navy.mil>, yoshi@nocusuhs.nnmc.navy.mil (Dojun Yoshikami) writes: > In article <1991Apr16.155126.5186@sagpd1> monty@sagpd1.UUCP (Monty Saine) writes: > > > > I may be totally wrong in this but aren't FORTH and LISP close relatives? > >It seems to me that FORTH was the foundation of LISP. Now as I said before > >I may be remembering wrong or have the wrong "child" of FORTH in mind, or I > >may just be remembering a LISP that was developed from FORTH as an exercise > >by some one I knew or read about. Is there anyone out there that can set me > >straight or re-enforce this?? > > > >Thanks, > > > >Monty Saine > > Ho boy, here we go. > Deleted the really nice "go" > > If you're wondering why I'm so interested in Forth, currently I'm in the > process of making a few small microprocessor controlled robotics projects, > and the easiest way to program them is in Forth. If there's anyone who knows > where to get a ROM-able Z80 Interpreter, Let me know (I'm too lazy to write > my own!) > > May the Forth be with you!!!!!! FORTH LOVE IF HONK THEN > > DY > > =-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > D M Yoshikami :-) ;-) :-) | Internet: yoshikami@usuhsb.ucc.usuhs.nnmc.navy.mil > May the Forth be with you! | Bitnet : yoshikami@usuhsb.bitnet > *** !!xob X*NU V METSYS T&TA eht ni renosirp dleh gnieb m`I !pleH !pleH *** > =-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > P.s. I program in practically any language I can get my hands on, including > Ada, C, and, on rare occasions (!) COBOL (arrgh!). I figure, each language > has some reason for existing, so I try to exploit that, especially if the > language is tailored to a certain problem. I will not write windowy SQL > databasey things in Forth, just like I would REFUSE to write small rommable > hardware control (robotics) projects in RPG. Hi there! I've done a LOT of this. I ported a FIG-FORTH for my buddies Z-80 SBC back in 1980. By 1984 he employed it in a Naval Contract implementing Spread Spectrum Battlefield relay radios, or was it remote data acq. radio relays, anyway the Naval Officers LOVED IT. His interactive remote diagnostics didn't hurt either. So anyway this man is Mike Simon, (815) 874-2296 Space-Time Productions Talk to him as he currently controls our 8-bit products, and you guys may have more to talk about.... Take care & have Fun, Clyde
smith@sctc.com (Rick Smith) (04/18/91)
> monty@sagpd1.UUCP (Monty Saine) writes: >> >> I may be totally wrong in this but aren't FORTH and LISP close relatives? >>It seems to me that FORTH was the foundation of LISP. ... >>Is there anyone out there that can set me straight or re-enforce this?? John McCarthy developed LISP around 1956-57 and presented it as a notation for fiddling with recursive functions on a computer. Chuck Moore developed FORTH about 10 years later. I forget just why did it, but Kitt's Peak Observatory was an early and ardent user. >> >>Thanks, >> >>Monty Saine And yoshi@nocusuhs.nnmc.navy.mil (Dojun Yoshikami) writes: >... FORTH allows one to bind >at any time (using the words : CREATE and DOES>) either early or late (which >is why it's so d*mn fast!) whereas LISP (for the most part) tends to be late >binding and does not allow one to control binding as easily. Not true. Modern LISPs support early, late, and up-to-the-last-possible- moment binding. It depends on how you use your compiler. FORTH generally binds early, since it will compile-in a pointer to the latest dictionary entry, and that pointer won't ever be changed to point to a more recent one. But it _can_ be made to bind late. One reason I love both languages is that they both have embedded interpreters available at runtime. Now *that's* what I call late binding! >FORTH is easily >extensible, for instance, FORTH doesn't have a GOTO but if you want it, you >can program it in. LISP is also easily extensible. It already has GOTO, and you can implement numerous bizarre flow control variations with modern LISPs. >... Forth allows you to extend your language to create your own >defining words. Same with LISP. Every LISP typically comes with a bunch of optionally loaded libraries of functions you'll get if you need them, all written in LISP. > In Forth you can De-compile definitions to see what they are, Same with most LISPs: implementable, commonly found, but not always included. >run non-preemptive multitasking, I do it all the time in LISP. Did a great realtime autoloader mechanism simulation on a Macintosh in LISP. I *did* have to implement my own scheduler and such and maybe it wasn't as transparent as I'd wish. >If you're wondering why I'm so interested in Forth, currently I'm in the >process of making a few small microprocessor controlled robotics projects, FORTH fits the most hack value in the smallest space of any programming language ever developed. No question. If you're severely limited in your development environment (sentenced to 8 bit mircos, for example) then it's a wonderful choice. If you have to deal with big bucks, serious requirement specification, source code control, change tracking, ad nauseum, then I don't know how well FORTH would work. It really is designed for a *micro* system environment (not large, not medium, not mini, not small, but *micro*). My own rule of thumb: If you can't do it in a weekend, maybe you shouldn't do it in FORTH. Rick. smith@sctc.com Arden Hills, Minnesota
schweige@aldebaran.cs.nps.navy.mil (Jeffrey M. Schweiger) (04/18/91)
In article <11106@uwm.edu> wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) writes: > >Forth was born later than LISP. I don't think the designer of LISP knew >anything about Forth when he designed LISP. Because of the simplicity of >Forth, many people had developed variants of Forth, such as Fifth, Sixth, >... . I don't know any LISP written in Forth. But I do know there >is Prolog written in Forth. I've not used a version of Prolog written in Forth, so can't comment on it, but Prolog is not a variant of Forth, per se. According to "Prolog: A Relational Language and its Applications" by John Malpas, the first Prolog was written in Fortran, not Forth, in 1973 by Colmerauer and Roussel. I know that the first Prolog that I used was C-Prolog. -- ******************************************************************************* Jeff Schweiger Standard Disclaimer CompuServe: 74236,1645 Internet (Milnet): schweige@taurus.cs.nps.navy.mil *******************************************************************************
wlee@csd4.csd.uwm.edu (Wan Ngai Wayne Lee) (04/18/91)
From: smith@sctc.com (Rick Smith) >Chuck Moore developed FORTH about 10 years later. I forget just why >did it, but Kitt's Peak Observatory was an early and ardent user. Chuck got fed up with the software available to him at the time, so he developed Forth to do everything he needed to do in the observatory. Later, Forth became the official programming language for the Astronomical Union. >FORTH fits the most hack value in the smallest space of any programming >language ever developed. No question. If you're severely limited in your >development environment (sentenced to 8 bit mircos, for example) then >it's a wonderful choice. Forth designed based on Chuck's philosophy is inherently small, but some modern Forth are getting "fat". >If you have to deal with big bucks, serious requirement specification, >source code control, change tracking, ad nauseum, then I don't know >how well FORTH would work. It really is designed for a *micro* system >environment (not large, not medium, not mini, not small, but *micro*). Source code control can be a big problem if the programmer is not extremely well disciplined. Forth is designed to fit in a micro system but not for micro system. The original Forth is a multi-tasking and multi-user system. There are also distributed and multi-procersor Forth systems. >My own rule of thumb: >If you can't do it in a weekend, maybe you shouldn't do it in FORTH. If you can't do it with ________ in a weekend, maybe you should do it in Forth.
yoshi@nocusuhs.nnmc.navy.mil (Dojun Yoshikami) (04/19/91)
In article <1991Apr17.193144.15194@sctc.com> smith@sctc.com (Rick Smith) writes: >>> >>> I may be totally wrong in this but aren't FORTH and LISP close relatives? >>>It seems to me that FORTH was the foundation of LISP. ... >>>Is there anyone out there that can set me straight or re-enforce this?? > >John McCarthy developed LISP around 1956-57 and presented it as a >notation for fiddling with recursive functions on a computer. > >Chuck Moore developed FORTH about 10 years later. I forget just why >did it, but Kitt's Peak Observatory was an early and ardent user. He most certainly did. Forth has quite a few LISP'isms in it. Some words such as tick (') came from LISP, even though they work a bit differently in FORTH. >>> >>>Thanks, >>> >>>Monty Saine > >And yoshi@nocusuhs.nnmc.navy.mil (Dojun Yoshikami) writes: > [lots of stuff deleted. Hey, I should have put my flame suit on..] I forgot one of the biggest differences. With FORTH you don't have all those stupid parentheses. (You do, however, run the risk of killing yourself when you underflow the stack!) Unlike what you said about doing things in a weekend in Forth, many people have disobeyed that rule, to the common good of all involved, as FORTH has been successfully used in many LARGE systems, and continues to be used in large systems. One such large system controls an entire airport (It's described in JFAR, some time long ago), and another, an entire sonar training simulator which had stations for a trainer and a whole bunch of students. Both projects took more than a weekend. However, FORTH is NOT ALWAYS good for a LOT of large systems. Forth's failings with large systems generally stem from lacking all those things you find in Ada (No flames, please) that keep programmers from stepping on each other, and all those things you find in OS's that allow users to share data (sharing forth dictionaries can be problematic when security is involved). But that's not what Forth was designed for. I agree, Forth seems to appear to run best on small microcomputer systems. But you can get PolyForth for the VAX, though, and that is what is usually referred to as a Large Mini (discounting micro-VAXen). Anyways, enough of this. We'll get nowhere yelling any more about what one language does and what it doesn't. Let's get back to the robotics instead, the REAL reason for this newsgroup. =-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= D M Yoshikami :-) ;-) :-) | Internet: yoshikami@usuhsb.ucc.usuhs.nnmc.navy.mil May the Forth be with you! | Bitnet : yoshikami@usuhsb.bitnet *** !!xob X*NU V METSYS T&TA eht ni renosirp dleh gnieb m`I !pleH !pleH *** =-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=