GnuCOBOL TODO -*- outline -*-

The following is only a part of the things to do; many more

can be found in the issue trackers.

1 Pending requests

1.1 Handling of EBCDIC files

2 Other features to be implemented

2.1 New option handling.

A new configuration file, cobc.conf, is described in

https://sourceforge.net/p/gnucobol/feature-requests/342/

Integrate that file with existing command-line parsing,

allowing for overrides and warning-defeats as outlined in

that document.

2.2 New preprocessor support.

https://sourceforge.net/p/gnucobol/feature-requests/341/ defines

configuration for preprocessors. Add support for preprocessors to cobc.

Modify the -E option to be

-E [preprocessor]

meaning that all preprocessors should be run up to and including the

one named in the -E argument. If no argument is provided, -E

continues to work as currently.

2.3 Embedded SQL - ship as sample configurations for 2.2

esqlOC - preprocessor by Sergey Kashyrin.Sergey Kashryin (ODBC)

ocesql - https://github.com/opensourcecobol/Open-COBOL-ESQL (MySQL/ODBC)

PostgreSQL using epcpg, wrapper for COBOL by Frank Polscheit (ruby based)

http://lists.gnu.org/archive/html/gnucobol-users/2004-02/msg00053.html

Firebird (firebird.sourceforge.net) has a SQL preprocessor

for their database.

Oracle Pro*COBOL

3 Improvement of compiler internals

3.1 Error checking

3.1.1 Strict error checking depending on the standard

Mostly implemented

3.1.2 Use `error' token in the parser for better error recovery

3.1.3 detailed diagnostics with output of offending code (similar to gcc)

3.1.4 Add special contexts dedicated to the arguments of some intrinsics

Some words are context-sensitive only in the context of some intrinsic

functions arguments. This is the case of ANUM, or BYTE, HEX, and NAT

for CONVERT, or ACTIVATING, CURRENT, STACK, and TOP-LEVEL for

MODULE-NAME, for instance.

This could be handled in two ways, either: (i) by using a generic

mechanism (triggered after looking up intrinsic functions in the

scanner) and a new context set for arguments in `struct

