Just my 2 cents, but GNU C does generate
object modules on the platform in use.
If OpenCOBOL generated the object module
directly then it needs to deal with the many different hardware platforms,
Intel x86, Itanium, PA-Risc, PowerPC, SPARC, etc…
GNU C does have some internal features
which seem to allow GOTO and computed GOTO to be implemented.
Roger While would know better than I.
Cheers
Ron
Norman
From: Jeff Chimene [mailto:address@hidden
Sent: May 24, 2009 7:31 PM
To:
address@hidden
Subject: Re: [open-cobol-list]
Proposed addition to OpenCOBOL: an objectmodule generator
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:
- Add a command line argument that invokes object
file generation
- Analyze the generated C code that implements
branch control. Design and implement the branch control routines
- Analyze the generated C code that implements
memory management (working storage, data descriptions). Design and
implement the memory management routines
- 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.
- Branch the current parser
- Modify the parser branch co-routines to generate
object records in place of C code. This includes generating debug symbol
table information
- 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