www.digitalmars.com         C & C++   DMDScript  

D - GCC frontend planned?

reply Jakob Kemi <jakob.kemi telia.com> writes:
Is there any plans or work going on with a GCC frontend.
This way D would reach a bunch of platforms (even java bytecode)
and get some of the GCC developers invested work for free.

Thoughts?

	Jakob Kemi
Mar 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
The plan is to produce a "dfront" which will emit C code. Dfront will be
open source, but will not be GPL. This will enable D on any platform with a
decent C compiler, without all the issues that come with GPL.

Dfront will be the pioneer, like cfront was for C++. I hope that native
implementations from a variety of sources, including a GPL one, will follow.

-Walter


"Jakob Kemi" <jakob.kemi telia.com> wrote in message
news:a6j78d$1lnm$1 digitaldaemon.com...
 Is there any plans or work going on with a GCC frontend.
 This way D would reach a bunch of platforms (even java bytecode)
 and get some of the GCC developers invested work for free.

 Thoughts?

 Jakob Kemi

Mar 11 2002
next sibling parent reply Jakob Kemi <jakob.kemi telia.com> writes:
On Tue, 12 Mar 2002 00:39:11 +0100, Walter wrote:

 The plan is to produce a "dfront" which will emit C code. Dfront will be
 open source, but will not be GPL. This will enable D on any platform
 with a decent C compiler, without all the issues that come with GPL.
 
 Dfront will be the pioneer, like cfront was for C++. I hope that native
 implementations from a variety of sources, including a GPL one, will
 follow.
 
 -Walter

I'm sorry if this question has been asked already, since I'm new to the list. How come you want an GPL version but you'll release your version under some other "open source" license ? Why not release it directly under GPL ? Or perhaps under a dual license? Jakob
 
 "Jakob Kemi" <jakob.kemi telia.com> wrote in message
 news:a6j78d$1lnm$1 digitaldaemon.com...
 Is there any plans or work going on with a GCC frontend. This way D
 would reach a bunch of platforms (even java bytecode) and get some of
 the GCC developers invested work for free.

 Thoughts?

 Jakob Kemi


Mar 11 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Jakob Kemi" <jakob.kemi telia.com> wrote in message
news:a6jj2h$10v$1 digitaldaemon.com...
 I'm sorry if this question has been asked already, since I'm new to
 the list. How come you want an GPL version but you'll release your
 version under some other "open source" license ?
 Why not release it directly under GPL ?
 Or perhaps under a dual license?

 Jakob

Likely do a fork & dual license.
Mar 11 2002
parent reply andy <acoliver nc.rr.com> writes:
I'm disinterested in license issues, but would rather not use a GPL
version (oddly because I'm NOT interested in license issues).  I think D
is a compelling project, but the lack of source avaiable for even the
win32 version kind of scares me out of investing too much time into D as
an opensource developer and contributer.  I'd be interested in trying to
spawn a project to create a D compiler and possibly a runtime
environment.  

Can you give me a bit more on the rationale to not release sources and
involve other developers in the project?

-Andy
Mar 17 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"andy" <acoliver nc.rr.com> wrote in message
news:a72ncr$8ag$1 digitaldaemon.com...

 I'm disinterested in license issues, but would rather not use a GPL
 version (oddly because I'm NOT interested in license issues).  I think D
 is a compelling project, but the lack of source avaiable for even the
 win32 version kind of scares me out of investing too much time into D as
 an opensource developer and contributer.  I'd be interested in trying to
 spawn a project to create a D compiler and possibly a runtime
 environment.

Walter says the sources will be available eventually... and Dfront is definitely going to be open-sourced, so I wouldn't worry if I were you. Anyhow, what's the problem with contribution? You get the compiler, the docs, and complete source to the entire RTL, including the garbage collector, for free - so what stops you from writing your own modules, which might hopefully end being part of Phobos... =)
Mar 17 2002
parent reply andy <acoliver nc.rr.com> writes:
On Sun, 17 Mar 2002 14:14:39 -0500, Pavel Minayev wrote:


 "andy" <acoliver nc.rr.com> wrote in message
 news:a72ncr$8ag$1 digitaldaemon.com...
 
 I'm disinterested in license issues, but would rather not use a GPL
 version (oddly because I'm NOT interested in license issues).  I think
 D is a compelling project, but the lack of source avaiable for even the
 win32 version kind of scares me out of investing too much time into D
 as an opensource developer and contributer.  I'd be interested in
 trying to spawn a project to create a D compiler and possibly a runtime
 environment.

Walter says the sources will be available eventually... and Dfront is definitely going to be open-sourced, so I wouldn't worry if I were you. Anyhow, what's the problem with contribution? You get the compiler, the docs, and complete source to the entire RTL, including the garbage collector, for free - so what stops you from writing your own modules, which might hopefully end being part of Phobos... =)

Well for starters, I don't have windows. (I don't like crashing my system and I mostly do server side non-gui programming anyhow so I need a secure stable system. Barely need a GUI.) Yeah its the "eventually" that concerns me. Its a "check in the mail" kind of thing. Personally, I think the success or failure of D may be based on when/if the sources are released. Would anyone object to the creation of a seperate project for creating a free compiler for D? Thanks, Andy
Mar 17 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"andy" <acoliver nc.rr.com> wrote in message
news:a72srh$c4l$1 digitaldaemon.com...

 Well for starters, I don't have windows.  (I don't like crashing my
 system and I mostly do server side non-gui programming anyhow so I need a
 secure stable system.  Barely need a GUI.)

