James A. Morrison wrote:

Ed Smith-Rowland <[EMAIL PROTECTED]> writes:



On 1 Mar 2005 at 8:17, James A. Morrison wrote:



Hi,
I've decided I'm going to try to take the time and cleanup and
update
the
Pascal frontend for gcc and try it get it integrated into the upstream
source. I'm doing this because I wouldn't like to see GPC work with GCC
4+. I don't care at all at supporting GPC on anything less than GCC 4.1
so I've started by ripping out as much obviously compatibility code as I
can and removing any traces of GPC being a separate project.


My guess is that inclusion of Pascal into gcc would give that language
more exposure and would lead to faster development.

By many accounts gcc-4 is getting faster.  It would be nice to see pascal
take advantage of this rather than being marooned on 3.x.

I, for one, am more likely to play with a gpascal that bootstraps with
mainline than to try to build one with, perhaps unusual, dependencies
and some different version of gcc.

I am learning gcc internals slowly (this is a part-time after-work effort :-P)
but I would be interested in helping wherever I can.



Grab the source and see what you can do.


I will do that.




So far I have only accomplished converting lang-options.h to
lang.opt. I'm going
to continue cleaning up the GPC code, then once I am happy with how the code
looks with respect to the rest of the GCC code, I'm going to get it to
compile with
the current version of GCC mainline. I'm starting with the boring
conflict happy
whitespace changes first so the code is easier for me to read and so that I can
try to get an idea what the GPC frontend is doing.


Before we get too far with this I think we should keep an eye on a trend in gcc
at least through 3.4 and 4.0:  Front ends are increasingly written by hand 
rather
than with flex and bison.  This is true for C++ as of 3.4 and for C as of 4.1.
I'm pretty sure it's true for gfortran too.  I think this is true for gcjx too.
The latter is written in C++ to boot.

My understandng is that gpc uses flex/bison in a p2c - a pascal to C translator.
I would like to know why folks think hand written parsers are better.  My guess 
is that
they are easier to maintain and that they support more lookahead.

A gpascal front end effort might do well to take a hard look at the new front ends
for C and C++ (and Java) and consider a rewrite from scratch using these as models.



Feel free to write your own parser, I have no desire to do that.


I have no desire to write my own parser. I want to steal someone else's ;-).

I was just wondering what the best one to steal was given the long term goals of
1) Integration into GCC-4.x
2) Happy maintainable code
3) Entertainment


In fact, I'm somewhat curious what caused folks to jump into the breach with parsers. From reading the lists it seems to be maintainability and stomping out corner case problems for the most part.

Perhaps a parser toolset is emerging that will decouple the front ends from the middle and back ends to a greater degree. I think I will look at the new C/C++ parsers and see what's what.

My current changes are available through bazaar (an arch implementation) which
people can get with:
baz register-archive http://www.csclub.uwaterloo.ca/~ja2morri/arch <http://www.csclub.uwaterloo.ca/%7Eja2morri/arch>
baz get [EMAIL PROTECTED]/gcc-pascal--mainline--0.3


There is another trend in gcc: a move toward Subversion from CVS.  I realize 
this
is a first-try effort but there would probably be less regret later if we adopt
the standard toolchain.  The decision to go to Subversion was not taken lightly.

Ed Smith-Rowland



I don't think it makes a difference. If this little project of mine does start moving I'll put the code in CVS/SVN at that time. Until then, I'm taking an opportunity to play with bazaar.



I'm all for grabbing new tools and playing with them. I have a huge relational database collection and a script language collection. In fact, I think I'll check out bazaar and arch and start a revision control system collection :-).

Ed Smith-Rowland


Reply via email to