Re: Patch: delete treelang

Re: Patch: delete treelang

[Jim Morrison]

Please go ahead and remove this.  Feel free to move me to write after
approval section of the MAINTAINERS file.
-- 
Jim

Re: Patch: delete treelang

[Tom Tromey]

>>>>> "Jim" == Jim Morrison <phython@google.com> writes:

Jim> Please go ahead and remove this.  Feel free to move me to write after
Jim> approval section of the MAINTAINERS file.

Thanks.  And, thanks for reminding me about MAINTAINERS.

I am checking in the patch, with the appended addition.

Tom

ChangeLog:
2008-03-06  Tom Tromey  <tromey@redhat.com>

	* MAINTAINERS: Update for treelang deletion.

Index: MAINTAINERS
===================================================================
--- MAINTAINERS	(revision 132902)
+++ MAINTAINERS	(working copy)
@@ -130,8 +130,6 @@
 java			Tom Tromey		tromey@redhat.com
 objective-c/c++		Mike Stump		mrs@apple.com
 objective-c/c++		Stan Shebs		stanshebs@earthlink.net
-treelang                Tim Josling             tej@melbpc.org.au
-treelang                James A. Morrison	phython@gcc.gnu.org
 
 			Various Maintainers
 
@@ -338,6 +336,7 @@
 Harsha Jagasia					harsha.jagasia@amd.com
 Fariborz Jahanian				fjahanian@apple.com
 Phillip Jordan					phillip.m.jordan@gmail.com
+Tim Josling					tej@melbpc.org.au
 Klaus Kaempf					kkaempf@progis.de
 Victor Kaplansky				victork@il.ibm.com
 Brendan Kehoe					brendan@zen.org
@@ -385,6 +384,7 @@
 Alan Modra					amodra@bigpond.net.au
 Alexander Monakov				amonakov@ispras.ru
 Catherine Moore					clm@redhat.com
+James A. Morrison				phython@gcc.gnu.org
 Dirk Mueller					dmueller@suse.de
 Adam Nemet					anemet@caviumnetworks.com
 Thomas Neumann					tneumann@users.sourceforge.net

Re: Patch: delete treelang

[Tim Josling]

Too late now but a few thoughts on this...

Treelang was based on Richard Kenner's toy language. I packaged it up to
include as a part of GCC because toy had fallen behind the GCC mainline
and no longer worked, and there were various versions floating around
that were all broken in different ways. When I re-started work on my
COBOL compiler again a few months ago, I was very pleased to see
treelang still there because it will make my job of rebuilding an
interface to the GCC back end a lot easier. To that extent it's done its
job for me because it survived almost long enough.

I suspect that people who have worked on GCC full time for a number of
years, and who have commit authority, can tend to forget the many
obstacles that are in front of someone starting work on GCC,
particularly on a front end.

The impediments to starting work on GCC, particularly building a front
end, are formidable. Treelang was an attempt to somewhat reduce those
impediments. In particular the front end documentation has traditionally
been considerably more limited than the documentation for the rest of
GCC. The main front ends also tend to fractally mix language-specific
code with the generic GCC back end interface which makes it much harder
to understand what the essentials are and to use one as a starting
point.

Treelang did not entirely solve all these problems but it did provide a
small, simple working model of a compiler front end.

The way I am structuring the COBOL compiler is in part a response to the
difficulties of interfacing to the GCC back end. The interface is poorly
documented, volatile (as shown by the need to patch treelang on a
regular basis), and hard to debug. The way the GCC back end works limits
the ways that the front end can be structured. As a result, the COBOL
compiler will be a separate executable, and will pass a binary file to a
mini-front end that interfaces to the GCC back end. Everything that can
be taken out of the cob1 binary will be. This way I can more easily
employ other code generation strategies such as generating C, generating
Java classes, or using other back ends such as LLVM. This front end will
be a very clean example as it turns out, so all is not lost - there wil
still be a clean front end as an example.

Tim Josling

On Thu, 2008-03-06 at 09:20 -0700, Tom Tromey wrote:
> >>>>> "Jim" == Jim Morrison <phython@google.com> writes:
> 
> Jim> Please go ahead and remove this.  Feel free to move me to write after
> Jim> approval section of the MAINTAINERS file.
> 
> Thanks.  And, thanks for reminding me about MAINTAINERS.
> 
> I am checking in the patch, with the appended addition.
> 
> Tom

Re: Patch: delete treelang

[Basile STARYNKEVITCH]

I'm cc-ing gcc@ & gcc-patches@ list. I feel this interesting discussion 
belongs more to gcc@

