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

Greg Hermann wrote:
> 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?

Now there's an idea.  It hadn't occurred to me that the VC back-end might be usable by a third party program.


Sean

Greg Hermann wrote:
> 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...
> 
> 

Interesting, never heard of the "Microsoft Phoenix architecture", googling for it returned an interesting result!

If someone can do it, it would be awesome.

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/

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.

- EricAnderton at yahoo

pragma wrote:

> Well, some of us are working on producing binary loading and binding
> capabilities for D. 
> 
> http://trac.dsource.org/projects/ddl/

* Completely D-coded library, suitable for use under Windows or Unix

Claire: "Oh, we got both kinds. We got country *and* western"


Like Derelict, sounds yet like another non-Mac project. Too bad... :-)

In theory, I guess it's just getting someone to write Mach-O handlers.

--anders

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?

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


Sean

Greg Hermann wrote:
> 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...
> 
> 
For those wondering the link is:
http://research.microsoft.com/phoenix/

It looks very interesting, came earlier then I expected.

Zz

In article <dq6t0b$1ind$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>pragma wrote:
>
>> Well, some of us are working on producing binary loading and binding capabilities for D.
>> 
>> http://trac.dsource.org/projects/ddl/
>
>* Completely D-coded library, suitable for use under Windows or Unix
>
>Claire: "Oh, we got both kinds. We got country *and* western"
>
>
>Like Derelict, sounds yet like another non-Mac project. Too bad... :-)
>
>In theory, I guess it's just getting someone to write Mach-O handlers.

That's it exactly.  The project isn't intended to be exclusive to Intel machines, but I can only test so much PPC/Mac code when I don't have access to one. ;)

Getting object loading support on the Mac would be the *only* hurdle to playing along.  Actually, once we see OSX running on x86 machines, it is my hope that you're going to see this project come in very handy.

- EricAnderton at yahoo

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.

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

- EricAnderton at yahoo

pragma wrote:

>>Like Derelict, sounds yet like another non-Mac project. Too bad... :-)
>>In theory, I guess it's just getting someone to write Mach-O handlers.
> 
> That's it exactly.  The project isn't intended to be exclusive to Intel
> machines, but I can only test so much PPC/Mac code when I don't have access to
> one. ;)

Well, it did say "Unix" and not Linux actually. Mac OS X is a "Unix".
(they did get sued for using the term UNIX though, without paying up)

http://www.apple.com/macosx/features/unix/

Mac OS X does have dlopen, but I believe you want "something different"

> Getting object loading support on the Mac would be the *only* hurdle to playing
> along.  Actually, once we see OSX running on x86 machines, it is my hope that
> you're going to see this project come in very handy.

Good thing that GDC works for Mac OS X86 then. At least, it compiles :-)

I don't think we'll see a legal generic version soon, just Apple boxes. (i.e. it's not that it doesn't work, it's that they don't want to do it)

--anders


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