Thread: [Cobolforgcc-devel] Re: GCC front end for COBOL
Status: Pre-Alpha
Brought to you by:
timjosling
Menu
▾
▴
cobolforgcc-devel
|
From: Keisuke N. <kni...@ne...> - 2003-04-29 20:41:04
|
Hello, As I talked in the gcc list, I would like to write a COBOL front end for GCC. I know there have been lots of discussion and efforts on this list, and I wonder if we could work together. I would like to contribute my code to the COBOL for GCC project and join in if you are comfortable with that. What do you think? Thanks, Keisuke Nishida |
|
From: <de...@gn...> - 2003-04-29 20:28:39
|
Tim Josling said > 1. A test suite. Existing languages have comprehensive test suites. I would think the standard COBOL test suite (used for GSA cobol validations at least in the past, not sure of current policy) would be a fine test suite for this purpose. |
|
From: William M. K. <wm...@ix...> - 2003-04-30 21:01:20
|
A few comments on the "NIST" test suite (for those not familiar with its status), 1) As the ANSI (and ISO) '85 Standard is NOW no longer a "recognized" ANSI/ISO Standard (as of the approval of the 2002 Standard), these tests = are no longer relevant to a "currently recognized" COBOL Standard. (Which = is NOT to say they aren't "useful"). 2) NIST stopped doing COBOL (or any other) "independent" validations = about 4 or 5 years ago. (This had to do with Dept of Commerce "cut-backs"). 3) At the time that NIST stopped doing its own testing, they "allowed" (licensed?) EDS to do validation testing of COBOL (and SQL - as I = recall). 4) From the time that EDS was licensed to do such testing to the time = that the '85 Standard became obsolete, there were ZERO (as far as I know) = vendors (or independents) who actually paid for this service. For more information on this, see: http://www.eds-conform.com/ValProdList.html and http://www.eds-conform.com/languages.html *** Final note - FYI The NIST tests were modified for the 1st Amendment to the '85 Standard (the intrinsic function amendment) but were NOT updated for the 2nd Amendment (the "corrections" amendment). Therefore, the test suite = doesn't even "fully" test for conformance to the "85 Standard" - as it was at = the time it became obsolete. > -----Original Message----- > From: ope...@li...=20 > [mailto:ope...@li...] On=20 > Behalf Of Robert Dewar > Sent: Tuesday, April 29, 2003 3:29 PM > To: kni...@ne...; te...@me... > Cc: cob...@li...; gc...@gc...;=20 > ope...@li... > Subject: Re: [open-cobol-list] GCC front end for COBOL >=20 >=20 > Tim Josling said >=20 > > 1. A test suite. Existing languages have comprehensive test suites. >=20 > I would think the standard COBOL test suite (used for GSA=20 > cobol validations > at least in the past, not sure of current policy) would be a fine test > suite for this purpose. >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > open-cobol-list mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/open-cobol-list >=20 |
|
From: Tim J. <te...@me...> - 2003-05-06 20:49:50
|
The only issue would be the copyright. While they have given permission to use the suite freely, it is not public domain, nor copyright FSF. Bill Klein also pointed out it has not been updated for the second revision of COBOL 85 (the correction amendment). Tim Josling Robert Dewar wrote: > Tim Josling said > > >>1. A test suite. Existing languages have comprehensive test suites. > > > I would think the standard COBOL test suite (used for GSA cobol validations > at least in the past, not sure of current policy) would be a fine test > suite for this purpose. > |
|
From: Geoff K. <ge...@ge...> - 2003-05-06 21:00:33
|
Tim Josling <te...@me...> writes: > The only issue would be the copyright. While they have given > permission to use the suite freely, it is not public domain, nor > copyright FSF. This may be OK; the testsuite has different rules to the rest of the compiler. It would depend on the exact license. -- - Geoffrey Keating <ge...@ge...> |
|
From: Tim J. <te...@me...> - 2003-05-04 20:29:03
|
Keisuke, 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. 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. Also I will have a look at your compiler and verify if the structure is OK. Could you give me your phone number and a time I can call you, in a few days time, so we can discuss all this? By the way, I am visiting Japan in July... maybe we could get togther then. 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'. Regards, Tim Josling Keisuke Nishida wrote: > Hello, > > As I talked in the gcc list, I would like to write a COBOL front end > for GCC. I know there have been lots of discussion and efforts on > this list, and I wonder if we could work together. > > I would like to contribute my code to the COBOL for GCC project and > join in if you are comfortable with that. What do you think? > > Thanks, > Keisuke Nishida |
|
From: Keisuke N. <kni...@ne...> - 2003-05-05 22:59:59
|
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
|
|
From: Tim J. <te...@me...> - 2003-05-06 21:17:52
|
Keisuke Nishida wrote: > At Mon, 05 May 2003 06:15:47 +1000, > Tim Josling wrote: > ... > > Thanks. Can I put my code on the CVS repository of the COBOL for GCC > project? > Yes, once you have the FSF paperwork done. > >>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: > ... > > Thanks for your advice, and I agree with you. Maybe we should target > GCC 3.3. > > Best regards, > Keisuke Nishida > > I think this is a good idea. I will be in Japan from 2-13 July. Perhaps we could get togther for a few hours and work out a plan which meets both our needs. One possibility is: Most of the code comes from opencobol. Except - preprocessor (cobol4gcc is complete implementation of COPY/REPLACE) - GCC integration Then we could both pick features to work on and get it done twice as fast. Tim Josling |
|
From: William M. K. <wm...@ix...> - 2003-05-06 21:29:31
|
> -----Original Message----- > From: cob...@li...=20 > [mailto:cob...@li...] On=20 > Behalf Of Keisuke Nishida > Sent: Monday, May 05, 2003 6:00 PM > To: Tim Josling > Cc: cob...@li...; gc...@gc... > Subject: Re: [Cobolforgcc-devel] Re: GCC front end for COBOL <snip> >=20 > Features that are missing: >=20 > Nested programs > Intrinsic functions > REPORT SECTION > COMMUNICATION SECTION > SCREEN SECTION > Embedded SQL > Debugging with GDB >=20 Just a PERSONAL suggestion, do NOT bother with "Communications Section". Also, which "variation" of Screen Section are you thinking of = implementing? AcuCOBOL syntax (includes character mode *AND* GUI) Micro Focus, RM, or any of the other currently available on Unix = system variations X/Open (medium "basic" character mode - and medium portable to = existing implementation 2002 COBOL Standard (possibly the MOST portable - in the future, but = not yet) Each of these has "PROs and CONs". My personal SUGGESTION would be to = go with the 2002 COBOL Standard definition (which is SIMILAR to - but not identical to - the X/Open specification) |
|
From: Keisuke N. <kni...@ne...> - 2003-05-12 20:38:06
|
At Tue, 6 May 2003 16:29:15 -0500, William M. Klein wrote: > > > Features that are missing: > > > > Nested programs > > Intrinsic functions > > REPORT SECTION > > COMMUNICATION SECTION > > SCREEN SECTION > > Embedded SQL > > Debugging with GDB > > Just a PERSONAL suggestion, do NOT bother with "Communications Section". Thanks. I am not going to support it because it seems there is no user of it. > Also, which "variation" of Screen Section are you thinking of implementing? Maybe we could support all of them by selecting a compiler option. At the beginning, I am going to support the one of COBOL 2002. Regards, Keisuke Nishida |
Thanks for helping keep SourceForge clean.
X