www.digitalmars.com         C & C++   DMDScript  

D.gnu - Re: Alive?

reply resistor mac.com writes:
What happened to the guys who were working on the GCC port?  I don't think a
binary release for 
other platforms is sufficient.  I really think D could be great, but without a
backend to GCC it's 
going to be almost impossible for it to get wide use.  Like I said before, I
want to run it on my Mac 
OS X system!

Owen
Nov 05 2003
parent reply Ilya Minkov <midiclub tiscali.de> writes:
PLEASE STOP MOANING!

If everyone who wants a compiler only keeps moaning than we will have 
*no* portable compiler ever!

I'll try to write a simple example back-end, which all it does is dump 
code, possibly in a D-like syntax. Then it could be changed to output 
GCC-specific C or KSI.

CONSIDER HELPING.

You cannot have Walter do everything, he cannot clone himself. And even 
if he could the clone would probably only be of help in 40 years or so. 
:) And that clone would definately refuse digging in GCC. :)

I BARELY HAVE ANY TIME MYSELF!

Noone has been working on a port. Jan started some experimentation and 
investigation, but gave up because noone wanted to help, and he himself 
didn't have enough time for something which noone wants sincerely enough 
to consider helping. And that's how it's going to happen fairly often!

And now admit it: as soon as the compiler is there, you, having not 
worked on it, will not even really use it beyond trying it once or 
twice! Be ashamed of yourself!!!

-eye


resistor mac.com wrote:
 What happened to the guys who were working on the GCC port?  I don't think a
 binary release for 
 other platforms is sufficient.  I really think D could be great, but without a
 backend to GCC it's 
 going to be almost impossible for it to get wide use.  Like I said before, I
 want to run it on my Mac 
 OS X system!
 
 Owen
 

Nov 06 2003
next sibling parent reply Jan Knepper <jan smartsoft.us> writes:
Ilya Minkov wrote:

 PLEASE STOP MOANING!
 
 If everyone who wants a compiler only keeps moaning than we will have 
 *no* portable compiler ever!

Right!
 I'll try to write a simple example back-end, which all it does is dump 
 code, possibly in a D-like syntax. Then it could be changed to output 
 GCC-specific C or KSI.

That's a way to go.
 CONSIDER HELPING.

Good idea...
 You cannot have Walter do everything, he cannot clone himself. And even 
 if he could the clone would probably only be of help in 40 years or so. 
 :) And that clone would definately refuse digging in GCC. :)

Well, I could not blame him since the DM backend seems to be very good...
 I BARELY HAVE ANY TIME MYSELF!

Same here! However, there is a website www.opend.org and a CVS server cvs.opend.org.
 Noone has been working on a port. Jan started some experimentation and 
 investigation, but gave up because noone wanted to help, and he himself 
 didn't have enough time for something which noone wants sincerely enough 
 to consider helping. And that's how it's going to happen fairly often!

Actually... I have not given up on it and *if* I would not have lost about 100K in my business and would not have been 30K in debt because of it I probably would be working on it at this moment. However, I have to take care of my *life* first and making sure the Digital Mars HTTP, FTP and NEWS servers stay up. We have never been down for longer than 15 minutes and have not been down even during the Hurricane.
 And now admit it: as soon as the compiler is there, you, having not 
 worked on it, will not even really use it beyond trying it once or 
 twice! Be ashamed of yourself!!!

Would not know about that. I personally am strongly a C++ (C) and ASM type of person. D is not for me (yet) although I have written some code with it, but I would like to see D integrated into the IDDE. Walter could do this by having a .dll switch between D and C/C++ based on the file extension, i.e. ".d". This would help me and a few others a LOT by integrating D into our larger projects. -- ManiaC++ Jan Knepper
Nov 06 2003
parent Ilya Minkov <webmaster midiclub.de.vu> writes:
Jan Knepper wrote:

 You cannot have Walter do everything, he cannot clone himself. And 
 even if he could the clone would probably only be of help in 40 years 
 or so. :) And that clone would definately refuse digging in GCC. :)

