1. Forum
  2. Usenet
  3. COMP.LANG.FORTH

  • Build Forth interpreter into a C/C++ application

    From Buzz McCool@21:1/5 to All on Tue Feb 11 14:07:42 2025
    I happened to be reading an interview of Tom Zimmer https://jimlawless.net/blog/posts/zimmer/ in which he states:

    "When I work with other C programmers on large projects, I always build
    in a Forth interpreter into the application, for debugging purposes. The hardware guys love it, because it gives them so much power to figure out
    what is going on with the hardware. For software debugging, it is great
    because it gives you an interactive method of figuring out how to talk
    to the hardware before going off and writing a driver in C."

    Would anyone have a "Hello, World!" type example of this technique?

    I do see
    https://gforth.org/manual/Integrating-Gforth.html
    which ends with an ominous "More documentation needs to be put here." :-)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Paul Rubin@21:1/5 to Buzz McCool on Tue Feb 11 14:37:24 2025
    Buzz McCool <buzz_mccool@yahoo.com> writes:
    I happened to be reading an interview of Tom Zimmer https://jimlawless.net/blog/posts/zimmer/ in which he states:

    "When I work with other C programmers on large projects, I always
    build in a Forth interpreter into the application, for debugging
    purposes....
    Would anyone have a "Hello, World!" type example of this technique?
    I do see https://gforth.org/manual/Integrating-Gforth.html which ends
    with an ominous "More documentation needs to be put here." :-)

    I think these days the approach is less useful because of the
    availability of external debuggers. C programmers these days are
    comfortable with GDB, which gives source level debugging and
    breakpoints. I'd be interested to know if any integrated Forth
    debuggers supported that.

    Gforth is quite heavyweight by Forth standards and if you wanted to use
    Forth that way, you might be happier with something like pForth. Is the
    idea to stop the application while poking around with Forth, or would
    Forth be a task under an RTOS, or what?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Buzz McCool@21:1/5 to Paul Rubin on Tue Feb 11 18:06:08 2025
    On 2/11/25 14:37, Paul Rubin wrote:
    ... Is the
    idea to stop the application while poking around with Forth, or would
    Forth be a task under an RTOS, or what?

    I'm unclear on the whole concept Tom Zimmer was advocating so I was
    asking if anyone had examples.

    I have a bare metal type embedded system I'm working on where I can
    command it from Ethernet. It has a serial console port. Maybe your first
    idea would be an example where I could command it to stop and jump into
    a Forth ok prompt so I could type commands into the serial port and see
    debug output there.

    Your second idea is along the lines of the Gforth/ATLAST concept where
    Forth is a scripting language for a C/C++ application. I have another
    Linux based embedded system that has some pieces that are always
    changing. Maybe a Forth task inside a C/C++ program that would pick up changeable scripts from the SD Card would be better than constantly
    recompiling my C/C++ application and re-flashing main memory.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From minforth@21:1/5 to All on Wed Feb 12 07:53:49 2025
    "Once upon a time" we had controllers installed in remote
    industrial sites that could be teleserviced via modem line.
    The controllers had a small Forth system as Trojan horse
    for issuing system commands and diagnostics e.g hex dump of
    buffers.

    It was an embedded system maintenance tool, but not a debugger.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)