[Tiny-cobol-users] Re: Tiny Cobol

[David E. <de...@ar...>]

Richard Stallman wrote:

> 
>     Personally I am looking at GPC 2.0(GNU Pascal)(1). They have used GCC
>     2.7.2.1 back end to create a Pascal compiler.
> 
>     Could this be an approach that COBOL could use ?
> 
> In general, that is the right approach.  You should make it work
> with the current version of GCC, of course.
> 
>     Why not an easy fit? Well besides the huge COBOL syntax, which makes
>     scanning/parsing a big job, COBOL has some unique features which in turn
>     require changes to the back end, another big job.
> 
> This may or may not require changes in the back end.
> Depending on the details, there may be an easier solution.
> 
>     Some of these features
>     include, data types which are not available in GCC, build in indexed file
>     support, to name a few.
> 
> Could you tell me about these data types?  If they are essentially
> opaque, and operated on only by library functions, you don't really
> need to teach the back end about them.  You could treat it as a
> structure type, as far as the back end is concerned.

That is a difficult question to answer in detail, since I am not very
familiar with the GCC back end specifics. However I will expand on a few
details, maybe you can shed some light on the matter.

In COBOL variables are defined/declared in a tree type structures. Each
variable has a storage size and a display size which may or may not be
the same size.

In this COBOL example X=alpha, 9=numeric, V=numeric implied decimal
point, COMP=binary storage.

01 V1.
  05 V1a       PIC X(20).
  05 V1b.
    10 V1b1    PIC 9(3)V99.
    10 V1b2    PIC 9(10) COMP.

The equivalent C code would be as follows. Fields of type X(alpha) are
non null terminated strings, like Pascal strings are. Fields of type
9(numeric) are Pascal strings, with only numeric data.

struct branch {
   branch *next_branch;
   leaf   *next_leaf;
   unsigned int len;
};

struct leaf {
   unsigned int display_len;
   unsigned int storage_len;
   unsigned int implicit_decimal_pos;
   unsigned char *display_data;
   leaf   *next_leaf;
};

Thus the above COBOL code as the following C code.

struct branch {
   next_branch = V1b;
   next_leaf   = V1a;
   len         = 29;
}V1;

struct branch {
   next_branch = NULL;
   next_leaf   = V1b1;
   len         = 9;
}V1b;

struct leaf {
   display_len = 20;
   storage_len = 20;
   implicit_decimal_pos = 0;
   display_data[20];
   next_leaf = NULL;
}V1a;

struct leaf {
   display_len = 5;
   storage_len = 5;
   implicit_decimal_pos = 2;
   display_data[5];
   next_leaf = V1b2;
}V1b1;

struct leaf {
   display_len = 10;
   storage_len = 4;
   implicit_decimal_pos = 0;
   display_data[10];
   next_leaf = NULL;
}V1b2;


So what are the GCC back end implications in having these type of
variables ?


Another example is the way COBOL controls program flow. It has
functions, which are called sub programs, but it also has procedures,
which in C are a cross between goto labels and functions. The following
example will illustrate what I mean.

PROCEDURE DIVISION.
PERFORM A100.
PERFORM A130.
STOP RUN.

A100.
 ...
A110
 ...
A120.
 ...
A130.
 ...

Control will flow from PERFORM A100, to the A100 procedure, to PERFORM
A130, to the A130 procedure, to STOP RUN, then exit.

Since procedures are neither goto labels nor functions, how is GCC going
to handle this ? Will the back end be effected ?  



>     Besides, how much of the current compiler could be used in GCC? Maybe the
>     scanner, and not much else I suspect.
> 
> I do not entirely understand this question.  But is it really relevant
> to the decision at hand?  I don't think so.
> 
> If you want a portable compiler producing good code, you can either use
> GCC, or do a gigantic amount of work to duplicate GCC.
> 
> Even supporting ONE additional target machine is probably as much
> work as connecting this front-end to GCC.  So why consider doing it
> the hard way?
> 
>     IMHO, the best approach is to complete this tiny project first, then
>     consider integrating this into GCC.
> 
> The sooner you connect it with GCC, the better.
> 
> if you continue on the present path, some of the work you do would
> need changing in order to connect it with GCC later.  That is inefficient.
> It is better to connect the front-end with GCC first, then finish the
> front-end by writing code that won't need to be redone.

There is a lot of work to change, regardless if it done now or later.


I think using GCC is the way to go, in the long run, but that is a large
project. The scope of this project while not small, is smaller, before
we can create a useful compiler. Further lessons learned here may be
applicable in tackling GCC.
  


David