RE: [open-cobol-list] Re: Status of Cobol

[Pierre Brico]

Hi Robert,

Thank you for your performance hints but they aren't applicable in my 
situation. I'm using a SUN Solaris 9 with ultrasparc processors and none of the 
options are usable.
Note I try to optimize compilation with "-m64 -O2 -mcpu=ultrasparc3" but the 
result aren't wonderful. By example, a batch processing takes about 10 times 
more with OpenCobol than with MF.
With some minor changes in the generated code (like memset(x, c, 1); -> *x = 
c;), I obtain a 6 factor but there's still a lot to do !

Pierre 


-----Message d'origine-----
De : Margit Schubert-While [mailto:address@hidden 
Envoyé : jeudi 10 juin 2004 16:42
À : address@hidden
Cc : address@hidden
Objet : [open-cobol-list] Re: Status of Cobol

Yes, indeed, always use the CVS.

Pierre, you can do the following things to get near the MF performance:
(Assumes gcc >= 3)

1) When configuring Open Cobol, attach extra cflags to the command :
(typically for a P4 ->)
./configure --with-lfs64 --with-db \
  CFLAGS="-march=pentium4 -fomit-frame-pointer -minline-all-stringops"

2) When compiling progs, as well as using -O2, prior to the compile,
set/export COB_CFLAGS to the same value as in CFLAGS above in (1).
(Note however that omit-frame-pointer doesn't mix with option "-g")

3) This was posted before, but I will repeat.
Implement a "driver" program equivalent to MF's "cobrun" :

cobcrun.c
#include        <stdio.h>
#include        <libcob.h>

#define KCOBMAXARGS     64
int
main (int argc, char **argv)
{
         int     ret;
         int (*func)();
         char    *argn[KCOBMAXARGS];

         if ( argc <= 1 || argc > KCOBMAXARGS) {
                 fprintf(stderr, "Number of parameters incorrect\n");
                 return 1;
         }
         for ( ret = 1; ret < argc; ret++ ) {
                 argn[ret - 1] = argv[ret];
         }
         cob_init (argc - 1, argn);
         func = cob_resolve (argn[0]);
         if (func == NULL) {
                 cob_call_error ();
         }
         return func();
}

Compile/link as follows (for P4) :

gcc -rdynamic -Wl,-export-dynamic -O2 -march=pentium4 \
-minline-all-stringops -fomit-frame-pointer cobcrun.c -o cobcrun \
-Wl,-whole-archive /usr/local/lib/libcob.a /usr/lib/libgmp.a \
-Wl,-no-whole-archive -lltdl -ldb -lncurses -lm

Note this pulls in the static versions of libcob and libgmp (the most heavily
used).

You can now compile your complete application as modules.  (option -m)
(And save the bother of trying to work out what's a main prog and
  what's a module)
You can then run similarly to MF with "cobcrun MYPROG".

In fact, what I do for the app scripts is define a variable "COBEXEC"
which is then set ie. to "cobrun" for MF, "cobcrun" for Open Cobol,
"runcbl" for ACU etc. and call the progs with "$COBEXEC MYPROG".
As each of the afore-mentioned generates a different suffix for the generated
code, everything can be managed in the same source directory and, assuming
other environment variables are set correctly, you can switch between Cobol's
simply by changing "COBEXEC".

Roger While




-------------------------------------------------------
This SF.Net email is sponsored by: GNOME Foundation
Hackers Unite!  GUADEC: The world's #1 Open Source Desktop Event.
GNOME Users and Developers European Conference, 28-30th June in Norway
http://2004/guadec.org
_______________________________________________
open-cobol-list mailing list
address@hidden
https://lists.sourceforge.net/lists/listinfo/open-cobol-list