Loading ...
Sorry, an error occurred while loading the content.

[SeattleRobotics] Re: Forth for Robots

Expand Messages
  • PeterBalch
    Dan ... It sounds to me like it s a matter of how they re implemented. The Forths I ve seen have compiled to lists of Push, Pop and (low level) function calls.
    Message 1 of 12 , Feb 3, 2008
    • 0 Attachment
      Dan

      > I did some benchmarking between C and Forth in the old days, and
      > execution speeds were very comparable. I had always wondered why
      > the "threaded structure" of Forth, where the words are really just
      > lists of pointers and not executable code per se, could be nearly as
      > fast executing as C routines, which are mainly all code. It sounds
      > like the more efficient operation of the Forth data stack may be the
      > answer, in that this efficiency compensates for inefficiency of
      > threading through lists of pointers before reaching the actual
      > executable code, down at the bottom.

      It sounds to me like it's a matter of how they're implemented. The Forths
      I've seen have compiled to lists of Push, Pop and (low level) function
      calls. The list is either interpreted of, perhaps, executed directly.

      A C procedure call should compile to almost identical code to a Forth
      procedure call. After all, both just push the parameters and return address
      on the stack (or on two stacks for Forth).

      Bur a C statement like A=B+C should be compiled to three instructions. The
      equivalent Forth code:
      Push address of A
      Push value of B
      Push value of C
      Add
      Assign
      would compile to five function calls; each function would then execute
      maybe half a dozen instructions. There's no way that will ever be as fast
      as C. The same argument applies to FOR or array access or whatever.

      A badly implemented C compiler for a PIC might produce really slow
      inefficient code. A very clever Forth compiler for a stack-based
      instruction set (e.g 80x86) might produce 5 instructions from the example
      above.

      But in general, Forth will always be slightly slower than good C code and
      will usually be a lot slower.

      How many Forth compilers produce code that does much beyond call low-level
      functions?

      > Actually, I was referring to a shell
      > program that could interactively test a given routines or set of
      > routines, by being able to call them and execute them with selectable
      > parameters, and immediately being able to analyze the results. Kind
      > of like having a keyboard interpreter in Forth :).

      Interesting.

      In the majority of C (or, in my case, Delphi) programs, a function only
      makes sense in the context of the whole program. And can only reasonably be
      called in the middle of executing the whole program. I've just looked at a
      typical program and, for the majority of functions, it would make no sense
      to call those functions from the keyboard. I suppose you could put a
      breakpoint in a program and, when it stops, then start calling functions.
      (I've never felt the need to do that because the Delphi compiler is so
      fast, I'd just insert a function call into the source and do a compile/run.
      But for a robot, it's not so easy.)

      Your suggestion seems to be that Forth functions are somehow less context
      dependant. That they're all "top level" functions. How can that be?

      Peter
    • dan michaels
      ... selectable parameters, and immediately being able to analyze the results. Kind of like having a keyboard interpreter in Forth :). ... only makes sense in
      Message 2 of 12 , Feb 3, 2008
      • 0 Attachment
        --- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
        wrote:
        >


        > > Actually, I was referring to a shell
        > > program that could interactively test a given routines or set of
        > > routines, by being able to call them and execute them with
        selectable parameters, and immediately being able to analyze the
        results. Kind of like having a keyboard interpreter in Forth :).
        >
        > Interesting.
        >
        > In the majority of C (or, in my case, Delphi) programs, a function
        only makes sense in the context of the whole program. And can only
        reasonably be called in the middle of executing the whole program.
        I've just looked at a typical program and, for the majority of
        functions, it would make no sense to call those functions from the
        keyboard. I suppose you could put a breakpoint in a program and, when
        it stops, then start calling functions. (I've never felt the need to
        do that because the Delphi compiler is so fast, I'd just insert a
        function call into the source and do a compile/run.
        > But for a robot, it's not so easy.)
        >
        > Your suggestion seems to be that Forth functions are somehow less
        context dependant. That they're all "top level" functions. How can
        that be?
        >
        > Peter
        >


        To answer the last question first, since all Forth words
        incrementally compile above, and call as required, words previously
        compiled into the dictionary, they do effectively act as "top level"
        words, in a given context. You can only define a Forth word in terms
        of those previously defined.

        Secondly, as regards the statement "for the majority of functions, it
        would make no sense to call those functions from the keyboard", I
        don't think this is true if you're doing real modular programming.

        Rather, real "modules" tend to be standalone to some extent, meaning
        loose control and data coupling with other modules, and largely are
        passed data+control parameters from above, do their work and also
        call modules "below", and then pass something back, or else modify
        memory and/or flags.

        With such a scenario, it really helps during the test+integrate
        phases if you can test such modules in isolation from the rest of the
        program. With the Forth interactive keyboard interpreter capability,
        you can easily set flags and send in a wide range of parameters, and
        immediately check the outputs. You can also easily perform benchmark
        timing on your individual modules.

        To do something like this with a typical C IDE requires writing a
        specific test program, which is probably as much, or more, trouble as
        writing the original code module in the first place.

        In short, modular development profits from being able to do extensive
        modular testing in an efficient manner.
      • Dave Hylands
        Hi Peter, ... GDB (the GNU source code debugger) will allow you to call arbitrary C functions from within the debugger. In fact, you can even patch code and
        Message 3 of 12 , Feb 3, 2008
        • 0 Attachment
          Hi Peter,

          > In the majority of C (or, in my case, Delphi) programs, a function only
          > makes sense in the context of the whole program. And can only reasonably be
          > called in the middle of executing the whole program. I've just looked at a
          > typical program and, for the majority of functions, it would make no sense
          > to call those functions from the keyboard. I suppose you could put a
          > breakpoint in a program and, when it stops, then start calling functions.
          > (I've never felt the need to do that because the Delphi compiler is so
          > fast, I'd just insert a function call into the source and do a compile/run.
          > But for a robot, it's not so easy.)

          GDB (the GNU source code debugger) will allow you to call arbitrary C
          functions from within the debugger. In fact, you can even patch code
          and setup breakpoints which will call a function or evaluate an
          expresison everytime a particular line of code is hit.

          Admittidly, with todays fast tools, I often just rebuild (like you
          mentioned elsewhere).

          The most useful functions to execute are often the ones that just
          print a bunch of information about a particular structure or object.

          --
          Dave Hylands
          Vancouver, BC, Canada
          http://www.DaveHylands.com/
        • PeterBalch
          George ... Not quite. The Coral and Fortran languages were specified such that they could be implemented without the need for a stack. And, afaik that s how
          Message 4 of 12 , Feb 5, 2008
          • 0 Attachment
            George

            > I was only following your lead. You claimed that Coral and Fortran
            > didn't use a stack, but there you've confused the implementation of
            > specific compilers with the semantics of the languages. You also have
            > repeatedly stated that C is a "stack-based" language but that again is
            > confusing the implementation of the compilers with the semantics of
            > the language.

            Not quite. The Coral and Fortran languages were specified such that they
            could be implemented without the need for a stack. And, afaik that's how
            they always were implemented (up to Fortran IV).

            The C language is specified such that it must be implemented with a stack.
            If I were to implement a C compiler that didn't use a stack, it would not
            be real C.

            > > Assembly and/or C are good solutions for simple uCs.
            > >
            > > C on a simple uC? With a stack? Not a good solution. Statically
            > > allocated C
            > > (i.e. Coral) with no stack. Yes, a good solution.
            >
            > "Good" means different things to different people. I've found assembly
            > and/or C to be good solutions for my applications on small micros.

            The (few) C compilers I've seen for 16F PICs have produced poor quality
            code because they assumed that the local variables must be on a stack. 16F
            PICs are really very inefficient for stack-based coding.

            Maybe there are C compilers that use static allocation for local variables
            and parameters. Do you use such a compiler? Can you provide an example of
            its output?

            Peter
          • PeterBalch
            Alan ... As Randy pointed out, the Dictionary can be on the PC. The PIC need only ever see compiled code. And if it were me, I d put the Forth code in Flash
            Message 5 of 12 , Feb 5, 2008
            • 0 Attachment
              Alan

              > So 3.9K is not enough for the dictionary? I did just find the
              > PIC18Forth, but I haven't researched it enough to know what they are
              > doing. For all I know, they are adding external RAM as you describe.
              >
              > But does the dictionary have to be in RAM? Can the static "core" of the
              > dictionary be put in Flash?

              As Randy pointed out, the Dictionary can be on the PC. The PIC need only
              ever see compiled code.

              And if it were me, I'd put the Forth code in Flash not RAM. That way, each
              Forth word can be a CALL (I think the 18F can't execute from RAM - right?
              and the 18F is self-programming?). It does mean that your interactive
              editing is continually overwriting Flash and Flash has a write-limit of
              10,000 times. A good implementation of Forth could ensure that you're not
              always overwriting the _same_ region of Flash and if your chip dies after a
              year, well, they're cheap to replace.

              Peter
            • dan michaels
              ... are doing. For all I know, they are adding external RAM as you describe. ... of the dictionary be put in Flash? ... only ever see compiled code. ... What
              Message 6 of 12 , Feb 5, 2008
              • 0 Attachment
                --- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
                wrote:
                >
                > Alan
                >
                > > So 3.9K is not enough for the dictionary? I did just find the
                > > PIC18Forth, but I haven't researched it enough to know what they
                are doing. For all I know, they are adding external RAM as you
                describe.
                > >
                > > But does the dictionary have to be in RAM? Can the static "core"
                of the dictionary be put in Flash?
                >
                > As Randy pointed out, the Dictionary can be on the PC. The PIC need
                only ever see compiled code.
                >



                What you apparently mean is the editor/compiler part of the
                dictionary.



                > And if it were me, I'd put the Forth code in Flash not RAM. That
                way, each
                > Forth word can be a CALL (I think the 18F can't execute from RAM -
                right?
                > and the 18F is self-programming?). It does mean that your
                interactive
                > editing is continually overwriting Flash and Flash has a write-
                limit of
                > 10,000 times. A good implementation of Forth could ensure that
                you're not
                > always overwriting the _same_ region of Flash and if your chip dies
                after a
                > year, well, they're cheap to replace.
                >
                > Peter
                >
              • Alan KM6VV
                Hi Peter, I don t know where all the tools reside on a Forth development for a uP (PIC). I know the IDE-PC, ICD2-PIC board development environment. I m
                Message 7 of 12 , Feb 5, 2008
                • 0 Attachment
                  Hi Peter,

                  I don't know where all the tools reside on a Forth "development" for a
                  uP (PIC). I know the IDE-PC, ICD2-PIC board development environment.
                  I'm hearing that Forth doesn't really maintain "source code" like I'm
                  familiar with. It sounds like once a word is compiled, it gets added to
                  the dictionary and is lost; but I'm sure I've got parts of that wrong.

                  Can't a core (minimal) Forth run on the uP, and the program be developed
                  there with the PC only being used as a terminal? OK, maybe save off
                  something that looks like source code?

                  I don't think the 18F can run from RAM, as you've observed. It CAN
                  program it's self. If the Dictionary can be incrementally built up with
                  words, then one could "test" a word in RAM, then "commit" it to EEPROM
                  (on board Flash or off board EEPROM) after the tested word was OK.
                  Maybe someone has already done this. This shouldn't be too much of a
                  stretch for EEPROM life.

                  So somewhere someone has probably already done this!

                  Alan KM6VV
                  P.S. I sent two files for your perusal. I think you can see the
                  details of a call(). No real overhead that I can see. Returns should
                  be simple as well. Pardon my "hack" approach to this program file; I'm
                  not sure where it's going yet. It does have a simple main, all simple
                  calls()! No math, either.


                  PeterBalch wrote:

                  >As Randy pointed out, the Dictionary can be on the PC. The PIC need only
                  >ever see compiled code.
                  >
                  >And if it were me, I'd put the Forth code in Flash not RAM. That way, each
                  >Forth word can be a CALL (I think the 18F can't execute from RAM - right?
                  >and the 18F is self-programming?). It does mean that your interactive
                  >editing is continually overwriting Flash and Flash has a write-limit of
                  >10,000 times. A good implementation of Forth could ensure that you're not
                  >always overwriting the _same_ region of Flash and if your chip dies after a
                  >year, well, they're cheap to replace.
                  >
                  >Peter
                  >
                  >
                • PeterBalch
                  Alan ... According to Randy, Dan, Dave, et al, it depends on the implementation. ... It can be recovered from the dictionary. Forth words can easily be
                  Message 8 of 12 , Feb 6, 2008
                  • 0 Attachment
                    Alan

                    > I don't know where all the tools reside on a Forth "development" for a
                    > uP (PIC).

                    According to Randy, Dan, Dave, et al, it depends on the implementation.

                    > I'm hearing that Forth doesn't really maintain "source code" like I'm
                    > familiar with. It sounds like once a word is compiled, it gets added to
                    > the dictionary and is lost; but I'm sure I've got parts of that wrong.

                    It can be recovered from the dictionary. Forth words can easily be
                    de-compiled back into source. (Some very fast Forths replace words with
                    actual assembler code; presumably that can't be de-compiled. Randy argued
                    that decompilation didn't always work but the IF example he provided was
                    easy to decompile. Given that almost every Forth textual token compiles to
                    a word, decompilation ought to be trivial.)

                    The Forth "dictionary" contains the bodies of each of the functions defined
                    in your source. It could also contain the textual name of each function.
                    Alternatively, the textual names could be held on the host PC. But then
                    you'd have to worry about whether the dictionaries on the two systems had
                    got out of sync.

                    > If the Dictionary can be incrementally built up with
                    > words, then one could "test" a word in RAM, then "commit" it to EEPROM
                    > (on board Flash or off board EEPROM) after the tested word was OK.
                    > Maybe someone has already done this.

                    It depends on how the Forth is implemented. Either you have an array of
                    "words" which the interpreter reads and interprets. Or you have a sequence
                    of CALLs. CALLs are faster but an 18F can't have CALLs in RAM. So if you
                    want to do it the way you suggest and use CALLs, you'd need an interpreter
                    that can handle both kinds of "words".

                    [Of course, things get more complicated when you re-define one of your
                    existing functions 'FRED'. All the old functions that called 'FRED' must
                    now be updated to point at the new 'FRED' which might be in RAM instead of
                    flash. Either you need to re-link on the fly or make it illegal to
                    re-define flashed functions. That's why in some Forth implementations, the
                    words in the program point into an indirection-table which points to the
                    latest version of each function; that way, there's no need to re-link, you
                    only have to update the indirection-table.]

                    Peter
                  • PeterBalch
                    Randy, Dan, Dave OK. So far you ve convinced me that the interactivity of Forth is potentially attractive. So I ve started to try to imagine how I would use it
                    Message 9 of 12 , Feb 7, 2008
                    • 0 Attachment
                      Randy, Dan, Dave

                      OK. So far you've convinced me that the interactivity of Forth is
                      potentially attractive. So I've started to try to imagine how I would use
                      it in my development.

                      My uC programs always have the same structure:
                      declaration of global variables
                      declaration of functions
                      initialisation of variables and the chip's "peripherals"
                      MAINLOOP:
                      code for main loop
                      goto MAINLOOP

                      So I tend to poll rather than use interrupts if I possibly can.

                      The main loop contains a few function or macro calls. (As I've said, I use
                      my own Basic compiler. It includes macros. I use macros a lot for
                      hierarchical decomposition because they have zero overhead.)

                      The whole program is probably doing several tasks and they're all
                      interleaved by being polled in the main loop. Each task requires its own
                      its own global variables, its own declaration of functions, its own
                      initialisation and its own polling in the main loop. I try to develop all
                      the code for one task then all the code for the next and so on but often
                      they're interdependent so they all advance together. I don't suppose my way
                      of developing is much different from everyone-else's.

                      How will Forth help me?

                      When I want to alter some of the code for task A, it will need some global
                      declarations. Presumably global declarations are done in the beginning part
                      of a forth program. So how could they be changed without having to
                      recompile all the beginning part code? Would there then be an
                      initialisation function? If I add extra initialisation code, I'd have to
                      recompile it all. And similarly for the main polling loop.

                      None of this is a problem if I re-compile every time. I'm trying to
                      understand how it can easily be done with incremental compilation. (If I
                      recompile everything every time then I've lost the advantage of Forth.)

                      A lot of the coding I'm doing has to be in assembler because it's time
                      critical (measured in uSec) so that will be done in assembler. I can
                      understand how the incremental compiling of Forth might (or might not)
                      allow for incremental coding of assembler. I might take me 20 or 50
                      attempts to get some really critical code right. How will Forth help?
                      Today, I was getting some code working that required me to use one of the
                      PIC Timers. So I needed to set up the timer in the initialisation section
                      then respond to the timer overflow in the polling loop. I couldn't just
                      have a simple Forth timer function. After a while, I decided I'd be better
                      off using Timer0 rather than Timer1 so, had I been using Forth, how would I
                      have modified those two sections? How much work could I do in "incremental"
                      mode?

                      If Forth allows for incremental coding of assembly language functions then
                      presumably the Forth IDE includes an assembler. I currently write my
                      time-critical parts using my Basic compiler (it produces tight code). If I
                      switch to Forth, presumably I'd have to go back to assembler. Yuck.

                      Part of my program is not time critical - the "logic" part rather than the
                      "h/w interface" part. That could be written in Forth. But I find the
                      "logic" part is the easiest part. The part I can write quickly and soon get
                      right. So although Forth would speed that part up, it wouldn't make a huge
                      difference to the overall development time. The "logic" part of the main
                      loop would have to co-exist with the time-critical parts of the main loop.
                      How would that work?

                      Most of my code relies on the main loop executing within a few hundred uS
                      or a few mS. If parts of the main loop are written in Forth, it would be
                      about 20x slower (from your example) so I'd probably have to start doing
                      lots of work inside an interrupt handler. How useful would Forth be there?

                      You can see that I'm having a hard time understanding how Forth will make
                      my life (or yours) better.

                      Peter
                    • dan michaels
                      ... Hi Peter. You re kind of jumping around a lot below. I haven t used Forth on a microcontroller - that s really Randy s thing. I used it on a PC, and didn t
                      Message 10 of 12 , Feb 7, 2008
                      • 0 Attachment
                        --- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
                        wrote:
                        >


                        Hi Peter. You're kind of jumping around a lot below. I haven't used
                        Forth on a microcontroller - that's really Randy's thing. I used it
                        on a PC, and didn't use real-time interrupts to any great extent. I
                        did use serial interrupts, but had Forth polling the OS serial data-
                        avail flag.

                        My version of Forth did have an assembler built-in, so I would
                        initially code up everything in Forth, and perform benchmark testing
                        on various routines, which was very easy to do using words like ".T".

                        Then I would recode time-critical routines in assembler, such as FFTs
                        and graphical displays [ie, the writing pixels parts]. This normally
                        amounted to a limited amount of code, and the user interface and non-
                        time critical code took most of the program space, and was still
                        written in Forth. To me, this was a great melding of optimized low-
                        level code where it was necessary, plus easier to write high-level
                        code for most of the program.



                        > Randy, Dan, Dave
                        >
                        > OK. So far you've convinced me that the interactivity of Forth is
                        > potentially attractive. So I've started to try to imagine how I
                        would use
                        > it in my development.
                        >
                        > My uC programs always have the same structure:
                        > declaration of global variables
                        > declaration of functions
                        > initialisation of variables and the chip's "peripherals"
                        > MAINLOOP:
                        > code for main loop
                        > goto MAINLOOP
                        >
                        > So I tend to poll rather than use interrupts if I possibly can.
                        >
                        > The main loop contains a few function or macro calls. (As I've
                        said, I use
                        > my own Basic compiler. It includes macros. I use macros a lot for
                        > hierarchical decomposition because they have zero overhead.)
                        >
                        > The whole program is probably doing several tasks and they're all
                        > interleaved by being polled in the main loop. Each task requires
                        its own
                        > its own global variables, its own declaration of functions, its own
                        > initialisation and its own polling in the main loop. I try to
                        develop all
                        > the code for one task then all the code for the next and so on but
                        often
                        > they're interdependent so they all advance together. I don't
                        suppose my way
                        > of developing is much different from everyone-else's.
                        >
                        > How will Forth help me?
                        >
                        > When I want to alter some of the code for task A, it will need some
                        global
                        > declarations. Presumably global declarations are done in the
                        beginning part
                        > of a forth program. So how could they be changed without having to
                        > recompile all the beginning part code? Would there then be an
                        > initialisation function? If I add extra initialisation code, I'd
                        have to
                        > recompile it all. And similarly for the main polling loop.
                        >
                        > None of this is a problem if I re-compile every time. I'm trying to
                        > understand how it can easily be done with incremental compilation.
                        (If I
                        > recompile everything every time then I've lost the advantage of
                        Forth.)
                        >
                        > A lot of the coding I'm doing has to be in assembler because it's
                        time
                        > critical (measured in uSec) so that will be done in assembler. I can
                        > understand how the incremental compiling of Forth might (or might
                        not)
                        > allow for incremental coding of assembler. I might take me 20 or 50
                        > attempts to get some really critical code right. How will Forth
                        help?
                        > Today, I was getting some code working that required me to use one
                        of the
                        > PIC Timers. So I needed to set up the timer in the initialisation
                        section
                        > then respond to the timer overflow in the polling loop. I couldn't
                        just
                        > have a simple Forth timer function. After a while, I decided I'd be
                        better
                        > off using Timer0 rather than Timer1 so, had I been using Forth, how
                        would I
                        > have modified those two sections? How much work could I do
                        in "incremental"
                        > mode?
                        >
                        > If Forth allows for incremental coding of assembly language
                        functions then
                        > presumably the Forth IDE includes an assembler. I currently write my
                        > time-critical parts using my Basic compiler (it produces tight
                        code). If I
                        > switch to Forth, presumably I'd have to go back to assembler. Yuck.
                        >
                        > Part of my program is not time critical - the "logic" part rather
                        than the
                        > "h/w interface" part. That could be written in Forth. But I find the
                        > "logic" part is the easiest part. The part I can write quickly and
                        soon get
                        > right. So although Forth would speed that part up, it wouldn't make
                        a huge
                        > difference to the overall development time. The "logic" part of the
                        main
                        > loop would have to co-exist with the time-critical parts of the
                        main loop.
                        > How would that work?
                        >
                        > Most of my code relies on the main loop executing within a few
                        hundred uS
                        > or a few mS. If parts of the main loop are written in Forth, it
                        would be
                        > about 20x slower (from your example) so I'd probably have to start
                        doing
                        > lots of work inside an interrupt handler. How useful would Forth be
                        there?
                        >
                        > You can see that I'm having a hard time understanding how Forth
                        will make
                        > my life (or yours) better.
                        >
                        > Peter
                        >
                      • PeterBalch
                        Dan ... So you d use the incremental compile facility to debug your assembler code? ... Well, Randy? As you can see from my questions in the previous post, I
                        Message 11 of 12 , Feb 11, 2008
                        • 0 Attachment
                          Dan

                          > My version of Forth did have an assembler built-in, so I would
                          > initially code up everything in Forth, and perform benchmark testing
                          > on various routines, which was very easy to do using words like ".T".
                          > Then I would recode time-critical routines in assembler,

                          So you'd use the incremental compile facility to debug your assembler code?

                          > I haven't used
                          > Forth on a microcontroller - that's really Randy's thing.

                          Well, Randy? As you can see from my questions in the previous post, I don't
                          really understand how Forth is used to develop a system that contains a lot
                          of time-critical code.

                          I can't do what Dan did and write it all in Forth then, when it's working,
                          re-code some of it so it runs faster. With time-critical code, it has to
                          run fast all the time. And it isn't as though you can write the all the
                          non-time-critical code first or all the time-critical code first. Their
                          development usually has to be interleaved.

                          Peter.
                        • dan michaels
                          ... testing on various routines, which was very easy to do using words like .T . Then I would recode time-critical routines in assembler, ... assembler code?
                          Message 12 of 12 , Feb 11, 2008
                          • 0 Attachment
                            --- In SeattleRobotics@yahoogroups.com, PeterBalch <PeterBalch@...>
                            wrote:
                            >
                            > Dan
                            >
                            > > My version of Forth did have an assembler built-in, so I would
                            > > initially code up everything in Forth, and perform benchmark
                            testing on various routines, which was very easy to do using words
                            like ".T". Then I would recode time-critical routines in assembler,
                            >
                            > So you'd use the incremental compile facility to debug your
                            assembler code?
                            >


                            Umm, I probably used the term "time-critical" differently from you.
                            You're talking more about "real-time" interrupt/timer type stuff,
                            while I was actually talking aobut code that could be significantly
                            speeded up by recoding into assembler. In my case, this included FFT
                            and graphics routines.

                            Regards debugging, to Forth, a word is just a word, regardless of
                            whether it's coded in Forth or in assembler. You can execute/test
                            either type directly from the keyboard interpreter.

                            OTOH, as I mentioned, I did everything on a PC, so I can't speak very
                            well for microcontroller implementations. Below, you're more or less
                            indicating that everything has to be in assembler, but I can't really
                            say. Forth is pretty efficient, and I imagine a lot of the code can
                            be written in high-level Forth, in which case it'll probably more
                            compact than assembler code, and which is one of the advantages of
                            Forth in the first place. You probably need to look at specific
                            implementations regarding interrupt handling.



                            > > I haven't used
                            > > Forth on a microcontroller - that's really Randy's thing.
                            >
                            > Well, Randy? As you can see from my questions in the previous post,
                            I don't really understand how Forth is used to develop a system that
                            contains a lot of time-critical code.
                            >
                            > I can't do what Dan did and write it all in Forth then, when it's
                            working, re-code some of it so it runs faster. With time-critical
                            code, it has to run fast all the time. And it isn't as though you can
                            write the all the non-time-critical code first or all the time-
                            critical code first. Their development usually has to be interleaved.
                            >
                            > Peter.
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.