Re: Introspector & Treecc (was: [DotGNU]Licence question about GNU and GCC)

[James Michael DuPont]

Rhys,
You have caught me guessing about things that I have
not looked into enough, let me leave the issues of the
optimisation and rtl up to the people who know about
them.  You have done much more work on this and I dont
want waste time going over the same tracks over and
over again in circles.

The original interest of mine was the treecc tool and
the similarities of that to the introspector. I will
be concentrating on that area where I can make a
difference. 

> > Good, Then we can glue the CIL decoder as a gcc
> > frontend?
> Anything is possible.  It's all just 1's and 0's
> after all.
> Do I personally have time to do it?  No.  It 
> would need a volunteer to step up for it.
I dont know how expressive the CIL is yet, I am just
poking in the dark. The mono-project seems to have a
disassembler going.....

> I'm also worried that this may turn gcc into a super
> assembler, providing a way to circumvent the GPL.
I see that as also an issue, that will also not be the
best return on investment for the gnu project. 
a C# front-end would be a better investment.

> > > But the  question is will this be useful ?.
> > To be able to create a native exe via tha gcc
> given a
> > CIL file? yes!
> 
> I think you would be better off starting with C#,
> instead of CIL.  i.e. make pnet's C# compiler output
> C instead of CIL/JVM bytecode.  This gives you
> more access to the semantics of C#, and can hence
> generate C code that is more likely to compile well.
That would amount a C# front end to gcc, still a
worthy goal, and on the level where I might be able to
help. This brings us back to the mapping of the trees
from the treecc to the gcc/asts.

I have read your essay on the aspect oriented
programming and the implementation of the parser. You
presented some very interesting ideas. 

It should be possible to create more aspects of the
trees such as reflection, serialisation, 
visualisation, persistance and transformation
algorithms. 

A pattern and rule based tranformation language
similar to xslt/scheme/lisp would be interesting and
usefull for representing the tranformations from the
c# to the gcc asts. 

We have to find a way to have a single data structure
with possibly many interfaces.

The analogy of a DOM is what is burning in my mind.

For some tree nodes types we should be able to present
the gcc interface and the treecc interface to the
exact same chunk of memory! For others we might have
other cardinalities.

I think that the rtl and cil levels are over my head,
to be blunt. I have only been 
concentrating on the tree nodes. 
 
> i.e. "while" for "for" loops can be directly mapped
> into the same construct in C, which helps gcc when
> the code is compiled and optimised.  CIL uses raw
> branch instructions, which are harder to de-compile
> back to constructs that gcc can optimise well.
I see, we need to grab the trees before they get into
that representation, the transformations have to take
place on the level that is close to the original
representation.

> I've already thought about putting a C back-end
> into cscc, but there are lots of other fish to fry
first.
A gcc front end at hooked to the CIL backed would be
possibly better than c generation but basically the
same effect. By using the tree, you can also use many
features of the gcc.

> There are also difficult issues: how to support
> reflection, for example.
Now we are talking! 

That is what I have been thinking about alot.

The gcc supports reflection in the gcj, and 
the mono has an interesting module that encodes the
meta information into a data structure for the
run-time. All written in c.

Currently I am prototyping reflective models,
and the api to a reflection system. 
The most important feature for me is to create the
reflection system in such a way that it is available
via a simple c-api that would be usable from a simple
c program. 

In a postgres database, I am storing the meta
information about the program. Interesting is that if
you were to be able to pull in the meta data that is
needed, like a form of linking.

The encoding of this meta-data back into the target
program will have to be as small as possible. In one
way it is like accessing a code browser database, but
the data is linked into the executable.

At the lowest level, this meta information is the full
set of asts that make up the source program, but that
is a huge data set! We need to support at least the
reflection api of c#.

> > After that we can try and get the CIL back out,
> > after the optimisation takes place.
> 
> Are you trying to run CIL through gcc so you can
> optimise it, and then get better CIL out the other
> end?
That is what crossed my mind yes.

> If so, you need a CIL back-end in gcc to do that.
> Perhaps you may want to read the pnet FAQ to see
> just how difficult this really is:

There are certain optimisations that wont be
applicable, and I have not got into the rtl yet. 
Yes I have read the faq, and you have done your
homework. I will take back all the statements on the
gcc output to CIL. That was not thought through to the
end. Let us concentrate on the reflection aspect for
now.

Yours Truly,
Mike



=====
James Michael DuPont

__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/