"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>.

> 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

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

"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.

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

"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. =)

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.

"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!).

"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>.