Still, most people use Windows, so I guess making a compiler for Win32 is the right way.
 Yeah its the "eventually" that concerns me.  Its a "check in the mail"
 kind of thing.  Personally, I think the success or failure of D may be

 on when/if the sources are released.  Would anyone object to the creation

 a seperate project for creating a free compiler for D?

Don't you want to wait till Dfront is released? I guess it will be just what you want... and then, if it isn't, a separate project could be started. Besides, the language is just too immature to separate implementations. Otherwise, we might end up with two hardly compatible compilers.
Mar 17 2002
parent andy <acoliver nc.rr.com> writes:
On Sun, 17 Mar 2002 16:36:13 -0500, Pavel Minayev wrote:

 "andy" <acoliver nc.rr.com> wrote in message
 news:a72srh$c4l$1 digitaldaemon.com...
 
 Well for starters, I don't have windows.  (I don't like crashing my
 system and I mostly do server side non-gui programming anyhow so I need
 a secure stable system.  Barely need a GUI.)

Still, most people use Windows, so I guess making a compiler for Win32 is the right way.

Not for heavy lifting. It would have been better to start with a plugin for GCC or something of the such because it would have been available cross platform from the start. I'm also fairly certain this could have been done around the GPL or so (as so far as I know C/C++ have not become "infected" by the GPL :-) by seperating things out properly.
 Yeah its the "eventually" that concerns me.  Its a "check in the mail"
 kind of thing.  Personally, I think the success or failure of D may be

 on when/if the sources are released.  Would anyone object to the
 creation

 a seperate project for creating a free compiler for D?

Don't you want to wait till Dfront is released? I guess it will be just what you want... and then, if it isn't, a separate project could be started.

Dfront doesn't excite me very much to be honest.
 Besides, the language is just too immature to separate implementations.
 Otherwise, we might end up with two hardly compatible compilers.

Agreed, I just can't see how this is going to work if boom one day there is a big 'D' from a little company. You need either big muscle (IBM/MS/SUN/etc) backing 'D' or an opensource movement. You've got the necessary codebase for a community of developers around it, why open it up now and let other developers help out? In my view its the only way the thing will take at all. -Andy
Mar 17 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"andy" <acoliver nc.rr.com> wrote in message
news:a72srh$c4l$1 digitaldaemon.com...
 Would anyone object to the creation of
 a seperate project for creating a free compiler for D?

Not me, in fact, I welcome it. D is designed to be easy to implement for just that reason <g>.
Mar 17 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"andy" <acoliver nc.rr.com> wrote in message
news:a72ncr$8ag$1 digitaldaemon.com...
 I'm disinterested in license issues, but would rather not use a GPL
 version (oddly because I'm NOT interested in license issues).  I think D
 is a compelling project, but the lack of source avaiable for even the
 win32 version kind of scares me out of investing too much time into D as
 an opensource developer and contributer.  I'd be interested in trying to
 spawn a project to create a D compiler and possibly a runtime
 environment.
 Can you give me a bit more on the rationale to not release sources and
 involve other developers in the project?

The only reason I haven't done an open source version yet is because I felt it was so early in the project it would fork into fundamentally incompatible versions. I understand that at some point D needs to go open source to be successful. Hooking it up to the GCC code generator would make it GPL'd, which I am uncomfortable with. Thus, the idea of a "dfront" which outputs C code. This would make D available on any platform with a C compiler. What do you think?
Mar 17 2002
parent reply "Immanuel Scholz" <digital-mars kutzsche.net> writes:
 I understand that at some point D needs to go open source to be

 Hooking it up to the GCC code generator would make it GPL'd, which I am
 uncomfortable with. Thus, the idea of a "dfront" which outputs C code.

 would make D available on any platform with a C compiler.

Huh! For me, I thought "DFront" is some kind of IDE... I am impressed! You can output portable C Code from a language which seems not portable in some things, as example inline assemble or fixed size of variables. Imi
Mar 17 2002
parent reply Russell Borogove <kaleja estarcion.com> writes:
Immanuel Scholz wrote:
[Walter wrote:]
Hooking it up to the GCC code generator would make it GPL'd, which I am
uncomfortable with. Thus, the idea of a "dfront" which outputs C code.
This would make D available on any platform with a C compiler.

[snip] I am impressed! You can output portable C Code from a language which seems not portable in some things, as example inline assemble or fixed size of variables.

If you mean the bit widths of integers, that's pretty easy to make portable via a set of typedefs per targeted C compiler (i.e. the typedefs aren't portable, but everything else is). As for inline assembler, portability really can't be reasonably achieved at the semantic level, but it could be attempted syntactically: Dfront could pass the assembly code through unchanged, making sure that the syntax was appropriate for, e.g. gcc's inline assembler. With Dfront open-sourced, it should be a small matter to tweak the syntax of the inline assembler throughput in order to work with other compilers which support inline assembly. -RB
Mar 17 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C954B8D.4010102 estarcion.com...

 As for inline assembler, portability really can't be
 reasonably achieved at the semantic level, but it could
 be attempted syntactically: Dfront could pass the
 assembly code through unchanged, making sure that the
 syntax was appropriate for, e.g. gcc's inline assembler.

