www.digitalmars.com         C & C++   DMDScript  

D.gnu - the D front-end

reply "Steven Shaw" <steven_shaw iprimus.com.au> writes:
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.
Jul 02 2002
next sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
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
Jul 02 2002
parent reply andy <acoliver apache.org> writes:
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
Jul 02 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
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
Jul 02 2002
parent reply ben <zander echotech.ca> writes:
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
Jul 03 2002
parent reply andy <acoliver apache.org> writes:
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
Jul 03 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
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
Jul 04 2002
parent reply andy <acoliver apache.org> writes:
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
Jul 04 2002
parent Jan Knepper <jan smartsoft.cc> writes:
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
Jul 05 2002
prev sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
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
Jul 11 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
 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.


Well, that would be an other project.

Currently we are working on a GLUE layer between the D-front-end and the
GCC-back-end.

Jan
Jul 11 2002
parent reply andy <acoliver apache.org> writes:
I regard this as a chicken and the egg kinda thing.  We need a cross 
platform D compiler before we can write a front end in D.  And if we 
wanted to write the cross platform D compiler, we'd need a D front end.

So from my perspective the long term goal should be as follows:

1. Attach the existing C++ front end to GCC via glue code
2. Make it work nice and get people interested in using it
3. If Walter is up for it (which he said he's interested in the idea), 
create a D front end in D and adapt said GCC glue code.
4. Create a bootstrapping process that allows one to compile gcc + D 
with either the existing version or a previous version (the C++ version)

The same arguments against rewriting the D front-end in C currently 
apply to re-writing it in D.  Meaning we should only do so once walter 
is ready to convert to a D front end to avoid having divergent front ends.

Personally, my interest is in getting a cross-platform D compiler.  I'll 
be working hard with others to achieve this goal.  While I'd enjoy it if 
we had a written-in-D version, its not something I'd likely donate much 
of my own time for, but would gladly help others.

Once we have a cross-platform D compiler, my main interest will be in 
creating a rich API.  Creating libraries that make it easy to port 
legacy Java code to D, etc.

Or at least thats my thinking.

-Andy


Jan Knepper wrote:

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.


 
 
 Well, that would be an other project.
 
 Currently we are working on a GLUE layer between the D-front-end and the
 GCC-back-end.
 
 Jan
Jul 11 2002
parent Jan Knepper <jan smartsoft.cc> writes:
andy wrote:


 I regard this as a chicken and the egg kinda thing.  We need a cross
 platform D compiler before we can write a front end in D.  And if we
 wanted to write the cross platform D compiler, we'd need a D front end.


<g>


 So from my perspective the long term goal should be as follows:

 1. Attach the existing C++ front end to GCC via glue code
 2. Make it work nice and get people interested in using it
 3. If Walter is up for it (which he said he's interested in the idea), create
 a D front end in D and adapt said GCC glue code.


I am very PRO leaving "3" up to Walter as the whole idea of the GLUE layer is
not to touch the current D front-end (written in C++) nor touch the GCC back-end
(written in C)


 4. Create a bootstrapping process that allows one to compile gcc + D with
 either the existing version or a previous version (the C++ version)


Let's wait for "3" first on that one! <g>


 The same arguments against rewriting the D front-end in C currently apply to
 re-writing it in D.  Meaning we should only do so once walter is ready to
 convert to a D front end to avoid having divergent front ends.


Certainly! Agreed!


 Personally, my interest is in getting a cross-platform D compiler.  I'll be
 working hard with others to achieve this goal.  While I'd enjoy it if we had a
 written-in-D version, its not something I'd likely donate much of my own time
 for, but would gladly help others.


Neither would I.
I think writing the D-front-end is Walter's thing to do.


 Once we have a cross-platform D compiler, my main interest will be in creating
 a rich API.  Creating libraries that make it easy to port legacy Java code to
 D, etc.



 Or at least thats my thinking.


Makes sense...

Jan
Jul 11 2002