Tim Josling wrote:
> 
> Treelang was based on Richard Kenner's toy language. I packaged it up to
> include as a part of GCC because toy had fallen behind the GCC mainline
> and no longer worked, and there were various versions floating around
> that were all broken in different ways. When I re-started work on my
> COBOL compiler again a few months ago, I was very pleased to see
> treelang still there because it will make my job of rebuilding an
> interface to the GCC back end a lot easier. 


> I suspect that people who have worked on GCC full time for a number of
> years, and who have commit authority, can tend to forget the many
> obstacles that are in front of someone starting work on GCC,
> particularly on a front end.


I really agree with that. We usually do not have enough in mind that GCC 
is a particularily difficult open source software to dive into. And this 
is a major bottleneck to attract new developers & maintainers.

Issues are not only on the front end. It is also difficult to interest 
people to work on the middle end, and perhaps even on the back end.

FWIW, I'm also trying to attract some new people & companies to work on 
GCC within european projects, and it is a very difficult job (even with 
the perspective of partial funding with european taxpayers' money).

> 
> The impediments to starting work on GCC, particularly building a front
> end, are formidable. Treelang was an attempt to somewhat reduce those
> impediments. In particular the front end documentation has traditionally
> been considerably more limited than the documentation for the rest of
> GCC. 

I would say the same for the middle-end also, and also for 
infrastructure stuff. Even the building part of GCC (eg Makefile.in and 
configure.ac are very intimidating).

> The main front ends also tend to fractally mix language-specific
> code with the generic GCC back end interface which makes it much harder
> to understand what the essentials are and to use one as a starting
> point.

It is very difficult to be fair and well informed, but I have the 
impression that GCC is more difficult to dive into than perhaps other 
similar monster open source (= free GPL-ed software) projects.

I tend to believe that we the GCC community should make diving into GCC 
easier, even if I don't understand how to do that. I really think that 
GCC is still lacking of developers (& developping efforts), and that its 
current state (which is remarkable for a 20+ years software) make it too 
intimidating for many potential developers.

Regards.
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Patch: delete treelang

[Tom Tromey]

>>>>> "Tim" == Tim Josling <tejgcc@westnet.com.au> writes:

Tim> Too late now but a few thoughts on this...

It's been bothering me for a couple of days that I didn't address some
of these things in my original note.

I know how hard it can be to have one's code deleted -- I've had to
mourn more than one program that I had worked hard on.  So, I wanted
to thank you for your contribution.

Tim> I suspect that people who have worked on GCC full time for a number of
Tim> years, and who have commit authority, can tend to forget the many
Tim> obstacles that are in front of someone starting work on GCC,
Tim> particularly on a front end.

I've also been through this.  And yes, it is very hard... GCC's
internals have improved greatly in the past years, but there is still
a long way to go.  And, the front end interfaces don't get as much
attention as we might like.

Tim> In particular the front end documentation has traditionally been
Tim> considerably more limited than the documentation for the rest of
Tim> GCC.

Yes.  How can we fix this?

I usually recommend that aspiring front end writers read tree.def (the
most useful source) and skim tree.h (still useful but also a lot of
unreadable goo).

This is not really enough, though.  There are many things that are
undocumented.  And, there is little differentiation inside GCC between
the requirements of different phases of the compiler.

Maybe we could start documenting the tree API in more detail?  I'm a
fan of extracting documentation from the code, a la javadoc.  I feel
that this improves the likelihood that the documentation will actually
be updated when the code is changed.

And, maybe we could simplify the header file situation as
well.. provide a single "front-end.h" or something like that.

Anyway... fixing things here is not a super high priority for me, it
is more like a wish.  And, I've been reluctant to open this topic in
the past.  But maybe a few of us could band together to work on it a
bit.

Tim> As a result, the COBOL compiler will be a separate executable,
Tim> and will pass a binary file to a mini-front end that interfaces
Tim> to the GCC back end.

I wonder whether you've considered writing your front end as a
library.  This preserves the separation of the bulk of your FE from
GCC, but also turns many kinds of divergences into compile-time
errors, and removes a potential source of fragility (i.e, why write
out some binary serialization rather than just C?).

This is the approach I took with gcjx.  I did this primarily because I
did not want to use trees for my IR -- I am not a fan of trees,
really.  Like your FE, gcjx supported multiple back ends.  The gcc
side was the minimal code needed to lower the gcjx IR to trees, plus
the required langhooks and whatnot that all FEs need.

Tom

Re: Patch: delete treelang

[Tim Josling]

On Sat, 2008-03-08 at 09:58 -0700, Tom Tromey wrote:
> >>>>> "Tim" == Tim Josling <tejgcc@westnet.com.au> writes:

> Tim> I suspect that people who have worked on GCC full time for a number of
> Tim> years, and who have commit authority, can tend to forget the many
> Tim> obstacles that are in front of someone starting work on GCC,
> Tim> particularly on a front end.
> 
> I've also been through this.  And yes, it is very hard... GCC's
> internals have improved greatly in the past years, but there is still
> a long way to go.

I'm  not sure this is true, in terms of complexity, compilation speed,
quality of code produced, and the general experience for a front end
developer. I have been putting together a more detailed analysis of
these issues but now is not the time.

> I wonder whether you've considered writing your front end as a
> library.

The Lisp compilers do not realistically support running as a library so
this is not an option for me. Similar problems exist for hooking into
GCC from any high level language such as Ruby or Python. Using GCC in a
just in time compiler is also very difficult (see the paper from the GCC
summit 2007 on this topic). The GCC top end insists on being in charge
and so does the interpreter run-time. Partly this is a historical legacy
in that RMS did not want GCC exported as a library.

> Tom

Tim Josling

Re: Patch: delete treelang

[Joseph S. Myers]

On Sat, 8 Mar 2008, Tom Tromey wrote:

> Maybe we could start documenting the tree API in more detail?  I'm a
> fan of extracting documentation from the code, a la javadoc.  I feel

Maybe once the FSF has produced the GPLv3 exception wording for all the 
runtime library code where GCC is still using GPLv2, the SC could ask them 
for appropriate wording to allow documentation to be extracted and used in 
GFDL manuals?  (There are other cases it might be useful for, e.g. the 
documentation of target-specific asm constraints.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Patch: delete treelang

[Richard Guenther]

On Thu, Mar 6, 2008 at 12:19 AM, Tom Tromey <tromey@redhat.com> wrote:
> Today I was debugging treelang on my branch and wondering why I was
>  bothering.  Then I remembered suggesting its deletion once before:
>
>  http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01119.html
>
>  Andrew Pinski had the only objection, based on it not being much work.
>  I don't consider that a very strong reason to keep something in the
>  tree.  For instance, our standard for back ends is higher.
>
>  So, this patch removes treelang.
>
>  I've omitted all the deletions from the patch.  I can re-send if you
>  really want to see 300K of them :)
>
>  Bootstrapped and regtested on the compile farm.
>  Ok?

I cannot approve this, but +1 for removing an example that isn't a good
one anymore.

Thanks,
Richard.

Re: Patch: delete treelang

[Rafael Espindola]

2008/3/6 Ben Elliston <bje@au1.ibm.com>:
> I agree with you, Tom.  There comes a point where maintaining an example
>  front-end to aid developers comes at a greater expense than just helping
>  the developers of new front-ends (or improving the documentation).

And it is not such a good example anymore (since 4.0 at least).

+1 for the patch

>  Ben
>
>
>


-- 
Rafael Avila de Espindola

Google Ireland Ltd.
Gordon House
Barrow Street
Dublin 4
Ireland

Registered in Dublin, Ireland
Registration Number: 368047

Re: Patch: delete treelang

[Ben Elliston]

I agree with you, Tom.  There comes a point where maintaining an example
front-end to aid developers comes at a greater expense than just helping
the developers of new front-ends (or improving the documentation).

Ben

Re: Patch: delete treelang

[Diego Novillo]

On Wed, Mar 5, 2008 at 18:19, Tom Tromey <tromey@redhat.com> wrote:

>  Bootstrapped and regtested on the compile farm.
>  Ok?

I don't think I can unilaterally approve this, but it has my
enthusiastic vote in favour.


Diego.

Patch: delete treelang

[Tom Tromey]

Today I was debugging treelang on my branch and wondering why I was
bothering.  Then I remembered suggesting its deletion once before:

http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01119.html

Andrew Pinski had the only objection, based on it not being much work.
I don't consider that a very strong reason to keep something in the
tree.  For instance, our standard for back ends is higher.

So, this patch removes treelang.

I've omitted all the deletions from the patch.  I can re-send if you
really want to see 300K of them :)

