This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Cobolforgcc-devel] Re: GCC front end for COBOL
- From: Keisuke Nishida <knishida at netlab dot jp>
- To: Tim Josling <tej at melbpc dot org dot au>
- Cc: cobolforgcc-devel at lists dot sourceforge dot net, gcc at gcc dot gnu dot org
- Date: Tue, 06 May 2003 07:59:54 +0900
- Subject: Re: [Cobolforgcc-devel] Re: GCC front end for COBOL
- References: <5bd6j5dokk.wl@othello.netlab.jp> <3EB574F3.8020605@melbpc.org.au>
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