Well, I could not blame him since the DM backend seems to be very good...

I don't blame him. I like the back end. And most especially i like the C++ compiler. :) But however you put it, it is not really portable beyond x86. Noone says it should be. I was just referring to the simple fact that the clone would first take time to grow up, and create his own set of tools. :)
 I BARELY HAVE ANY TIME MYSELF!

Same here! However, there is a website www.opend.org and a CVS server cvs.opend.org.

Interesting - i didn't know it had a CVS running.
 Actually... I have not given up on it 

PSSST. Don't tell the Moaner. :) Else he'll try to persue you to work faster. :> You're not working on the compiler, which by itself means that you can't... Which means that noone does it and that it has been given up for now.
 ... and *if* I would not have lost 
 about 100K in my business and would not have been 30K in debt because of 
 it I probably would be working on it at this moment. However, I have to 
 take care of my *life* first and making sure the Digital Mars HTTP, FTP 
 and NEWS servers stay up. We have never been down for longer than 15 
 minutes and have not been down even during the Hurricane.

*life* is an important keyword. That's what keeps us from doing the good stuff. :) I am in my second year of my studies - which i expect to be the hardest one of all. And if i don't keep up well, i shall loose my stipendium and also have a debt. My ultimate plan is to stay working at the university after the studies, so that i don't ever have to do anything with business. :) This perfectly excludes the possibility of loosing large amounts of money.
 And now admit it: as soon as the compiler is there, you, having not 
 worked on it, will not even really use it beyond trying it once or 
 twice! Be ashamed of yourself!!!


 Would not know about that. I personally am strongly a C++ (C) and ASM 
 type of person. D is not for me (yet) although I have written some code 
 with it, but I would like to see D integrated into the IDDE.

I was not referring to you, but to the Moaner. Who would be reading the compiler sources right now if he wanted the compiler. -eye.
Nov 07 2003
prev sibling parent reply resistor mac.com writes:
Wow.  Please calm down.  I have considered helping.  I posted a message a while
back with all the 
information I could find to help on the subject.  I'm afraid that I can't write
it, and won't be able to 
for some time.  I only understand the workings of a compiler on the highest
level.  I could probably 
learn how to do it (in fact probably will in the long run), but that is a matter
of years away.

I am perfectly willing to help someone write it, but that's just it:  I have to
help someone.  I can't 
write it by myself.

I never implied that I expected Walter to do it himself.  I do, however, think
that it's a little sad that 
so little of the D community is interested in extending its reach.  Obviously
Jan and Walter have 
perfectly good reasons for being unable to do it at the moment, as I'm willing
to bet do most of the 
others reading this list.  I am, however, disappointed in the people over in the
normal D list who 
are completely uninterested.  D may be (and I believe it is) one of the best
languages in existance 
today, but unless more of the world gets to see it, it won't ever matter.

Sure, D now runs on Linux.  Certainly it's a step forward, but not a great deal.
It helps those who 
already know D, but it doesn't make it more visible to those who don't.  A GCC
port, however, 
would.

Now, for a complete change of pace, here's some more information for pondering:

Perhaps we don't have to port to GCC.  I did some research and dug up a
BSD-licensed compiler 
known as TenDRA, with is a C and (limited) C++ compiler.  Its focus is on code
correctness, with 
work being done to allow the compiler to export mathematical proofs of code
correctness.  In 
addition, TenDRA uses a well defined intermediary language known as ANDF.
(http://
www.info.uni-karlsruhe.de/~andf/)

Might a port to this compiler work?  ANDF seems to place a lot of weight on
being language neutral 
with respect to high-level languages, and the TenDRA compiler has backends to
several UNIX and 
BSD-based systems.  Linux support is in the works.

Anyways, that's my contribution for the moment.  In less someone shoots me down
in a bit I'm 
going to go poke through the TenDRA source in a bit and see how comprehensible
it is.