Bootstrapped and regtested on the compile farm.
Ok?

Tom


ChangeLog:
2008-03-05  Tom Tromey  <tromey@redhat.com>

	* treelang: Delete.
	* doc/standards.texi (Standards): Don't mention treelang.
	* doc/invoke.texi (Overall Options): Don't mention treelang.
	* doc/install.texi (Prerequisites): Don't mention bison or
	treelang.
	(Configuration): Don't mention treelang.
	(Building): Likewise.
	* doc/frontends.texi (G++ and GCC): Don't mention treelang.

testsuite/ChangeLog:
2008-03-05  Tom Tromey  <tromey@redhat.com>

	* lib/treelang-dg.exp, lib/treelang.exp: Delete.
	* treelang: Delete.

Index: doc/standards.texi
===================================================================
--- doc/standards.texi	(revision 132902)
+++ doc/standards.texi	(working copy)
@@ -1,4 +1,4 @@
-@c Copyright (C) 2000, 2001, 2002, 2004, 2006, 2007 Free Software Foundation,
+@c Copyright (C) 2000, 2001, 2002, 2004, 2006, 2007, 2008 Free Software Foundation,
 @c Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
@@ -219,14 +219,6 @@
 have additional useful information.
 @end itemize
 
-@section Treelang language
-@cindex treelang
-There is no standard for treelang, which is a sample language front end
-for GCC@.  Its only purpose is as a sample for people wishing to write a
-new language for GCC@.  The language is documented in
-@file{gcc/treelang/treelang.texi} which can be turned into info or
-HTML format.
-
 @xref{Top, GNAT Reference Manual, About This Guide, gnat_rm,
 GNAT Reference Manual}, for information on standard
 conformance and compatibility of the Ada compiler.