cb_intrinsic_table`; or (ii) more explicitly in the parser itself (in

rule `function`). In both cases, reset of special contexts need to be

performed in parser actions.

Alternative (i) mimicks the behavior of current token-based entry for

contexts, but may be harder to adapt to cases of nested function calls

(as we currently do not maintain a stack of active special contexts).

3.2 Data representations

3.2.1 Fix handling of 32bit, 64bit, and 128bit floating-point usages

3.2.2 Finish USAGE BINARY for sizes > 18 digits "COB_MAX_BINARY"

3.3 add checks

4 Optimization

4.1 More inlining of run-time functions

Done with various binary operands and expressions, open for some

intrinsic functions (actually using libcob at compile time).

4.2 generating multiple C functions for procedures

Currently, cobc translates a COBOL program into a single huge

C function. There are two problems with doing this:

- The speed of C compilation is very slow, especially when

optimization is enabled. Optimizing a single huge C function

is much slower than doing that for divided functions of it and

need a lot of memory - big COBOL sources break 32bit GCC

when compiling without -O0.

- Debugging the generated COBOL program with gdb is hard

because you cannot see performed procedures on the stack and

cannot skip PERFORM statement by the 'next' command.

Currently PERFORM is implemented by C's goto statement, so you

have to go there.

To solve these problems, we could separate COBOL sections into

multiple C functions, and use C function calls to execute each

section. As most of the memory is function-local this only works with

compilers that support nested functions (mostly GCC), with the currently

4.x only addition of placing the memory into one big block (as that can be

passed around).

However, this does not work for all cases _easily_. Consider

the following example:

SAMPLE-1 SECTION.

PERFORM SAMPLE-2.

PERFORM SAMPLE-3.

SAMPLE-2 SECTION.

GO TO SAMPLE-3.

SAMPLE-3 SECTION.

EXIT PROGRAM.

You might want to generate three functions SAMPLE_1, SAMPLE_2,

and SAMPLE_3. SAMPLE_1 might be defined as follows:

void SAMPLE_1 ()

{

SAMPLE_2 ();

SAMPLE_3 ();

}

But you cannot define SAMPLE_2 because you cannot jump from

one function to another function. SAMPLE_1 and SAMPLE_2 must

be defined within the same function, and thus you cannot call

them separately.

A similar problem occurs with "fall through" of paragraphs/sections.

To detect and avoid this kind of problems, we will need control

flow analysis of COBOL programs - the options -fsection-exit-check,

-fimplicit-goback-chec and cb_validate_perform_thru_ranges() partially

take care of this.

If a portion of program is used only through a PERFORM

statement, and if there is no GO TO statement that jumps

to outside of the portion, then we can safely separate the

portion as a C function.

As an alternative we have to have a global jump table (in the GCC

case we can use computed-goto, otherwise a switch to handle that):

prog () { prog_() }

prog_() {

auto void SAMPLE_1();

auto void SAMPLE_2();

auto void SAMPLE_3();

l_sample1:

void SAMPLE_1() {

SAMPLE_2();

if (gotoptr) goto gotoptr;

SAMPLE_3(); // never executed

if (gotoptr) goto gotoptr; // never executed

}

if (gotoptr) goto gotoptr; // never executed

l_sample2: // never executed

SAMPLE_2() {

gotoptr = l_sample3;

}

if (gotoptr) goto gotoptr; // never executed

l_sample3:

SAMPLE_3() {

gotoptr = l_exit;

}

if (gotoptr) goto gotoptr;

l_exit:

// over

}

As a third alternative we can just add a flag that says

"assume I never go out of a section".

4.3 optimizing cob_move_display_to_edited

This function is relative often called in production systems and

re-calculates the picture on runtime, which the compiler already

did - pass this information along with the call.

4.4 optimize multiple uses of the same (sub-)expression

the following code

IF T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "E"

AND T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "L"

AND T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "T"

AND T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "t"

AND T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "M"

AND T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "i"

AND T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "v"

as well as

IF T01-VAL (T01-MAIN T01-IND1 T01-IND2) NOT = "E"

AND NOT = "L"

AND NOT = "T"

AND NOT = "t"

AND NOT = "M"

AND NOT = "i"

AND NOT = "v"

currently generates identical code; it generates

* in case of non-binary data: a cob_get_int for the subscripts

seven times

* the runtime checks, if enabled, seven times

(each with 3 subscript checks, possibly with 4 linkage checks)

* seven times the same offset calculation

* for the case of non-optimized comparisions (here a single byte

vs. a single byte -> direct compare) like comparing different

lengths or numeric types, we generate a COB_SET_FLD or

cob_get_int multiple times

ideally each of those are only done once (if there's no UDF call

in the expression as those can have side effect for left-to-right compare

by changing the underying data)

4.4.1 ensure that the same integer is only resolved once by using local

int fields

4.4.1 optimize runtime checks by doing them once (as the abbeviated

condition example above would "imply"); note:

cater for IF IND <= MAX AND ( TAB (IND) = "5" OR TAB (IND) = "6" )

--> can only be generated for the second part, not for the complete statement

5 Debugging support

5.1 Data access method

We should generate all data hierarchy defined in a COBOL program

with all relevant information, including data names, picture clauses,

and source locations. We should also define a debugging function

that receives a data name and displays its value using the generated

data hierarchy. By calling the function from gdb, we can easily

access the COBOL data at debugging time.

Note: GnuCOBOL 3 implemented this partially, using extensions

near full GDB support is already possible.

GnuCOBOL 4 provides this quite complete at runtime, too.

In case of coredumps and recorded code using those functions are

unlikely to work.

6 Better user manual

Yes, we should, for now: refer to the GnuCOBOL Programmer's Guide

https://sourceforge.net/p/gnucobol/code/HEAD/tree/external-doc/guide/

For vfile routines: document return-codes per fileio.c and different

handling of cancel and heap-status variable used in CBL_OPEN_VFILE only

and no use of backup file, limitation of i/o area length.

7 NATIONAL support

Finish implementation of NATIONAL support.

This implies to take care - among other things - of the many TODOs in the following functions:

* tree.c

- cb_tree_category (CB_TAG_FIELD)

- cb_tree_type (CB_USAGE_NATIONAL)

- cb_build_picture ('N')

* parser.y

- prepare_default_collation

- program_coll_sequence_values

- alphabet_type_national

- symbolic_characters_clause

- class_name_clause

- coll_sequence_values

- usage_screen_report

- usage

- class_value

* scanner.l

- N[''""]

- NC[''""]

- U[''""]

- error_literal

- read_literal

- scan_x

* typeck.c

- cb_emit_sort_init (nat_col)

* field.c

- validate_any_length_item

* codegen.c

- output_alphabet_name_definition

* reserved.c

- function_list (CHAR-NATIONAL, EXCEPTION-FILE-N, EXCEPTION-LOCATION-N, NATIONAL-OF)

* intrinsics.c

- cob_check_numval_f

- numval

- cob_check_numval

- cob_intr_bit_of

- cob_intr_hex_of

- cob_intr_numval_f

- cob_intr_char_national

- cob_intr_display_of

- cob_intr_exception_file_n

- cob_intr_exception_location_n

- cob_intr_national_of

* common.c

- cob_cmp

* fileio.c

- indexed_open

* mlio.c

- set_xml_text

- xml_generate

- cob_json_generate_new