Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator

[Jeff Chimene]

On 05/23/2009 05:53 PM, Jeff Chimene wrote:

Hi,

Would there be any interest in adding an object module generator to OpenCOBOL?

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"[1] or "address interpreter"[2]) 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:

1. Add a command line argument that invokes object file generation
2. Analyze the generated C code that implements branch control. Design and implement the branch control routines
   
3. Analyze the generated C code that implements memory management (working storage, data descriptions). Design and implement the memory management routines
4. Analyze the existing COBOL run-time library. Define threads for the entry points. Each thread should be the external symbol reference. In other words, call the existing RTL entry point after establishing the call frame. No changes should be necessary to the existing run-time library.
5. Branch the current parser
   
6. Modify the parser branch co-routines to generate object records in place of C code. This includes generating debug symbol table information
7. Modify the parser branch co-routines to generate object records in place of C calls to cob1. This includes generating debug symbol table information

Note that this task list does not include changes to cob1. I would add a separate run-time library for the routines described above in tasks two and three.

[1]
    There is no "outer loop" or "text interpreter": this is not an interpreter design;
[2]
    The term "address interpreter" may be misleading. Symbol resolution will be handled at run-time by the operating system's loader