Index: doc/invoke.texi
===================================================================
--- doc/invoke.texi	(revision 132902)
+++ doc/invoke.texi	(working copy)
@@ -1001,7 +1001,6 @@
 ada
 f95  f95-cpp-input
 java
-treelang
 @end smallexample
 
 @item -x none
Index: doc/frontends.texi
===================================================================
--- doc/frontends.texi	(revision 132902)
+++ doc/frontends.texi	(working copy)
@@ -1,5 +1,5 @@
 @c Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
-@c 1999, 2000, 2001, 2002, 2004 Free Software Foundation, Inc.
+@c 1999, 2000, 2001, 2002, 2004, 2008 Free Software Foundation, Inc.
 @c This is part of the GCC manual.
 @c For copying conditions, see the file gcc.texi.
 
@@ -14,7 +14,6 @@
 @cindex Java
 @cindex Objective-C
 @cindex Objective-C++
-@cindex treelang
 GCC stands for ``GNU Compiler Collection''.  GCC is an integrated
 distribution of compilers for several major programming languages.  These
 languages currently include C, C++, Objective-C, Objective-C++, Java,
Index: doc/install.texi
===================================================================
--- doc/install.texi	(revision 132902)
+++ doc/install.texi	(working copy)
@@ -372,16 +372,6 @@
 Necessary to regenerate the top level @file{Makefile.in} file from
 @file{Makefile.tpl} and @file{Makefile.def}.
 
-@item GNU Bison version 1.28 (or later)
-
-Necessary when modifying @file{*.y} files.  Necessary to build the
-@code{treelang} front end (which is not enabled by default) from a
-checkout of the SVN repository; the generated files are not in the
-repository.  They are included in releases.
-
-Berkeley @command{yacc} (@command{byacc}) has been reported to work
-as well.
-
 @item Flex version 2.5.4 (or later)
 
 Necessary when modifying @file{*.l} files.
@@ -1161,11 +1151,11 @@
 @end smallexample
 Currently, you can use any of the following:
 @code{all}, @code{ada}, @code{c}, @code{c++}, @code{fortran}, @code{java},
-@code{objc}, @code{obj-c++}, @code{treelang}.
+@code{objc}, @code{obj-c++}.
 Building the Ada compiler has special requirements, see below.
 If you do not pass this flag, or specify the option @code{all}, then all
 default languages available in the @file{gcc} sub-tree will be configured.
-Ada, Objective-C++, and treelang are not default languages; the rest are.
+Ada and Objective-C++ are not default languages; the rest are.
 Re-defining @code{LANGUAGES} when calling @samp{make} @strong{does not}
 work anymore, as those language sub-directories might not have been
 configured!
@@ -1707,18 +1697,13 @@
 
 The solution is not to use such a directory for building GCC@.
 
-When building from SVN or snapshots and enabling the @code{treelang}
-front end, or if you modify @file{*.y} files, you need the Bison parser
-generator installed.  If you do not modify @file{*.y} files, releases
-contain the Bison-generated files and you do not need Bison installed
-to build them.  Note that most front ends now use hand-written parsers,
-which can be modified with no need for Bison.
-
 Similarly, when building from SVN or snapshots, or if you modify
-@file{*.l} files, you need the Flex lexical analyzer generator installed.
-There is still one Flex-based lexical analyzer (part of the build
-machinery, not of GCC itself) that is used even if you only build the
-C front end.
+@file{*.l} files, you need the Flex lexical analyzer generator
+installed.  If you do not modify @file{*.l} files, releases contain
+the Flex-generated files and you do not need Flex installed to build
+them.  There is still one Flex-based lexical analyzer (part of the
+build machinery, not of GCC itself) that is used even if you only
+build the C front end.
 
 When building from SVN or snapshots, or if you modify Texinfo
 documentation, you need version 4.4 or later of Texinfo installed if you