Hi guys,

I've noticed that you have been spending much time figuring about how to port Walter's D frontend to C in order to use the GCC backend to generate native code. The Modula-3 compiler was written in Modula-3 and compiled via GCC (an old version) in order to produce machine code. Then I found this:

    http://gcc.gnu.org/frontends.html

The Mercury compiler is written in Mercury too (and uses GCC for a backend).

It shouldn't matter what language the frontend is written in (as long as
that language can produce C structure or call C functions or something).
Therefore it will be best to use Walter's (already written) frontend for D.
It will make it easy when the language evolves (as it will).

What I think must be done to hook the D frontend into the GCC backend is to traverse the D semantically verified abstract-syntax-tree (assuming there is one) and produce a RTL structure. Then hand this RTL tree to the GCC backend for code generation. This is my simplistic understanding.

I don't know how hard something like that would be. Maybe it would be easier to start by just generating C code instead of using the GCC backend. There's also "Quick C--" from cminusminus.org backend (but it seems to be a work in progress).

    http://www.cminusminus.org/qc--.html

Note that I don't know the GCC sources and I'm only a newbie compiler person.

regards,
Steve.

Steven Shaw wrote:

> I've noticed that you have been spending much time figuring about how to port Walter's D frontend to C in order to use the GCC backend to generate native code. The Modula-3 compiler was written in Modula-3 and compiled via GCC (an old version) in order to produce machine code. Then I found this:
>
>     http://gcc.gnu.org/frontends.html

Thanks 1E6!

> The Mercury compiler is written in Mercury too (and uses GCC for a backend).

Cool! I didn't doubt once that the D front end could stay in C++.

> It shouldn't matter what language the frontend is written in (as long as
> that language can produce C structure or call C functions or something).
> Therefore it will be best to use Walter's (already written) frontend for D.
> It will make it easy when the language evolves (as it will).

That's EXACTLY my understanding.

> What I think must be done to hook the D frontend into the GCC backend is to traverse the D semantically verified abstract-syntax-tree (assuming there is one) and produce a RTL structure. Then hand this RTL tree to the GCC backend for code generation. This is my simplistic understanding.

Yes! I had not written it in the group here. You just took the ground from under my feet, but this is what I discovered last weekend as well when reading through some of the GCC docco.

> I don't know how hard something like that would be. Maybe it would be easier to start by just generating C code instead of using the GCC backend. There's also "Quick C--" from cminusminus.org backend (but it seems to be a work in progress).

That's something that will need to be seen and is certainly a different approach.

>     http://www.cminusminus.org/qc--.html
>
> Note that I don't know the GCC sources and I'm only a newbie compiler person.

Well, they are availlable, but the compile process is kinda complicated.

Jan

>>The Mercury compiler is written in Mercury too (and uses GCC for a backend).
>

I was not aware of that.  I'll take a look.

> 
> Cool! I didn't doubt once that the D front end could stay in C++.
> 

Really...  I actually thing based on above that it should one day be written in D...

> 
>>It shouldn't matter what language the frontend is written in (as long as
>>that language can produce C structure or call C functions or something).
>>Therefore it will be best to use Walter's (already written) frontend for D.
>>It will make it easy when the language evolves (as it will).
> 
> 
> That's EXACTLY my understanding.
> 

I hope your understanding is correct.

> 
>>What I think must be done to hook the D frontend into the GCC backend is to
>>traverse the D semantically verified abstract-syntax-tree (assuming there is
>>one) and produce a RTL structure. Then hand this RTL tree to the GCC backend
>>for code generation. This is my simplistic understanding.
> 
> 
> Yes! I had not written it in the group here. You just took the ground from under
> my feet, but this is what I discovered last weekend as well when reading through
> some of the GCC docco.
> 

Thats my understanding.  The hard part will be becoming one with the RTL tree structure.

> 
>>I don't know how hard something like that would be. Maybe it would be easier
>>to start by just generating C code instead of using the GCC backend. There's
>>also "Quick C--" from cminusminus.org backend (but it seems to be a work in
>>progress).
> 
> 
> That's something that will need to be seen and is certainly a different
> approach.
> 
> 

I do not favor that approach at all to be honest.  I'd sooner rewrite the front end in C than generate C from C++.  My interest is in having a cross platform D compiler.  My secondary interest is in having one that might readily attract a user community.  A GCC front end seems the best way to do that.

While I've no interest in coding such a massive undertaking, a from scratch written in D cross-platform compiler would be even better -- but it would likely be at the expense of supporting a lot of different platforms as GCC does.  So maybe not.

>>    http://www.cminusminus.org/qc--.html
>>
>>Note that I don't know the GCC sources and I'm only a newbie compiler
>>person.
> 
> 
> Well, they are availlable, but the compile process is kinda complicated.
> 

