My apologies are due Marcel Hendrix and the people who worked with him for speaking with a needlessly harsh tone about the type of project they worked on.
Thank you for pointing out lib.fs. It looks reasonably straightforward. It seems to have been written as a study tool to perfect the method, and never polished into a production tool.
As far as I can see--
The memory location of code for a procedure from a shared library cannot be known until the OS provides it on request at run-time, so the computer busywork to request and save the procedure address is unavoidable.
The OS would have to dispatch all procedure calls of shared code. Users must not touch shared system code, nor use non-standard entry points that could execute code not intended by the builders. I suppose the OS provides not procedure addresses, but indexes to internal procedure tables. Some overhead from OS dispatch is unavoidable.
Simple prepared function calls like icallN and fcallN provide only their prepared lists of argument types. Prepared argument lists of arbitrary type are myriad and not possible. During Forth compilation we would not have the C compiler to build the code for building the lists.
Could we use a single utility function of type void, with a generous
allotment of dummy arguments of any convenient type, and have Forth build argument lists as needed?
Ideally the dummy argument list would be an array of type void with a specified length. Could that be done in a C argument list? Somehow an image of the required list would be prepared, and somehow the image would be copied into the dummy list in the utility function stack frame. Then control would be transferred to the system library procedure dispatcher.
A fairly small set of Forth primitives would be needed to store data in the argument list image with C format, since Forth and C don't necessarily use the same internal data formats.
The stack frame of the utility function with its dummy argument list
does not exist until the function is called, so whatever tool copies the
prepared argument list image into the stack frame must operate within
the utility function and before control passes to the system dispatcher.
If writing to the memory in a C stack frame is possible, then a simple
memory move should serve. The required instructions might fit into a
small C macro and avoid subroutine overhead. Parameter list building
sounds messy, but I suppose we would synthesize something that every C function does anyway.
I think Forth could build a parameter list for a C stack frame. As far as I know, the C stack frame format is not specified, so we don't know whether common memory formats would be used for data in the stack. However, since C accepts possibly large and complex structures as function arguments (I think), the stack frame would probably use common data formats and memory alignments. If the C stack used special data formats, complicated objects would need long and messy format conversions at each procedure call, which would increase the notorious C function call overhead. For the same reason, ordinary function argument conversions (char to short, float to double, etc.) are probably performed only as needed for each use within the function. I seem to recall reading programming advice to copy a frequently used function argument into a declared variable, so the argument conversion would only have to be done once.
Does this look like a workable plan? I am a complete novice at C and
Linux coding, and would not be surprised if I overlooked something that
would halt the show. If this looks like it might work, trying it will progress slowly, but I really would like to use Forth for some pet projects that need tidy interfaces and graphics.
DA
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
