Re: [Cobolforgcc-devel] Re: GCC front end for COBOL

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

At Mon, 05 May 2003 06:15:47 +1000,
Tim Josling wrote:
> 
> My objective is to get a working free cobol compiler. I think by joining 
> up we may be able to get their faster. As you remember I was keen to 
> join up before. You have done a lot of work very quickly, more than me.

Thanks.  Can I put my code on the CVS repository of the COBOL for GCC
project?

> Could you send me details of what your compiler does and does not 
> support? That is, what features are present and what features are missing.

Features that are present:

  COBOL core features (95% of NIST NC module), except
    - SPECIAL-NAMES. ALPHABET clause.
    - COLLATING SEQUENCE clause
    - variable length group item (OCCURS DEPENDING ON)

  SEQUENTIAL/REALTIVE/INDEXED/SORT-MERGE file I-O
  (85% of NIST SQ, RL, IX, and ST modules), except
    - SAME clause
    - LINAGE clause
    - variable length records
    - SORT with duplicate keys
    - COLLATING SEQUENCE

  CALL statement (48% of NIST IC module)
    A program can be compiled into either a native
    executable or a shared library (.so), and they
    can be linked either statically or dynamically.

    Nested programs are not supported.

  COPY and REPLACE statements (58% of NIST SM module)
    The current preprocessor cannot handle complex COPY statement.
    The preprocessor can handle both fixed and free form.

Features that are missing:

  Nested programs
  Intrinsic functions
  REPORT SECTION
  COMMUNICATION SECTION
  SCREEN SECTION
  Embedded SQL
  Debugging with GDB

  Compile-time / run-time error checking is not complete
  (I am currently improving this)

  Optimization is not well done

> One thing for you to consider: if you integrate into GCC, you will find 
> that GCC integration takes a lot of ongoing effort. People change things 
> that break your compiler. This will slow you down. I found that keeping 
> up with GCC changes is taking most of my time, not adding features. In 
> my opinion it would be best to target, say, gcc3.3 and then later on 
> upgrade to a later release. This protects you to some extent.
> 
> All in all, it may be better to integrate later on, once your compiler 
> is 'function complete'.

Thanks for your advice, and I agree with you.  Maybe we should target
GCC 3.3.

Best regards,
Keisuke Nishida