gnucobol-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Chimene
Subject: Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object module generator
Date: Mon, 25 May 2009 14:21:32 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.18) Gecko/20081105 Thunderbird/2.0.0.18 Mnenhy/0.7.5.0

On 05/25/2009 02:06 PM, Ron Norman wrote:
Other things to consider:
  A LINKAGE SECTION item can be declared as 
  01 MYPARAM PIC X ANY LENGTH. 
And the subroutine code can then do  
  MOVE LENGTH OF MYPARAM TO XXX.
I.e. the length of each parameter also needs to be encoded someplace.
Also you can do interesting things like  
   SET ADDRESS OF MYPRMX TO ADDRESS OF MYOTHERDATA.
   CALL "XYZ" USING MYPRMX, LOCALDATA.

Also, subroutines may be called with different number of parameters on
different calls to the same routine. (This was common practice on S/370
systems.)

I have OpenCOBOL as a supported COBOL compiler for my company's OLTP
system and being able to pass different number of parameters to our API
library (all C code) and having it be able to figure out how many
parameters were passed and the length of each parameter is very
important.
  

Agreed. The current parsing subsystem is able to convert COBOL to C, so it knows how to translate the parameter passing mechanism. The proposal relies on the current parsing subsystem.

Things quickly get complicated...

zLINUX is Linux on a Z Series (i.e. S/370) and OpenCOBOL could very
easily be running on a zLINUX system, Intel system, Sparc, Itanium,
etc...
Some people have also ported OpenCOBOL Windows using CYGWIN or something
similar.
  

Right. As I mentioned at the close of the last post: this implementation requires an architecture-independent parameter passing mechanism. The current parsing mechanism handles the translation to C for variable length argument lists as well as call by reference.

To emphasize the point: the proposal requires the development of an architecture-independent parameter passing mechanism. All of your examples are encompassed in the current parsing subsystem. Each production referenced in the parser would be addressed in the analysis and design tasks.

Cheers,
jec
Cheers
Ron Norman


-----Original Message-----
From: Jeff Chimene [mailto:address@hidden] 
Sent: May 25, 2009 4:40 PM
To: Ron Norman; address@hidden
Subject: Re: [open-cobol-list] Proposed addition to OpenCOBOL: an object
module generator

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.
   

    

  


reply via email to

[Prev in Thread] Current Thread [Next in Thread]