Am ready to be fired at, so take your best shots.

My question is, has anyone seriously considered the notion of DMD producing C-code. A kind of D-front if you like.

Now I realise straight up that DMD can probably produce code straight to binary that will likely be faster than a compiled intermediate C-form in a non-trivial number of cases. So I'm not proposing that compile to machine code be abandoned.

However, since there is currently a single compiler/linker that is usable with DMD, the bottleneck could be alleviated by allowing any C compiler to provide the back-end, and this could also help with porting to other platforms (not just Linux, but Mac, VAX, Solaris, etc. etc.). It would also allow debugging within one's accustomed compiler/environment, though of course this would be C debugging not D. (However, since a lot of the bugs being reported are in the generated code, this may not be a bad thing.)

Now I know the answer's going to be "LOTS", but how much work would it be to give the compiler this extra mode, perhaps with a -ic (intermediate C)? Does anyone think the benefits significant and, if so, worth the effort in Walter doing so.

Matthew

There is currently ongoing work to get a D frontend for gcc for exactly this reason.  I don't know the status, but things seem very quiet over there - perhaps the work is stalled?

Matthew Wilson wrote:
> Am ready to be fired at, so take your best shots.
> 
> My question is, has anyone seriously considered the notion of DMD producing
> C-code. A kind of D-front if you like.
> 
> Now I realise straight up that DMD can probably produce code straight to
> binary that will likely be faster than a compiled intermediate C-form in a
> non-trivial number of cases. So I'm not proposing that compile to machine
> code be abandoned.
> 
> However, since there is currently a single compiler/linker that is usable
> with DMD, the bottleneck could be alleviated by allowing any C compiler to
> provide the back-end, and this could also help with porting to other
> platforms (not just Linux, but Mac, VAX, Solaris, etc. etc.). It would also
> allow debugging within one's accustomed compiler/environment, though of
> course this would be C debugging not D. (However, since a lot of the bugs
> being reported are in the generated code, this may not be a bad thing.)
> 
> Now I know the answer's going to be "LOTS", but how much work would it be to
> give the compiler this extra mode, perhaps with a -ic (intermediate C)? Does
> anyone think the benefits significant and, if so, worth the effort in Walter
> doing so.
> 
> Matthew
> 
> 

I've thought many times about doing just that. But I think it's a lot more
work to generate C than it would be to integrate with gcc. There are also
some things that won't work - such as converting
the inline assembler to C! -Walter

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bfnnvo$305l$1@digitaldaemon.com...
> Am ready to be fired at, so take your best shots.
>
> My question is, has anyone seriously considered the notion of DMD
producing
> C-code. A kind of D-front if you like.
>
> Now I realise straight up that DMD can probably produce code straight to binary that will likely be faster than a compiled intermediate C-form in a non-trivial number of cases. So I'm not proposing that compile to machine code be abandoned.
>
> However, since there is currently a single compiler/linker that is usable with DMD, the bottleneck could be alleviated by allowing any C compiler to provide the back-end, and this could also help with porting to other platforms (not just Linux, but Mac, VAX, Solaris, etc. etc.). It would
also
> allow debugging within one's accustomed compiler/environment, though of course this would be C debugging not D. (However, since a lot of the bugs being reported are in the generated code, this may not be a bad thing.)
>
> Now I know the answer's going to be "LOTS", but how much work would it be
to
> give the compiler this extra mode, perhaps with a -ic (intermediate C)?
Does
> anyone think the benefits significant and, if so, worth the effort in
Walter
> doing so.
>
> Matthew
>
>

I'd be more than happy to accept a version that didn't work with inline assembler

"Walter" <walter@digitalmars.com> wrote in message news:bfnuu7$4cp$1@digitaldaemon.com...
> I've thought many times about doing just that. But I think it's a lot more
> work to generate C than it would be to integrate with gcc. There are also
> some things that won't work - such as converting
> the inline assembler to C! -Walter
>
> "Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bfnnvo$305l$1@digitaldaemon.com...
> > Am ready to be fired at, so take your best shots.
> >
> > My question is, has anyone seriously considered the notion of DMD
> producing
> > C-code. A kind of D-front if you like.
> >
> > Now I realise straight up that DMD can probably produce code straight to binary that will likely be faster than a compiled intermediate C-form in
a
> > non-trivial number of cases. So I'm not proposing that compile to
machine
> > code be abandoned.
> >
> > However, since there is currently a single compiler/linker that is
usable
> > with DMD, the bottleneck could be alleviated by allowing any C compiler
to
> > provide the back-end, and this could also help with porting to other platforms (not just Linux, but Mac, VAX, Solaris, etc. etc.). It would
> also
> > allow debugging within one's accustomed compiler/environment, though of course this would be C debugging not D. (However, since a lot of the
bugs
> > being reported are in the generated code, this may not be a bad thing.)
> >
> > Now I know the answer's going to be "LOTS", but how much work would it
be
> to
> > give the compiler this extra mode, perhaps with a -ic (intermediate C)?
> Does
> > anyone think the benefits significant and, if so, worth the effort in
> Walter
> > doing so.
> >
> > Matthew
> >
> >
>
>
>