Owen Anderson

In article <bodqc1$nsm$1 digitaldaemon.com>, Ilya Minkov says...
PLEASE STOP MOANING!

If everyone who wants a compiler only keeps moaning than we will have 
*no* portable compiler ever!

I'll try to write a simple example back-end, which all it does is dump 
code, possibly in a D-like syntax. Then it could be changed to output 
GCC-specific C or KSI.

CONSIDER HELPING.

You cannot have Walter do everything, he cannot clone himself. And even 
if he could the clone would probably only be of help in 40 years or so. 
:) And that clone would definately refuse digging in GCC. :)

I BARELY HAVE ANY TIME MYSELF!

Noone has been working on a port. Jan started some experimentation and 
investigation, but gave up because noone wanted to help, and he himself 
didn't have enough time for something which noone wants sincerely enough 
to consider helping. And that's how it's going to happen fairly often!

And now admit it: as soon as the compiler is there, you, having not 
worked on it, will not even really use it beyond trying it once or 
twice! Be ashamed of yourself!!!

-eye


resistor mac.com wrote:
 What happened to the guys who were working on the GCC port?  I don't think a
 binary release for 
 other platforms is sufficient.  I really think D could be great, but without a
 backend to GCC it's 
 going to be almost impossible for it to get wide use.  Like I said before, I
 want to run it on my Mac 
 OS X system!
 
 Owen
 


Nov 07 2003
parent reply Ilya Minkov <webmaster midiclub.de.vu> writes:
resistor mac.com wrote:
 Wow.  Please calm down.  I have considered helping.  I posted a
 message a while back with all the information I could find to help on
 the subject.  I'm afraid that I can't write it, and won't be able to
  for some time.  I only understand the workings of a compiler on the
 highest level.  I could probably learn how to do it (in fact probably
 will in the long run), but that is a matter of years away.

Okay okay. :) I'm not really intending to dig in GCC internals and the front-end interface. I shall simply output C as textfile, making use of GCCs extensions as appropriate. This should be the easiest, and shall get us running. An alternative would be to output Ksi as textfile, which will then allow to hack the (presumably simple) Ksi GCC front-end which is used in the Gont project. Would requiere some understanding of GCC though. Ksi was specifically written to make GCCs intermediate language public in an easy to parse and to dump textfile format, and Gont compiler was written which outputs it. But C has a merit by itself - although it parses slowly and would thus waste quite some time when compiling. It would allow to adapt easily to other C compilers on the Earth. Anyway, first step would be to get the machine headers for DMD, adapting them from DLI. This will allow to write a first dumper and we'll know what constructs we have to cope with. Probably most constructs are already reduced to the C level. DMD frontend doesn't maintain separate data types for D and intermediate level constructs, but instead does transformations within the D construct hierarchy. As far as i see we simply get a net of structures which contain complete correspondence to C or D constructs. Which in turn contain everything that we might ever want to know, and even much more. :)
 I am perfectly willing to help someone write it, but that's just it:
 I have to help someone.  I can't write it by myself.

Good. Welcome aboard.
 I never implied that I expected Walter to do it himself.  I do,
 however, think that it's a little sad that so little of the D
 community is interested in extending its reach.  Obviously Jan and
 Walter have perfectly good reasons for being unable to do it at the
 moment, as I'm willing to bet do most of the others reading this
 list.  I am, however, disappointed in the people over in the normal D
 list who are completely uninterested.  D may be (and I believe it is)
 one of the best languages in existance today, but unless more of the
 world gets to see it, it won't ever matter.

It's not about more of the world being able to see it. It's just that its serious use is limited by the Windows platform, as long as we have no cross-platform back-end binding with reliable *debuggers*.
 Sure, D now runs on Linux.  Certainly it's a step forward, but not a
 great deal. It helps those who already know D, but it doesn't make it
 more visible to those who don't.  A GCC port, however, would.

