|Subject:||Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator|
|Date:||Sun, 24 May 2009 16:31:27 -0700|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:220.127.116.11) Gecko/20081105 Thunderbird/18.104.22.168 Mnenhy/0.7.5.0|
On 05/23/2009 05:53 PM, Jeff Chimene wrote:
In one paragraph: Implement changes to the COBOL compiler so that it generates object files that can be read by the GNU Debugger and linker. The compile-time system that generates the object files and the run-time system that uses the object files are organized in a threaded execution model.
About me: I have a bit of experience working with compilers that emit and run-time systems that use a threaded execution model. This experience comes from some Digital Equipment Corporation operating systems: RSTS/E and RSX (both PDP/11) and VMS (VAX/Alpha).
I'm not proposing implementing p-code or Forth. Such implementations are for run-time interpreters.
Here is the proposal from 30K feet:
The generated object files contain a list of routines (the thread). These routines are currently defined in the COBOL run-time library (cob1). I would add a second library to handle the routines described below in tasks two and three.
Run time execution establishes the initial environment then begins a loop (aka the "inner loop" or "address interpreter") that follows the execution thread by dispatching to the next routine in the thread. Interestingly, a very portable implementation of a direct threaded dispatch can be implemented in GNU C (see http://ebweb.tuwien.ac.at/gnu-docs/gcc/gcc_58.html for the reference source and more information on threaded code):
This is one of GNU C's extensions to standard C, and it is currently the most portable method for implementing threaded code. A similar feature is FORTRAN's computed goto. In GNU C, a direct threaded NEXT looks like this:typedef void *Inst; Inst *ip; /* you should use a local variable for this */ #define NEXT goto **ip++
The initial task list:
There is no "outer loop" or "text interpreter": this is not an interpreter design;
The term "address interpreter" may be misleading. Symbol resolution will be handled at run-time by the operating system's loader
|[Prev in Thread]||Current Thread||[Next in Thread]|