Olaf Rogalsky says...
>
>Well, I don't like the idea of C beeing the backends language very much.
>Its too frustrating to see the translation process
>D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
>But on the other hand, one could make use of the wide availibilty of
>C to get a portable D compiler.
>

It's not exactly an ideal way to generate an app but it's the best way for one to get a compiler for a language on as many platform as possible. After you get it on lots of platform and people using it, then one can start thinking about native compiler on the different platform....

KTC

KTC wrote:
> Olaf Rogalsky says...
> 
>>Well, I don't like the idea of C beeing the backends language very much.
>>Its too frustrating to see the translation process
>>D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
>>But on the other hand, one could make use of the wide availibilty of
>>C to get a portable D compiler.
>>
> It's not exactly an ideal way to generate an app but it's the best way for one
> to get a compiler for a language on as many platform as possible. After you get
> it on lots of platform and people using it, then one can start thinking about
> native compiler on the different platform....
> KTC
> 
I remember that Algol60 had a "bootstrap compiler" which implemented Algol in a subset of itself, so to port it only the subset of the language needed to be ported.  This was used to compile the bootstrap compiler which was used to compile the full compiler.
What would be a good minimal subset of D?  (Clearly implementing ASM sections would work, but that fails the test of "good".)

It's only "best" in the sense of works on just about everything.  It's a pretty
widely acknowledged fact
that the easiest way to get a backend that compiles or cross-compiles for a
ridiculous number of
platforms/architectures AND is still capable of generating useable code
(performace, debugging, etc.) is
through GCC.

Building a D -> C -> C Compiler system would certainly be possible (someone else
was actually
working on it I believe), but it is NOT the best way to spread the language.
Such a system would be
hellish to use for development, and would mostly only be useful for compilation
of projects developed
on systems that support DMD.

Porting to GCC affords both a long list of supported systems AND the features of
a modern compiler.
Hence, I am much more inclined to say that GCC is the much better way of
extending the reach to other
systems, and that a C-dumping implementation should only be necessary/used for
obscure (or perhaps
embedded) systems that GCC cannot or does not support.  I mean, I happen to know
that with a GCC
backend I could compile D programs that would run on my graphing calculator!  I
don't think GCC's
system list is a problem. ;-)

Owen

In article <c376ln$n7u$1@digitaldaemon.com>, KTC says...
>
>Olaf Rogalsky says...
>>
>>Well, I don't like the idea of C beeing the backends language very much.
>>Its too frustrating to see the translation process
>>D->IL->C->IL->ASSEMBLER->LINKEDITOR->EXE :-(
>>But on the other hand, one could make use of the wide availibilty of
>>C to get a portable D compiler.
>>
>
>It's not exactly an ideal way to generate an app but it's the best way for one to get a compiler for a language on as many platform as possible. After you get it on lots of platform and people using it, then one can start thinking about native compiler on the different platform....
>
>KTC
>
>

resistor@mac.com schrieb:
> It's only "best" in the sense of works on just about everything.  It's a pretty
> widely acknowledged fact that the easiest way to get a backend that compiles or cross-compiles for a
> ridiculous number of platforms/architectures AND is still capable of generating useable code
> (performace, debugging, etc.) is through GCC.

No, not the easiest.

> Building a D -> C -> C Compiler system would certainly be possible (someone else
> was actually working on it I believe), but it is NOT the best way to spread the language.
> Such a system would be hellish to use for development, and would mostly only be useful for compilation
> of projects developed on systems that support DMD.

No, noone has been workiing, because this someone didn't have time even to read through the whole source. :> And this someone would more gladly help on GCC based compiler than hack something alone.

For development, it could actually be not that bad. It would be outputting "preprocessed" C, so that the compiler would be able to keep track of files and lines of D source both in error messages and debug information. It would also compile faster than normal C, due to lack of header includes. It would also allow to use another compiler than GCC to compile yet much faster. It could automatically call the target compiler and convert the command line. Just there would be some weird naming in debug information, but it can be resolved somehow.

-eye

In article <c3agqd$dpr$1@digitaldaemon.com>, Ilya Minkov says...
>For development, it could actually be not that bad. It would be outputting "preprocessed" C, so that the compiler would be able to keep track of files and lines of D source both in error messages and debug information. It would also compile faster than normal C, due to lack of header includes. It would also allow to use another compiler than GCC to compile yet much faster. It could automatically call the target compiler and convert the command line. Just there would be some weird naming in debug information, but it can be resolved somehow.

I don't understand how you'd be able to track back to a D file and line number
from errors thrown in
the compiled C code.  If it failed, you'd be getting C errors, which could be
traced back to the C
dumped files but not the D files.  The same goes for debugging: you could debug
against the C files
but not the D files.  Definitely a suboptimal at best way of developing.  If you
have a way to get around
either or both problems, please enlighten me.

Also, when I said "easiest" I meant in a pros vs. cons sense.  GCC probably is
harder to code than a C
dumper, but it also provides a large offset in terms of benefits.

C Dumper Pros:
Fast compile
Absolute maximum platform support
Possibly easier to write

C Dumper Cons:
Easier to break (non-standard compilers, etc)
Limited optimization (high-level optimization is lost in the C dumping)
Difficulties in tracing errors
Nigh-impossibility of debugging

GCC Pros:
Most widely used compiler (easier to get people to accept)
Actively developed but stable enough to rely on
Good and improving optimization support (cf. GENERIC/GIMPLE)
Wide (not infinite) platform support
GNU Debugger support
Direct D compilation makes error tracing much easier

GCC Cons:
Much harder to code
Potentially slower (though should improve as the compiler itself improves)
Platform list is not infinite

resistor@mac.com schrieb:
> I don't understand how you'd be able to track back to a D file and line number
> from errors thrown in the compiled C code.  If it failed, you'd be getting C errors, which could be
> traced back to the C dumped files but not the D files.  The same goes for debugging: you could debug
> against the C files but not the D files.  Definitely a suboptimal at best way of developing.  If you
> have a way to get around either or both problems, please enlighten me.

Running a separate preprocessor on a C file spit out a file with a by convention different extension. This file contains #file and #line directives to be able to track C errors and debug information to the original source. These can be sprinkled in so that these point to the original D source. It is mostly possible to retain D semantics in C, except for names which get mangled. Some locals would be moved in structs in rare cases etc. It might be possible to match C++ compilers' mangling scheme and allow thus even to view unmangled names while debugging, but this would probably go too far.

> Also, when I said "easiest" I meant in a pros vs. cons sense.  GCC probably is
> harder to code than a C dumper, but it also provides a large offset in terms of benefits.

OK. As i said, if i get out of my debts, i'd more gladly help Ben on GCC  than write my own C dumper, although i see now that it (basically a reduced D dumper) is almost embedded in the DMD frontend source as a debugging feature.

-eye