Let's hope.
 Now, for a complete change of pace, here's some more information for
 pondering:
 
 Perhaps we don't have to port to GCC.  I did some research and dug up
 a BSD-licensed compiler known as TenDRA, with is a C and (limited)
 C++ compiler.  Its focus is on code correctness, with work being done
 to allow the compiler to export mathematical proofs of code 
 correctness.  In addition, TenDRA uses a well defined intermediary
 language known as ANDF. (http:// www.info.uni-karlsruhe.de/~andf/)

We all know TenDRA. There are a few problems to it. The free x86 back-end i'm aware of is weak... Well, D could be a catalysator for it to become better, but expect it to take time. Maybe too much time to ever really matter. There was a good comercial x86 back-end though. Besides, the C++ counterpart is fairly weak.
 Might a port to this compiler work?  ANDF seems to place a lot of
 weight on being language neutral with respect to high-level
 languages, and the TenDRA compiler has backends to several UNIX and 
 BSD-based systems.  Linux support is in the works.

The port is certainly possible. But probably not plausible yet. Another interesting project is this: http://llvm.cs.uiuc.edu/ This might be a bit more work, since the langauge is quite low-level, though (or as a consequence) simple. But it doesn't like platform-dependant code.
 Anyways, that's my contribution for the moment.  In less someone
 shoots me down in a bit I'm going to go poke through the TenDRA
 source in a bit and see how comprehensible it is.

Thanks, but there are docs on the bytecode format, so it probably is not very importand how comprehensible the compilers are. What i don't know, what level the bytecode is. Is it fairly C level? Is it possible to branch definitions based upon the platform-specifics? It should be able to do native and C calls as well... If only the C-- project was alive! Striking news: someone who knows GCC internals and has already written a frontend to GCC works at my university! http://www4.in.tum.de/~pizka/ I have taken a fresh look at GCC syntax trees and i must say that i'm not that much afraid of it any longer. It is definately the pain for the GCC people, but seems that not so for the people who generate it... But the dumper comes first. -eye
Nov 08 2003
parent reply resistor mac.com writes:
I like your idea about a C dumper.  Certainly it's suboptimal, but it's a good
start.  Looking at the COBOL documentation of GCC internals, it seems like one
can script the GCC driver program to run a source file through multiple compiler
engines sequentially.  For instance, that's how the C compiler works: first the
file is run through the preprocessor, and then through the compiler.  It seems
to me we could script it something like C Dumper -> C Preprocessor -> C
Compiler, and have a D compiler for GCC that, while slow and definitely not the
best solution, would be transparent (hopefully) to the developer.  Just some
thoughts though.

Owen Anderson

In article <boiutt$229f$1 digitaldaemon.com>, Ilya Minkov says...
resistor mac.com wrote:
 Wow.  Please calm down.  I have considered helping.  I posted a
 message a while back with all the information I could find to help on
 the subject.  I'm afraid that I can't write it, and won't be able to
  for some time.  I only understand the workings of a compiler on the
 highest level.  I could probably learn how to do it (in fact probably
 will in the long run), but that is a matter of years away.

Okay okay. :) I'm not really intending to dig in GCC internals and the front-end interface. I shall simply output C as textfile, making use of GCCs extensions as appropriate. This should be the easiest, and shall get us running. An alternative would be to output Ksi as textfile, which will then allow to hack the (presumably simple) Ksi GCC front-end which is used in the Gont project. Would requiere some understanding of GCC though. Ksi was specifically written to make GCCs intermediate language public in an easy to parse and to dump textfile format, and Gont compiler was written which outputs it. But C has a merit by itself - although it parses slowly and would thus waste quite some time when compiling. It would allow to adapt easily to other C compilers on the Earth. Anyway, first step would be to get the machine headers for DMD, adapting them from DLI. This will allow to write a first dumper and we'll know what constructs we have to cope with. Probably most constructs are already reduced to the C level. DMD frontend doesn't maintain separate data types for D and intermediate level constructs, but instead does transformations within the D construct hierarchy. As far as i see we simply get a net of structures which contain complete correspondence to C or D constructs. Which in turn contain everything that we might ever want to know, and even much more. :)
 I am perfectly willing to help someone write it, but that's just it:
 I have to help someone.  I can't write it by myself.

