>
> Wow!
>
Ditto for D, what I've seen so far :)

While I'm working on this, I do notice that the current D implementation is somewhat biased towards a Windows platform. It would be nice if the runtime system was more or less independent of the OS, or at least cleanly separated. I understand this is a first prototype and to get results fast you have to make some dirty choices sometimes, but "idealistically" it would be better. The same goes for dependence on C library calls, IMO

A particular issue I ran into, is the Windows-specific code generation conventions in linker symbols. 'dmd' generates __d_throw@4 as a symbol for 'throw', and expects to find a __stdcall C function (implemented in deh.c). This meant that I had to specifically use '-mn' for compiling the C code using 'dmc'. Just as an example

So, on my wishlist for 'dmd' features so far I have:
- support for memory models other than '-mn' (Win32), or at least a model
that is not so win32 specific. A gcc frontend may solve this
- some control over segment names of symbols: I have some code that is only
used during system initialization, so in my current gcc implementation I put
it in a separate segment and discard it after startup

"Jeroen van Bemmel" <anonymous@somewhere.com> wrote in message news:b0ustc$2p9u$1@digitaldaemon.com...
> Ditto for D, what I've seen so far :)

Thanks!

> While I'm working on this, I do notice that the current D implementation
is
> somewhat biased towards a Windows platform. It would be nice if the
runtime
> system was more or less independent of the OS, or at least cleanly separated. I understand this is a first prototype and to get results fast you have to make some dirty choices sometimes, but "idealistically" it
would
> be better. The same goes for dependence on C library calls, IMO

This will get better.

> A particular issue I ran into, is the Windows-specific code generation conventions in linker symbols. 'dmd' generates __d_throw@4 as a symbol for 'throw', and expects to find a __stdcall C function (implemented in
deh.c).
> This meant that I had to specifically use '-mn' for compiling the C code using 'dmc'. Just as an example

deh.c is so heavilly dependent on windows structured exception handling anyway, I didn't think that was a problem!

> So, on my wishlist for 'dmd' features so far I have:
> - support for memory models other than '-mn' (Win32), or at least a model
> that is not so win32 specific. A gcc frontend may solve this
> - some control over segment names of symbols: I have some code that is
only
> used during system initialization, so in my current gcc implementation I
put
> it in a separate segment and discard it after startup

There are a lot of great reasons to graft the D front end onto gcc.