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)

Buzz McCool <[email protected]> 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)

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)

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