Anders F Björklund wrote:

> PS.
> Derelict isn't really impossible to do on a Mac either... Just not done.

And the only thing standing in the way of that is me getting my hands on a Mac (and learning how to program it), or a Mac user willing to become the maintainer of a Mac port :) I actually *want* to get Derelict up and running on the Mac eventaully.

pragma wrote:
> In article <dq6u91$1jen$1@digitaldaemon.com>, Sean Kelly says...
>> pragma wrote:
>>> In article <dq6pr2$1h2u$1@digitaldaemon.com>, Greg Hermann says...
>>> >From what I've been reading, I love the language -- I know there's a gdc
>>>> front-end compiler for gcc, which reuses the backend and so was wondering if a
>>>> similar process work reusing the new Microsoft Phoenix architecture for plugging
>>>> into a common backend? (or patching directly to c1xx/c2, but that's a little
>>>> shadier). Should mean that native tools would work pretty directly, all the file
>>>> formats would be up to date, etc, etc...
>>> Well, some of us are working on producing binary loading and binding
>>> capabilities for D. 
>>>
>>> http://trac.dsource.org/projects/ddl/
>> Does this conflict with the code generator used though?
> 
> I'm not 100% sure what you mean.

I just meant that so long as the code generator can produce native binaries, it shouldn't matter which code generator is used, correct?

>>> In the future, I'd like to branch out into runtime code generation and
>>> reflection similar to what the CLI supports now.  I suppose that if you throw in
>>> the DMD frontend, the only piece missing parts are covered by the GNU toolchain,
>>> although I'd love to see a D solution for that instead.
>> From what little I've read, it looks like Phoenix is really just a generic API for code generation--it's target agnostic.  While I'd like an all-D solution as well, there's a lot to be said for not having to write an optimizer or code generator.  The result would be the Windows equivalent of GDC.
> 
> I read a little deeper into the overview on it this time.  Seems I was a little
> off in my earlier assessment.
> 
> http://research.microsoft.com/phoenix/architecture.aspx
> 
> Think about where DDL is now, and how we can load modules and libs and
> manipulate them at the module level.  Now imagine throwing CLI and .exe loading
> support into the mix and being able to rip things apart at the function and
> field levels as well.  All these wonderful recompilation and optimization
> possibilities fall out.  Suddenly, writing an optimal compiler or linker is
> irrelevant: you can now optimize everything after the fact provided you back
> this library and write some damn good diagnostics to go with it.  You could even
> write a highly optimized JIT for the CLI with this as well. Amazing.

Definately.


Sean

In article <dq8o6l$12qc$1@digitaldaemon.com>, Sean Kelly says...
>
>pragma wrote:
>> In article <dq6u91$1jen$1@digitaldaemon.com>, Sean Kelly says...
>>> pragma wrote:
>>>> In article <dq6pr2$1h2u$1@digitaldaemon.com>, Greg Hermann says...
>>>> >From what I've been reading, I love the language -- I know there's a gdc
>>>>> front-end compiler for gcc, which reuses the backend and so was wondering if a similar process work reusing the new Microsoft Phoenix architecture for plugging into a common backend? (or patching directly to c1xx/c2, but that's a little shadier). Should mean that native tools would work pretty directly, all the file formats would be up to date, etc, etc...
>>>> Well, some of us are working on producing binary loading and binding capabilities for D.
>>>>
>>>> http://trac.dsource.org/projects/ddl/
>>> Does this conflict with the code generator used though?
>> 
>> I'm not 100% sure what you mean.
>
>I just meant that so long as the code generator can produce native binaries, it shouldn't matter which code generator is used, correct?

Correct.

- EricAnderton at yahoo