digitalmars.D - Front end/Back end
- Greg Hermann (6/6) Jan 12 2006 From what I've been reading, I love the language -- I know there's a gdc
- Sean Kelly (4/8) Jan 12 2006 Now there's an idea. It hadn't occurred to me that the VC back-end
- Hasan Aljudy (4/12) Jan 12 2006 Interesting, never heard of the "Microsoft Phoenix architecture",
- pragma (9/15) Jan 12 2006 Well, some of us are working on producing binary loading and binding
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (6/10) Jan 12 2006 * Completely D-coded library, suitable for use under Windows or Unix
- pragma (9/18) Jan 12 2006 That's it exactly. The project isn't intended to be exclusive to Intel
- =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= (11/20) Jan 13 2006 Well, it did say "Unix" and not Linux actually. Mac OS X is a "Unix".
- Mike Parker (5/7) Jan 13 2006 And the only thing standing in the way of that is me getting my hands on...
- Sean Kelly (8/24) Jan 12 2006 From what little I've read, it looks like Phoenix is really just a
- pragma (14/37) Jan 12 2006 I read a little deeper into the overview on it this time. Seems I was a...
- Sean Kelly (5/44) Jan 13 2006 I just meant that so long as the code generator can produce native
- pragma (3/22) Jan 13 2006 Correct.
- ZZ (5/13) Jan 12 2006 For those wondering the link is:
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
Sean Kelly <sean f4.ca> 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
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
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
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
In article <dq6t0b$1ind$1 digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...pragma wrote: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 yahooWell, 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.
Jan 12 2006
pragma wrote: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"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.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
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
pragma wrote:In article <dq6pr2$1h2u$1 digitaldaemon.com>, Greg Hermann says...Does this conflict with the code generator used though?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.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
In article <dq6u91$1jen$1 digitaldaemon.com>, Sean Kelly says...pragma wrote:I'm not 100% sure what you mean.In article <dq6pr2$1h2u$1 digitaldaemon.com>, Greg Hermann says...Does this conflict with the code generator used though?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/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 yahooIn 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.
Jan 12 2006
pragma wrote:In article <dq6u91$1jen$1 digitaldaemon.com>, Sean Kelly says...I just meant that so long as the code generator can produce native binaries, it shouldn't matter which code generator is used, correct?pragma wrote:I'm not 100% sure what you mean.In article <dq6pr2$1h2u$1 digitaldaemon.com>, Greg Hermann says...Does this conflict with the code generator used though?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/Definately. SeanI 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.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.
Jan 13 2006
In article <dq8o6l$12qc$1 digitaldaemon.com>, Sean Kelly says...pragma wrote:Correct. - EricAnderton at yahooIn article <dq6u91$1jen$1 digitaldaemon.com>, Sean Kelly says...I just meant that so long as the code generator can produce native binaries, it shouldn't matter which code generator is used, correct?pragma wrote:I'm not 100% sure what you mean.In article <dq6pr2$1h2u$1 digitaldaemon.com>, Greg Hermann says...Does this conflict with the code generator used though?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/
Jan 13 2006
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
Jan 12 2006