[Tiny-cobol-users] Re: Another observation about subroutines.

[Rildo P. <rpr...@ac...>]

Hi David,

On Mon, 6 Dec 1999, David Essex wrote:

> I think that there is another way of doing this. The only thing you need to
> pass is the references to the variables, not their
> descriptions(declarations). So your above example would be as follows.
> 
> [COBOL, calling program]
> PROGRAM-ID: main.
> ...
> WORKING-STORAGE.
> * variable definition
> 01 VAR1   PIC X(10).
> ...
> PROCEDURE-DIVISION.
> CALL "test" USING VAR1.
> 
> [C, called function(sub program)]
> // variable declaration(not definition)
> extern char var1[10];
> // Shouldn't char* be void* ? I am not sure.
> void test( char *var_buf ) { 
>    var1 = var_buf;
>    ...
> }

This is somewhat dangerous, as the C program don't really know the size of
the variable and could do anything, even write nulls to the end of the
variable (this belongs to another variable, of course).  I think it's
better to have the descriptor, so the function could be generalized.
If you don't need it, just make a dummy argument like (void *dummy1) to
receive the descriptor and ignore it.
Most of the library functions already require them, anyway.  
When we make the mathematical functions (abs, cos, sin, &c) we will need
also the descriptors, otherwise we will have to assemble some "move"
instructions to move the returned "double float" value to the variable.

The older (msdos) compiler do exactly what you mean (only "char *" is
passed) and I have experienced many problems with this.  For cobol
subprograms, we just replace the arriving arguments by the "procedure
division using ..." arguments at the called subprogram.  So cobol or C
programs will behave exactly the same, except that the C programs will
have 2 pointers to each variable.  Also, the cobol subprogram can redefine
the arguments to another layout (this is dangerous too, of course, but can
be done), if the size is maintained.

Please think a little more about this.  As we are doing it from (almost)
the ground up, we can choose anything we find useful.  Let also see what
the others have to tell us about this...
(^G^G^G^G^G^G  are you hearing me????? ^G^G^G^G^G^G^G^G^G)
I suggest also we look at other software manufacturers (besides the bug
blue) about their methods for doing subprograms and extensions in C or
other non-cobol languages.  Any docs are welcome.

> The two major drawbacks with this are as follows.  It may complicate the
> sym struct. I am not sure what the C calling method actually puts on the
> stack, so it may complicate matters.

Well, the symbol table don't exists anymore at the runtime.  The only
information we have about the symbols are what is declared at "struct
fld_desc", much less than "struct sym".  Functions in "C" use the stack to
store the "bp" register (base pointer) to request automatic variables, so
it's diffiult to know what's deeper in the stack (that's why we have
var_args functions to access variable number of arguments).
 
> BTW, the COBOL sub program does not return anything to the calling program,
> nor does a main program return anything. So it is equivalent the C void
> return type. There are COBOL compiler extensions, which add a return code.
> Some I*B mainframe COBOL compilers for example have a special variable
> called RETURN-CODE, which are set by the programmer, and are equivalent to
> the C statement return int.
> 
> Also a sub program does not need a asm_call("stop_run"), and the main
> labels (ie. main: main@.. etc) should be changed to the sub program name.
> In t15 I do that using sed before using GAS.

BTW, I can't yet make your example. Please correct the makefile, so I can
try to help you.

Anyway we are already prepared to return codes for the calling program.
Our file i/o routines are doing this to return status code, that are
tested by a separate function (get_status), that fills the "file status"
variable, and also as we test with "at end" or other if-like conditions.
We can change this later, but it means reworking many things in the
compiler. I think it's better leave it this way for now.

What I don't understand is why you are concerned with calling C functions
now. Please, let us finish the missing statements and we turn to make the
mathematical functions and other C functions.

best regards,
Rildo
 _____   _ __    __       __      __      ___      __  Rildo Pragana
/\ '__`\/\`'__\/'__`\   /'_ `\  /'__`\  /' _ `\  /'__`\ P.O. Box 721
\ \ \L\ \ \ \//\ \L\.\_/\ \L\ \/\ \L\.\_/\ \/\ \/\ \L\.\_ Camaragibe
 \ \ ,__/\ \_\\ \__/.\_\ \____ \ \__/.\_\ \_\ \_\ \__/.\_\ PE Brazil
  \ \ \/  \/_/ \/__/\/_/\/___L\ \/__/\/_/\/_/\/_/\/__/\/_/ 54792-990
   \ \_\ rpr...@ac... /\____/ FPGA/uControllers * Linux * tcl/tk
    \/_/ +55-81-459-1776  \_/__/  http://members.xoom.com/rpragana/