That would be an understatement.

How is your POC coming along Jan?

-Andy

> Jan
> 
> 

andy wrote:

> >>The Mercury compiler is written in Mercury too (and uses GCC for a backend).
> I was not aware of that.  I'll take a look.
>
> > Cool! I didn't doubt once that the D front end could stay in C++.
> Really...  I actually thing based on above that it should one day be written in D...

It probably will, once Walter gets D really going he might considers writing all new compiler in D...

> >>It shouldn't matter what language the frontend is written in (as long as
> >>that language can produce C structure or call C functions or something).
> >>Therefore it will be best to use Walter's (already written) frontend for D.
> >>It will make it easy when the language evolves (as it will).
> > That's EXACTLY my understanding.
> I hope your understanding is correct.

So do I! <g>

> >>What I think must be done to hook the D frontend into the GCC backend is to traverse the D semantically verified abstract-syntax-tree (assuming there is one) and produce a RTL structure. Then hand this RTL tree to the GCC backend for code generation. This is my simplistic understanding.
> > Yes! I had not written it in the group here. You just took the ground from under my feet, but this is what I discovered last weekend as well when reading through some of the GCC docco.
> Thats my understanding.  The hard part will be becoming one with the RTL tree structure.

That is the difficult part...

> >>I don't know how hard something like that would be. Maybe it would be easier to start by just generating C code instead of using the GCC backend. There's also "Quick C--" from cminusminus.org backend (but it seems to be a work in progress).
> > That's something that will need to be seen and is certainly a different approach.
> I do not favor that approach at all to be honest.  I'd sooner rewrite the front end in C than generate C from C++.  My interest is in having a cross platform D compiler.  My secondary interest is in having one that might readily attract a user community.  A GCC front end seems the best way to do that.

It is my least favorite aproach too, but nevertheless, still an aproach...

> While I've no interest in coding such a massive undertaking, a from scratch written in D cross-platform compiler would be even better -- but it would likely be at the expense of supporting a lot of different platforms as GCC does.  So maybe not.

Well, that would be something for Walter to do. I know the C++ compiler has a started Linux port, but I never heard that it was actually finished.

> >>    http://www.cminusminus.org/qc--.html
> >>Note that I don't know the GCC sources and I'm only a newbie compiler person.
> > Well, they are availlable, but the compile process is kinda complicated.
> That would be an understatement.

<g>

> How is your POC coming along Jan?

Well, regarding the time I got to spend on it last weekend. I am in the middle of an office move, so I run the compilation of GCC while I was building the desk and storage... <g>

Jan

Jan Knepper wrote:

> andy wrote:
> 
>> >>The Mercury compiler is written in Mercury too (and uses GCC for a
>> >>backend).
>> I was not aware of that.  I'll take a look.
>>
>> > Cool! I didn't doubt once that the D front end could stay in C++.
>> Really...  I actually thing based on above that it should one day be written in D...
> 
> It probably will, once Walter gets D really going he might considers writing all new compiler in D...
> 
>> >>It shouldn't matter what language the frontend is written in (as long
>> >>as that language can produce C structure or call C functions or
>> >>something). Therefore it will be best to use Walter's (already written)
>> >>frontend for D. It will make it easy when the language evolves (as it
>> >>will).
>> > That's EXACTLY my understanding.
>> I hope your understanding is correct.
> 
> So do I! <g>
> 
>> >>What I think must be done to hook the D frontend into the GCC backend is to traverse the D semantically verified abstract-syntax-tree (assuming there is one) and produce a RTL structure. Then hand this RTL tree to the GCC backend for code generation. This is my simplistic understanding.
>> > Yes! I had not written it in the group here. You just took the ground from under my feet, but this is what I discovered last weekend as well when reading through some of the GCC docco.
>> Thats my understanding.  The hard part will be becoming one with the RTL tree structure.
> 
> That is the difficult part...
> 
>> >>I don't know how hard something like that would be. Maybe it would be easier to start by just generating C code instead of using the GCC backend. There's also "Quick C--" from cminusminus.org backend (but it seems to be a work in progress).
>> > That's something that will need to be seen and is certainly a different approach.
>> I do not favor that approach at all to be honest.  I'd sooner rewrite the front end in C than generate C from C++.  My interest is in having a cross platform D compiler.  My secondary interest is in having one that might readily attract a user community.  A GCC front end seems the best way to do that.
> 
> It is my least favorite aproach too, but nevertheless, still an aproach...
> 
>> While I've no interest in coding such a massive undertaking, a from scratch written in D cross-platform compiler would be even better -- but it would likely be at the expense of supporting a lot of different platforms as GCC does.  So maybe not.
> 
> Well, that would be something for Walter to do. I know the C++ compiler has a started Linux port, but I never heard that it was actually finished.
> 
>> >>    http://www.cminusminus.org/qc--.html
>> >>Note that I don't know the GCC sources and I'm only a newbie compiler person.
>> > Well, they are availlable, but the compile process is kinda complicated.
>> That would be an understatement.
> 
> <g>
> 
>> How is your POC coming along Jan?
> 
> Well, regarding the time I got to spend on it last weekend. I am in the middle of an office move, so I run the compilation of GCC while I was building the desk and storage... <g>
> 
> Jan