Walter wrote:
> I've thought many times about doing just that. But I think it's a lot more
> work to generate C than it would be to integrate with gcc. There are also
> some things that won't work - such as converting
> the inline assembler to C! -Walter

You can't say "it won't work"!!! It may, just not portably. No sense sticking to ANSI C where it doesn't yuild what you need.

There would be a need to:
 * accomodate for compiler-dependant extended sytaxes, e.g. SEH with most Win32 compilers and Java-like exception handling with GCC. Preferable solution - INI-file. Or even simply an #include of a file #defining a number of macros which would sort these things away. The problem of the #include approach is with the mulri-line macros in the case one has to #define something in them, and the lack of flexibility.
 * accomodate for different inline assembly notations. Like, converter to AT&T-style assembly and somesuch. Maybe through plug-in scripts? May also be in the main code.

Besides, i believe there are quite a few people who know C and may want to help with that :) , while GCC internals are not something one wants to mess with. And another point: GCC is so slow, that going through C would be faster on most systems, where other compilers exist.

-i.

"Ilya Minkov" <midiclub@8ung.at> wrote in message news:bfon1k$q2o$1@digitaldaemon.com...
> Besides, i believe there are quite a few people who know C and may want to help with that :) , while GCC internals are not something one wants to mess with.

I'm such a person. I have always believed that it was the way to go - for several reasons:

- It does not require expertice with GCC.

- Dependence of GCC could make the compiler break if GCC changes. dfront would probably be a relative small free standing project.

- dfront could be ported to platforms where GCC is not available. Cross-compilation (generation of C files, that is) could easily be done.

- dfront could be implemented in D using DMD for its initial development. It would be fun to do, and also be a great proof-of-concept for D.


Regards,
Martin M. Pedersen

All the C compilers I know of have an inline assembler.  ;)

Just pass asm blocks straight thru to the C code and let the programmer deal with them.

Sean

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bfo0bm$69k$1@digitaldaemon.com...
> I'd be more than happy to accept a version that didn't work with inline assembler
>
> "Walter" <walter@digitalmars.com> wrote in message news:bfnuu7$4cp$1@digitaldaemon.com...
> > I've thought many times about doing just that. But I think it's a lot
more
> > work to generate C than it would be to integrate with gcc. There are
also
> > some things that won't work - such as converting
> > the inline assembler to C! -Walter

"Martin M. Pedersen" <martin@moeller-pedersen.dk> wrote in message news:bforpc$upb$1@digitaldaemon.com...
> "Ilya Minkov" <midiclub@8ung.at> wrote in message news:bfon1k$q2o$1@digitaldaemon.com...
> > Besides, i believe there are quite a few people who know C and may want to help with that :) , while GCC internals are not something one wants to mess with.
>
> I'm such a person. I have always believed that it was the way to go - for several reasons:
>
> - It does not require expertice with GCC.
>
> - Dependence of GCC could make the compiler break if GCC changes. dfront would probably be a relative small free standing project.
>
> - dfront could be ported to platforms where GCC is not available. Cross-compilation (generation of C files, that is) could easily be done.
>
> - dfront could be implemented in D using DMD for its initial development.
It
> would be fun to do, and also be a great proof-of-concept for D.

If someone wants to start up a dfront project, I'll help with advice and ideas.

In article <bfpfga$1hi2$1@digitaldaemon.com>, Walter says... [...]
>
>If someone wants to start up a dfront project, I'll help with advice and ideas.

I have some questions, before asking myself whether I'll have enough time to do it or not:

- does the D frontend build a syntax tree?
- are the currently distributed sources complete enough to do a dfront project?
- what are, in your opinion, the main obstacles one can find in trying to
generate a c source from a D source? I guess there's not only the inline
assembler.

Thanks in advace.

Ciao.

Since the objective is not raw performance, C++ might be a better target than C.  While probably not quite as wide-spread on a multitude of platforms, D->C++ is probably going to result in nicer generated code than D->C; hence easier debugging.  Targeting C++ would also make it easier to do D.NET since you would "just" generate Managed C++.

   Dan

"Matthew Wilson" <matthew@stlsoft.org> wrote in message news:bfnnvo$305l$1@digitaldaemon.com...
> Am ready to be fired at, so take your best shots.
>
> My question is, has anyone seriously considered the notion of DMD
producing
> C-code. A kind of D-front if you like.
>
> Now I realise straight up that DMD can probably produce code straight to binary that will likely be faster than a compiled intermediate C-form in a non-trivial number of cases. So I'm not proposing that compile to machine code be abandoned.
>
> However, since there is currently a single compiler/linker that is usable with DMD, the bottleneck could be alleviated by allowing any C compiler to provide the back-end, and this could also help with porting to other platforms (not just Linux, but Mac, VAX, Solaris, etc. etc.). It would
also
> allow debugging within one's accustomed compiler/environment, though of course this would be C debugging not D. (However, since a lot of the bugs being reported are in the generated code, this may not be a bad thing.)
>
> Now I know the answer's going to be "LOTS", but how much work would it be
to
> give the compiler this extra mode, perhaps with a -ic (intermediate C)?
Does
> anyone think the benefits significant and, if so, worth the effort in
Walter
> doing so.
>
> Matthew
>
>