Re: ICE in change_address at emit_rtl.c

[Daniel Berlin <dan at cgsoftware dot com>]

On Mon, 26 Nov 2001, Fergus Henderson wrote:

> On 24-Nov-2001, Neil Booth <neil@daikokuya.demon.co.uk> wrote:
> > I've often wondered whether we might do better type-wise to actually
> > use separate types, and refer to them as separate types, rather than
> > having every function take an effectively typeless "tree" as input.
> > This alone would help type safety quite a bit.
>
> FWIW I took this approach when writing the Mercury interface to the
> GCC "tree" type -- I had separate Mercury types for tree nodes
> representing expressions, declarations, types, initializers, etc.
> For my purposes this approach worked fairly well.

FWIW also (the idea of generating the tree structures using one of the
various ast/tree tools around  usually comes up in these discussions )
, over the past year, i've tried to rewrite our tree datatype
using various AST/tree code producerss (IE kimwitu, ASDL, etc. If it's
out there, I've tried it.).
Not only to ease serialization, but because most of these tools also let
you specify tree walkers/etc in nice forms.

They either had limitations that were unacceptable (ASDL's picklers only
handle acyclic structures), generated code that was unacceptable (either
too many support libs required,  not integratable into what we have now
without a *lot* of work, etc), or couldn't handle the complex structure we
have now in an elegant way.

However, today i ran across treecc.
It was written by the portable.net people for their c# compiler, but can
generate readable C/C++/Java/C# code.
Although it doesn't produce code to serialize the structure, the tool is
easily modifable to do so (i can actually understand the source code
easily, unlike some of the other tools).
It also seems to already support most, if not all, of the features we
would need to generate our tree structures (tree structure inheritance,
abstract bases,and fields that are marked as not required to be
passed to the constructor it generates).
It also is easy to write the various walkers in, if you wanted to (though
it's not required).
The resulting c code could stand a little factoring, but that's no biggie
to implement.
It's not too difficult at all to integrate with what we have now (if it
requires any changes at all to start)

In other words, it would be a usable tool for the purposes of generating
the tree structures gcc uses.
First one i've come across.

Just thought i'd point it out,
Dan

 > --
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
> The University of Melbourne         |  of excellence is a lethal habit"
> WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
>