www.digitalmars.com         C & C++   DMDScript  

D.gnu - Alive?

reply "Dana Anderson" <resistor mac.com> writes:
Is this project still alive?  Nothing seems to have happened in an awfully
long time, but I'd still love to see D for other platforms some day!

Dana

--
Dana M. Anderson
Athens, GA
Oct 25 2003
next sibling parent Jan Knepper <jan smartsoft.us> writes:
Well, it definitely is not dead, but Walter has created a D for Linux 
himself and D for BSD-Unix is in progress...

Thanks!
Jan



Dana Anderson wrote:

 Is this project still alive?  Nothing seems to have happened in an awfully
 long time, but I'd still love to see D for other platforms some day!
 
 Dana
 
 --
 Dana M. Anderson
 Athens, GA
 
 


-- 
ManiaC++
Jan Knepper
Oct 25 2003
prev sibling next sibling parent Ilya Minkov <minkov cs.tum.edu> writes:
I'm currently reading the compiler source and shall possibly write a doc 
on binding back-ends to D. Maybe it shall be of use to someone with GCC 
knowledge.

-eye

Dana Anderson wrote:

 Is this project still alive?  Nothing seems to have happened in an awfully
 long time, but I'd still love to see D for other platforms some day!
 
 Dana
 
 --
 Dana M. Anderson
 Athens, GA
Oct 26 2003
prev sibling next sibling parent 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
prev sibling parent "Steve Maillet" <nospam1 EntelechyConsulting.com> writes:
Aside from the comments of others here. The major problem I see is a rather
significant shift within GCC on the backend. GIMPLE is a new twist to the
gcc backend that isn't particularly well documented outside of the core GCC
developers who are pretty tightly focused on the languages GCC already
supports. So the task of sticking Walter's open front end on to the GCC back
end is a fairly huge and daunting task with lot's and lot's of pitfalls
waiting, (heck I'd even say a few chasms are hidden under thin layers there)

Another problem is that at this point D is effectively a proprietary
language and all the major industry focus is on Java and .NET, native
languages are "un-cool" at the moment. It's a new language with new ways of
doing things and thinking about systems. Changes don't come quickly to this
industry despite appearances to the contrary. (We STILL have mission
critical FORTRAN and BASIC apps in existence in the world!) So really D is
not much more then a curiosity at best for most developers so while they
might try it out there is no real industry drive to use it. Heck there are a
lot of developer's terrified of this new fangled C++ cuz it makes their
brain hurt!  ("What do you mean I'm not supposed to use 'goto' for all my
code branches!?")

Yes, it would be absolutely fabulous to have D for non x86 platforms
especially for embedded devices With controlled garbage collection and the
benefits of native code compilation combined with the ability to step
outside the garbage collected world to raw memory allocations D is a
fantastic language for use in real-time embedded devices. I've recently
embarked on getting the x86 version of it integrated into Visual Studio.NET
for use with Windows CE x86 based devices at least and am hoping somebody
can get the GCC going for use on other CPUs. Maybe someday my company will
have the resources to fund that effort but it certainly doesn't have it at
this point in time.

-- 
Steve Maillet (eMVP)
Entelechy Consulting
smaillet_AT_EntelechyConsulting_DOT_com
Nov 07 2003