Good. Welcome aboard.
 I never implied that I expected Walter to do it himself.  I do,
 however, think that it's a little sad that so little of the D
 community is interested in extending its reach.  Obviously Jan and
 Walter have perfectly good reasons for being unable to do it at the
 moment, as I'm willing to bet do most of the others reading this
 list.  I am, however, disappointed in the people over in the normal D
 list who are completely uninterested.  D may be (and I believe it is)
 one of the best languages in existance today, but unless more of the
 world gets to see it, it won't ever matter.

It's not about more of the world being able to see it. It's just that its serious use is limited by the Windows platform, as long as we have no cross-platform back-end binding with reliable *debuggers*.
 Sure, D now runs on Linux.  Certainly it's a step forward, but not a
 great deal. It helps those who already know D, but it doesn't make it
 more visible to those who don't.  A GCC port, however, would.

Let's hope.
 Now, for a complete change of pace, here's some more information for
 pondering:
 
 Perhaps we don't have to port to GCC.  I did some research and dug up
 a BSD-licensed compiler known as TenDRA, with is a C and (limited)
 C++ compiler.  Its focus is on code correctness, with work being done
 to allow the compiler to export mathematical proofs of code 
 correctness.  In addition, TenDRA uses a well defined intermediary
 language known as ANDF. (http:// www.info.uni-karlsruhe.de/~andf/)

We all know TenDRA. There are a few problems to it. The free x86 back-end i'm aware of is weak... Well, D could be a catalysator for it to become better, but expect it to take time. Maybe too much time to ever really matter. There was a good comercial x86 back-end though. Besides, the C++ counterpart is fairly weak.
 Might a port to this compiler work?  ANDF seems to place a lot of
 weight on being language neutral with respect to high-level
 languages, and the TenDRA compiler has backends to several UNIX and 
 BSD-based systems.  Linux support is in the works.

The port is certainly possible. But probably not plausible yet. Another interesting project is this: http://llvm.cs.uiuc.edu/ This might be a bit more work, since the langauge is quite low-level, though (or as a consequence) simple. But it doesn't like platform-dependant code.
 Anyways, that's my contribution for the moment.  In less someone
 shoots me down in a bit I'm going to go poke through the TenDRA
 source in a bit and see how comprehensible it is.

Thanks, but there are docs on the bytecode format, so it probably is not very importand how comprehensible the compilers are. What i don't know, what level the bytecode is. Is it fairly C level? Is it possible to branch definitions based upon the platform-specifics? It should be able to do native and C calls as well... If only the C-- project was alive! Striking news: someone who knows GCC internals and has already written a frontend to GCC works at my university! http://www4.in.tum.de/~pizka/ I have taken a fresh look at GCC syntax trees and i must say that i'm not that much afraid of it any longer. It is definately the pain for the GCC people, but seems that not so for the people who generate it... But the dumper comes first. -eye

Nov 08 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
resistor mac.com wrote:
 I like your idea about a C dumper.  Certainly it's suboptimal, but it's a good
 start.  Looking at the COBOL documentation of GCC internals, it seems like one
 can script the GCC driver program to run a source file through multiple
compiler
 engines sequentially.  For instance, that's how the C compiler works: first the
 file is run through the preprocessor, and then through the compiler.  It seems
 to me we could script it something like C Dumper -> C Preprocessor -> C
 Compiler, and have a D compiler for GCC that, while slow and definitely not the
 best solution, would be transparent (hopefully) to the developer.  Just some
 thoughts though.

Nothing is ever going to be optimal when dealing with GCC - apart from the generated code. :) GCC is simply bloody slow. :) But, as one cared to say a while ago: "Soon, the computers are going to be FAST!". :) So i wouldn't care much about it. That is, if it works: we may still run over problems. Dumping C is simply the easiest thing to do now. I guess we have figured out how to do exception handling with extensions, and how to translate inner functions into valid C. It is not true that GCC preprocessor is a separate program. Due to efforts of Apple and other companies, the current GCC preprocessor is built into the front-end compilers, and readily serves separate tokens instead of a stream of text to the parser. We can actually omit the preprocessor step, since we don't have to deal with header files. All declarations we need are taken from d imports. However, i doubt it will make it any faster with GCC 3.x, since the pre-processor does the tokenisation anyway. Steve Maillet mentions that there is a new front-end binding, GIMPLE, on GCC 3. However, i have not been able to find anything about it. I assume that established front-ends, like gpp. gnat, and gpc still use the same bindings as in good old 2.95, and that current bindinngs are kept intact. However, i don't like the idea of talking directly to the compiler for the reasons of debugging. I wonder whether there is something like a shim "back-end", which would all it do is dump the abstract tree? This would by the way help look at the workings of other frontends... -eye
Nov 09 2003
parent resistor mac.com writes:
I found a little bit of information about GIMPLE, and it won't be of much use to
us.  It does not change the way frontends work, and won't be merged and official
until 3.5.  What it is is another step between syntax trees and RTL.  Trees are
converted into a language called GENERIC which is specially designed for
high-level optimization.  The GENERIC is then pruned to a simpler subset called
GIMPLE to make identification of repetitive sequences easier.  Finally the fully
optimized GIMPLE is converted into RTL and the process continues as normal.