Hello everybody..

Hey thanks for the information on mercury.. Its helpful, now its on to the problem, and that is genarating the tree.. I have been reading about it but i have not gotten very far with it.. How is everybody else doing..

Later, Ben

My advice:

1. Don't concentrate on the tree, that may be months and months of hard work.

2. Get GCC to build.

3. Get the toy example or one of the others like it to build.

4. Convert it to C++ and create a build around it.

5. Get that to build

6. Show us what you did.

7. Sync up.  We'll then plan an approach to attach the D front end and divide up the labor.

8. Then we tackle (picture hugging with american football gear on) the tree.


> 
> Hello everybody.. 
> 
> Hey thanks for the information on mercury.. Its helpful, now its on to the problem, and that is genarating the tree.. I have been reading about it but i have not gotten very far with it.. How is everybody else doing.. 
> 
> Later, Ben

andy wrote:

> My advice:
>
> 1. Don't concentrate on the tree, that may be months and months of hard work.

That is getting close now.

> 2. Get GCC to build.

Done!

> 3. Get the toy example or one of the others like it to build.

Done!

> 4. Convert it to C++ and create a build around it.

It does not have a C++ class (yet), but it is toy2.cpp now and the build invokes
c++ instead of cc.

> 5. Get that to build

Done!

> 6. Show us what you did.

Will as soon as I also have a C++ class in toy2.cpp.

> 7. Sync up.  We'll then plan an approach to attach the D front end and divide up the labor.

That'll have to wait for 6...

Jan

Jan Knepper wrote:
> andy wrote:
> 
> 
>>My advice:
>>
>>1. Don't concentrate on the tree, that may be months and months of hard
>>work.
> 
> 
> That is getting close now.
> 
>

eeexcellent.  By monday I should be swimming again or sunk/drown to the bottom of my workload.


>>2. Get GCC to build.
> 
> 
> Done!
> 

excellent.

> 
>>3. Get the toy example or one of the others like it to build.
> 
> 
> Done!
> 

great.  See wasn't too bad.

> 
>>4. Convert it to C++ and create a build around it.
> 
> 
> It does not have a C++ class (yet), but it is toy2.cpp now and the build invokes
> c++ instead of cc.
> 

Thats an accomplishment.

> 
>>5. Get that to build
> 
> 
> Done!
> 

well mostly done.

> 
>>6. Show us what you did.
> 
> 
> Will as soon as I also have a C++ class in toy2.cpp.
> 

great.

> 
>>7. Sync up.  We'll then plan an approach to attach the D front end and divide
>>up the labor.
> 
> 
> That'll have to wait for 6...
>

excellent.

> Jan
> 
> 

> >>3. Get the toy example or one of the others like it to build.
> > Done!
> great.  See wasn't too bad.

Not bad at all, it just has to be in the right directory <g>

> >>4. Convert it to C++ and create a build around it.
> > It does not have a C++ class (yet), but it is toy2.cpp now and the build invokes
> > c++ instead of cc.
> Thats an accomplishment.

The whole excercise took a couple of hours, no more than 4 while waiting for other compiles to finish...

> >>5. Get that to build
> > Done!
> well mostly done.

Not quite. For D there is going to be a lot more to do <g>

> >>6. Show us what you did.
> > Will as soon as I also have a C++ class in toy2.cpp.
> great.

Which might be after the weekend.

Jan

Hi,

"Steven Shaw" <steven_shaw@iprimus.com.au> wrote in message news:afs9o7$20ts$1@digitaldaemon.com...
> Maybe it would be easier to start by just generating C code instead of
using the GCC backend.

That's the dfront idea, and I like it. It has some nice properties:

1. It allows dfront to be rewritten in D itself. It can be compiled using
Walter's compiler, and the generated C source can be compiled on another
platform.
2. dfront boldly goes where GCC has never gone before, thereby maximizing
portability.
3. The front-end part can be integrated into GCC without the C++ concerns.

Rewriting the front-end in D is not necessary, but it will seriously test the language, and - if succesful - be a valuable prof of concept.

Regards,
Martin M. Pedersen