Re: Embedding wishlist

[Anton Ertl]

On Mon, Feb 06, 2023 at 07:09:49PM -0600, Ulf Herrman wrote:
> I'm considering embedding gforth in a C program that uses an event
> loop. I need to be able to suspend the current forth task and return to
> C. I *think* the right primitive for this is (bye), unless I'm
> mistaken. But once it's been suspended, I'd like to be able to resume
> it. This could be done by having a forth wrapper word around (bye) which
> will push the succeeding ip onto the return stack, and then executing
> EXIT when it's time to resume. But I'd like it if I could resume
> directly from what invoked (bye). I see that there's a saved_ip, but is
> it current after returning from gforth_engine? I don't see a place where
> it would be kept up to date... would (bye) have to be modified to store
> it?

saved_ip is kept current in the engine gforth (through the macro NAME
called at the start of every primitive), but not in gforth-fast.  It's
there in order to report the primitive that caused an exception when
producing a backtrace.  If you want to go through (bye), the idea of
wrapping it in a colon definition, and then continuing at a ;S (the
primitive for EXIT) sounds good.

For resuming you also need to save the stack pointers and restore them
on returning.

You can call a C function from within Gforth using the C interface.
If you can arrange your C program such that you can call the C parts
as a function rather than as a coroutine, that would be the way to go.

Otherwise you can

a) look for a C library for coroutining or somesuch, and call that, or

b) pursue the approach of calling (BYE), saving and then restoring the
   stack pointers and IP there.

c) you could also try the approach of calling (BYE), but somehow
   arrange to get the stack pointers saved in a C structure
   "stackpointers" (possibly by calling a dummy C functionthat you then pass to 
gforth_engine for resuming.
   


> Also, it would be nice if gforth could be initialized without having to
> install signal handlers.
> 
> It would also be nice if gforth_stacks could be instructed to leave out
> the guard pages and page-alignment requirements. This would allow for
> tasks that are known to only require small stacks to be very compact. At
> present this isn't even configurable at compile-time: totalsize is
> always at least 10 pages large.

It seems that you want to replace some parts of the Gforth
initialization with your own.  With the development Gforth this is
entirely possible and I think you do not even need a change to Gforth
source code.  You just need to do your own main (which you will do
anyway), link with engine/libgforth.la (or engine/libgforth-fast.la
etc.), perform your initialization and eventually call
gforth-engine().

- anton