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

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
> 

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

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.

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
>> 
>

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

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
>

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

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
>