[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module g
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator
Mon, 25 May 2009 13:39:53 -0700
Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) Gecko/20081105 Thunderbird/22.214.171.124 Mnenhy/0.7.5.0
On 05/25/2009 12:04 PM, Ron Norman wrote:
Ok, I think I understand…
So if the hardware was say an IBM 370, the code would be something like:
MAIN DS 0A
PERFORMA DS 0A
. . .
Plus much much more detail.
Then your “inner interpreter” would basically trip thru the code
calling routines and passing parameters as required for things like
MOVE, COMPUTE, CALL, READ/WRITE etc…
Do I have it right?
My original example needs amending to address your example. My original
example was all calls to cob1, with no concern for user-written code. As
such, it was a bad example. Let me try and merge the two. this example
mixes code and data, which shouldn't happen in practice.
MAIN DS 0A
DC A(COBRTL_PUSH) one example
DS 8F ... of parameter passing
P1 DS 8F
P2 DS 4B
DC A(COBRTL_PERFORM) yet another example of
DC A(PERFORMB) ... parameter passing
P1 DS 0F
P2 DS 0B
DC A(COBRTL_GET_ARG_WORD) These GET_ARG routines either find
DC A(P1) ... values on a virtual stack
DC A(COBRTL_GET_ARG_HALFWORD) ... or by referring to the call
COBRTL_PERFORM would read its arguments using an artificial,
architecture-independent parameter passing mechanism.
Extending the example to include parameters is important. It's also
important that your example is the S/370 as it is an architecture that
doesn't have a stack. It's clear that this design will have to include a
parameter passing mechanism that doesn't rely on a hardware stack.
There could be no architecture-specific parameter passing mechanisms. It
may be that such a concession is a deal-breaker.
*From:* Jeff Chimene [mailto:address@hidden
*Sent:* May 25, 2009 2:47 PM
*To:* Ron Norman
*Subject:* Re: [open-cobol-list] Proposed addition to OpenCOBOL: an
object module generator
For future, I'd prefer to keep this discussion on the list.
Other comments in line.
On 05/25/2009 11:32 AM, Ron Norman wrote:
The module format COFF vs ELF is a minor issue compared to which machine
instruction set would be used.
Agreed. That's why I omitted it from the proposal.
In the proposed model, the executable code is all C.
As for the proposed object file, when decoded to assembler, it might
look something like:
The concept is that a C routine (aka the "inner interpreter") calls
the routines (also written in C, in the current cob1 library and a TBD
library). There needs to be additional code that replaces the current
C code emitted by the COBOL compiler, The new C code will handle
branching and data structures (data definition, working storage). That
new code would be in the TBD library.
To reiterate, all code that must be portable is written in GNU C. The
object file output by the COBOL compiler contains no executable code,
only pointers to routines in cob1 and another TBD library. The
organization of these pointers is commonly referred to as a "thread".
From: Jeff Chimene [mailto:address@hidden
Sent: May 25, 2009 11:16 AM
Subject: Re: [open-cobol-list] Proposed addition to OpenCOBOL: an
On Mon, May 25, 2009 at 6:15 AM,Ron Norman <address@hidden> <mailto:address@hidden> wrote:
Just my 2 cents, but GNU C does generate object modules on the
Agreed. One of the proposal's goals is to generate object files that
represent compiled COBOL code as opposed to compiled C code.
If OpenCOBOL generated the object module directly then it needs to
the many different hardware platforms, Intel x86,Itanium,PA-Risc,
The object module format would be COFF. That /should/ be portable
across those systems.
GNU C does have some internal features which seem to allow GOTO and
Agreed. However, I don't suggest transforming the current C code into
GOTO to be implemented.
threaded C code. I am suggesting using the theaded model in object
files. The run-time system uses the GNU C syntax for indirect jumps to
follow the thread.
I waiting for feedback from him on this proposal.
Roger While would know better than I.
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, Jeff Chimene, 2009/05/25
Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator, Brian Tiffin, 2009/05/25