1. Forum
  2. Newsgroups
  3. comp.lang.forth

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

    From Buzz McCool@buzz_mccool@yahoo.com to comp.lang.forth on Tue Feb 11 14:07:42 2025
    From Newsgroup: comp.lang.forth

    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." :-)


    --- Synchronet 3.20c-Linux NewsLink 1.2
  • From Paul Rubin@no.email@nospam.invalid to comp.lang.forth on Tue Feb 11 14:37:24 2025
    From Newsgroup: comp.lang.forth

    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?
    --- Synchronet 3.20c-Linux NewsLink 1.2
  • From Buzz McCool@buzz_mccool@yahoo.com to comp.lang.forth on Tue Feb 11 18:06:08 2025
    From Newsgroup: comp.lang.forth

    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.


    --- Synchronet 3.20c-Linux NewsLink 1.2
  • From minforth@minforth@gmx.net (minforth) to comp.lang.forth on Wed Feb 12 07:53:49 2025
    From Newsgroup: comp.lang.forth

    "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.
    --- Synchronet 3.20c-Linux NewsLink 1.2
  • From Hans Bezemer@the.beez.speaks@gmail.com to comp.lang.forth on Sun Feb 16 19:06:12 2025
    From Newsgroup: comp.lang.forth

    On 12-02-2025 03:06, Buzz McCool wrote:
    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.
    That was the original idea of 4tH - a scripting language for a C
    application. As a matter of fact, the different 4tH incarnations were originally meant as "example programs" for the library.

    Nowadays, everybody thinks it's "the 4tH compiler". Wrong.. Although in
    a sense it became somewhat true..

    Every 4tH incarnation is a testament to the original idea, since every
    single one of them contains embedded 4tH:

    4th - the block editor;
    4tsh - the command line;
    pp4th - the entire preprocessor.

    The program in question is saved as a compressed applet. When invoked,
    it creates a sandbox - according to the applet's specifications - and
    executes the applet. When it quits, it discards the entire sandbox.

    You can also compile and execute an external script (as long as you link
    in the compiler as well, of course).

    Hans Bezemer


    --- Synchronet 3.20c-Linux NewsLink 1.2