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


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?


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


 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?


 
 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


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.


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