As far as I can tell the only real problem in this process is understanding how
GCC constructs its trees.  Once the trees are properly constructed it seems to
be a reasonably straightforward process to convert them into RTL.


Owen Anderson

In article <bomf43$16tr$1 digitaldaemon.com>, Ilya Minkov says...
resistor mac.com wrote:
 I like your idea about a C dumper.  Certainly it's suboptimal, but it's a good
 start.  Looking at the COBOL documentation of GCC internals, it seems like one
 can script the GCC driver program to run a source file through multiple
compiler
 engines sequentially.  For instance, that's how the C compiler works: first the
 file is run through the preprocessor, and then through the compiler.  It seems
 to me we could script it something like C Dumper -> C Preprocessor -> C
 Compiler, and have a D compiler for GCC that, while slow and definitely not the
 best solution, would be transparent (hopefully) to the developer.  Just some
 thoughts though.

Nothing is ever going to be optimal when dealing with GCC - apart from the generated code. :) GCC is simply bloody slow. :) But, as one cared to say a while ago: "Soon, the computers are going to be FAST!". :) So i wouldn't care much about it. That is, if it works: we may still run over problems. Dumping C is simply the easiest thing to do now. I guess we have figured out how to do exception handling with extensions, and how to translate inner functions into valid C. It is not true that GCC preprocessor is a separate program. Due to efforts of Apple and other companies, the current GCC preprocessor is built into the front-end compilers, and readily serves separate tokens instead of a stream of text to the parser. We can actually omit the preprocessor step, since we don't have to deal with header files. All declarations we need are taken from d imports. However, i doubt it will make it any faster with GCC 3.x, since the pre-processor does the tokenisation anyway. Steve Maillet mentions that there is a new front-end binding, GIMPLE, on GCC 3. However, i have not been able to find anything about it. I assume that established front-ends, like gpp. gnat, and gpc still use the same bindings as in good old 2.95, and that current bindinngs are kept intact. However, i don't like the idea of talking directly to the compiler for the reasons of debugging. I wonder whether there is something like a shim "back-end", which would all it do is dump the abstract tree? This would by the way help look at the workings of other frontends... -eye

Nov 10 2003