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

[Jeff Chimene]

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:
>
>   ENTRY MAIN
>
> MAIN DS 0A
>
>     DC A(SETUP)
>
>     DC A(PERFORMA)
>
>     DC A(PERFORMB)
>
>     END
>
>  PERFORMA DS 0A
>
>     DC A(CALL)
>
>     DC A(MYRTN)
>
>     DC A(P1)
>
>     DC A(P2)
>
>     DC A(NULL)
>
>  . . .
>
> 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_SETUP)

    DC    A(COBRTL_PUSH)    one example
    DS    8F ... of parameter passing

    DC    A(COBRTL_PUSH)
    DS    6B

    DC    A(COBRTL_PERFORM)
    DC    A(PERFORMA)

    P1    DS 8F
    P2    DS 4B
    DC    A(COBRTL_PERFORM)    yet another example of
    DC    A(PERFORMB)          ... parameter passing
    DC    A(P1)
    DC    A(P2)

    ENTRY PERFORMA

    P1    DS 0F
    P2    DS 0B

    DC    A(COBRTL_GET_ARG_WORD)    These GET_ARG routines either find 
their
    DC    A(P1)                     ... values on a virtual stack

    DC    A(COBRTL_GET_ARG_HALFWORD)  ... or by referring to the call 
linkage pointer
    DC    A(P2)

    DC    A(COBRTL_PERFORM)
    DC    A(MYRTN)
    DC    A(P1)
    DC    A(P2)
    DC    A(NULL)

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
>
> HI Ron:
>
> 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:
>
> .entry MAIN
> .extern SETUP
> .extern PERFORMA
> .extern PERFORMB
> .end
>
> 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".
>
> Cheers,
> jec
>
>
>
>   
>   
> -----Original Message-----
> From: Jeff Chimene [mailto:address@hidden
> Sent: May 25, 2009 11:16 AM
> To:Ron Norman
> Subject: Re: [open-cobol-list] Proposed addition to OpenCOBOL: an
> objectmodule generator
>   
> 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
> >      
> platform in
>    
> > use.
> >      
>   
> 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
> >      
> deal with
>    
> > the many different hardware platforms, Intel x86,Itanium,PA-Risc,
> >      
> PowerPC,
>    
> > SPARC, etc...
> >      
>   
> 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
> >      
> computed
>    
> > GOTO to be implemented.
> >      
>   
> Agreed. However, I don't suggest transforming the current C code into
> 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.
>   
>    
> > Roger While would know better than I.
> >      
>   
> I waiting for feedback from him on this proposal.
>