This is not an option. Don't forget that D states that, for a single architecture, inline assembler syntax must be uniform for all the compilers (so you may easily write a program with inline assembler on Windows, and then compile it on Linux, for example). This syntax for x86 is quite different from the GAS one, so it'd require a converter. Another alternative is to remove asm blocks from Dfront at all. D specification encourages, but does not require implementations to support inline assembler, so this could be a case. I believe Walter had chosen this way.
Mar 17 2002
next sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
Pavel Minayev wrote:
 This is not an option. Don't forget that D states that, for a single
 architecture,
 inline assembler syntax must be uniform for all the compilers (so you may
 easily
 write a program with inline assembler on Windows, and then compile it on
 Linux,
 for example). This syntax for x86 is quite different from the GAS one, so
 it'd
 require a converter.

OK, that's somewhat unfortunate. I'd almost suggest some sort of hack where Dfront could translate inline asm to a #include statement, optionally generating a file to include which contains the original inline asm as a comment, followed by a #error Implement Me So that someone Dfronting D code knows they need to port the inline asm. -RB
Mar 18 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Russell Borogove" <kaleja estarcion.com> wrote in message
news:3C9624DF.1040900 estarcion.com...

 OK, that's somewhat unfortunate. I'd almost suggest
 some sort of hack where Dfront could translate inline
 asm to a #include statement, optionally generating a
 file to include which contains the original inline asm
 as a comment, followed by a

   #error Implement Me

 So that someone Dfronting D code knows they need to
 port the inline asm.

I think a simple "inline assembler not supported" error message would be enough to understand that. =)
Mar 18 2002
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:a7428a$131v$1 digitaldaemon.com...
 This is not an option. Don't forget that D states that, for a single
 architecture,
 inline assembler syntax must be uniform for all the compilers (so you may
 easily
 write a program with inline assembler on Windows, and then compile it on
 Linux,
 for example). This syntax for x86 is quite different from the GAS one, so
 it'd
 require a converter.

This bit in D is caused by my experience with the gratuitous incompatibilities in the inline assembler between MSC and BCC (Digital Mars C supports both syntaxes). But the worst is GCC, which reverses all the operands. Trying to do inline asm in GCC just gives me siezures, like that old experiment where a researcher wore special glasses that turned everything upsided down. After a couple weeks wearing them, suddenly his brain turned it right side up. Of course, after ending the experiment, he took the glasses off and now everything was upside down. The film on it ended with a warning not to try the experiment yourself <g>.
Mar 19 2002
prev sibling parent reply Chris <none none.invalid> writes:
Although useful to kickstart the language, the idea of another cfront 
seems wrong and could give D an undeserved bad rap.  I don't know if 
anyone else here remembers but cfront produced incredibly slow code.  In 
fact, any language that tries to sit on top of C tends to be very slow 
compared to native C.  I have never seen any language use C as an 
intermediate language and produce quick code (and I've looked at a lot 
of languages) which leads me to believe that it can't be done.

It seems like the time would be better used by hooking D up to the GCC 
backend.  I don't think this would take any longer than creating dfront 
and would certainly not be wasting any time.

--
// Chris



Walter wrote:
 The plan is to produce a "dfront" which will emit C code. Dfront will be
 open source, but will not be GPL. This will enable D on any platform with a
 decent C compiler, without all the issues that come with GPL.
 
 Dfront will be the pioneer, like cfront was for C++. I hope that native
 implementations from a variety of sources, including a GPL one, will follow.

Mar 18 2002
parent "Walter" <walter digitalmars.com> writes:
"Chris" <none none.invalid> wrote in message
news:3C96B1B8.6090105 none.invalid...
 Although useful to kickstart the language, the idea of another cfront
 seems wrong and could give D an undeserved bad rap.  I don't know if
 anyone else here remembers but cfront produced incredibly slow code.  In
 fact, any language that tries to sit on top of C tends to be very slow
 compared to native C.  I have never seen any language use C as an
 intermediate language and produce quick code (and I've looked at a lot
 of languages) which leads me to believe that it can't be done.

 It seems like the time would be better used by hooking D up to the GCC
 backend.  I don't think this would take any longer than creating dfront
 and would certainly not be wasting any time.

You raise good points. I remember the cfront days well. One of the main advantages of cfront was that companies wanting to commit to C++ were assured that C++, via cfront, was available everywhere. So even if they didn't actually use it, the fact it existed helped the language gain acceptability. Greg Comeau seems to have a successful business selling a C++ to C translator (Comeau C++ even supports Digital Mars C as a back end!).
Mar 19 2002