www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Front end/Back end

reply Greg Hermann <Greg_member pathlink.com> writes:
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...
Jan 12 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Jan 12 2006
prev sibling next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
Jan 12 2006
prev sibling next sibling parent reply pragma <pragma_member pathlink.com> writes:
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
Jan 12 2006
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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
Jan 12 2006
parent reply pragma <pragma_member pathlink.com> writes:
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
Jan 12 2006
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
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.
Jan 13 2006
parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Jan 13 2006
prev sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jan 12 2006
parent reply pragma <pragma_member pathlink.com> writes:
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
Jan 12 2006
parent reply Sean Kelly <sean f4.ca> writes:
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...

capabilities for D. http://trac.dsource.org/projects/ddl/


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.

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
Jan 13 2006
parent pragma <pragma_member pathlink.com> writes:
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...

capabilities for D. http://trac.dsource.org/projects/ddl/


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
Jan 13 2006
prev sibling parent ZZ <ZZ zz.com> writes:
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...
 
 

http://research.microsoft.com/phoenix/ It looks very interesting, came earlier then I expected. Zz
Jan 12 2006