public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "James K. Lowden" <jklowden@schemamania.org>
To: gcc@gcc.gnu.org
Subject: #include cobol
Date: Mon, 27 Feb 2023 05:32:46 -0500	[thread overview]
Message-ID: <20230227053246.ec9d48a5cd3cbd67fd296fc6@schemamania.org> (raw)

To the GCC community and GCC Steering Committee:  Greetings!  

We at COBOLworx would like GCC to consider our gcobol front-end for
inclusion in the GCC project.  We would like to contribute it to the
GNU Toolchain and have it merged into GCC.

We believe our work is further along than any previous GCC Cobol
effort.  As you may know, we have been working on the project for over
a year. Much of the last 9 months have been devoted to testing for
correctness.  The compiler now passes the core module of the NIST
CCVS-85 test suite.  Although not ready for production use by any
means, we expect to pass all relevant aspects of CCVS-85 later this
year.  

Old as it is, Cobol is far from dead.  Estimates run into billions of
lines written, with millions more added each year, even today.  But --
because there has never been a free, fully functional,
source-to-machine compiler for it -- Cobol remains largely locked
behind expensive, proprietary walls.  GCC can change that.  

Cobol also offers a window into what was and might yet be.  In Seibel's
"Coders at Work", Fran Allen put it this way:

	"There was a debate between Steve Johnson, of Bell Labs, who
were supporting C, and one of our people, Bill Harrison....  The nubbin
of the debate was Steve's defense of not having to build optimizers
anymore because the programmer would take care of it."

and 

	"By 1960, we had a long list of amazing languages: Lisp, APL,
Fortran, COBOL, Algol 60.  These are higher-level than C.  We have
seriously regressed since C developed."

Modern hardware, and GCC's 100 optimization passes, are evidence Fran
Allen was right.  Cobol, with its 2 dozen high-level verbs and
integrated I/O, provides a theoretical opportunity to surpass even C's
performance in its problem domain, because the compiler has more
information and more leeway.  

As a technical matter, to be sure we are far from achieving that goal.
It is, as I said, an opportunity.  As we hone our skills, we look
forward to learning together with others to make it a reality.  

Signed, 

Marty Heyman, James K. Lowden, Robert Dubner

             reply	other threads:[~2023-02-27 15:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-27 10:32 James K. Lowden [this message]
2023-03-18 13:22 ` David Edelsohn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230227053246.ec9d48a5cd3cbd67fd296fc6@schemamania.org \
    --to=jklowden@schemamania.org \
    --cc=gcc@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).