On Thu, Aug 5, 2010 at 12:08 AM, Dag Sverre Seljebotn <[email protected]> wrote: > On 08/05/2010 06:01 AM, Carl Witty wrote: >> I'm starting by essentially duplicating all of the generate_* methods >> into generate_dotnet_* methods, and modifying the duplicated methods >> to generate C++/CLI code. My hope is that once I have a working >> > Ah, this is very interesting -- when I've spoken with Enthought on the > matter we've largely ignored C++ for this and were talking about a C# > backend.
I convinced the Enthought people that a C++/CLI backend was the best first step. For a variety of reasons (mostly the fact that Cython's "extern from" describes the API, not the ABI, but also catching C++ exceptions and turning them into Python exceptions) a C# backend would have to generate C or C++ wrappers for every operation on "extern from" values/types (function call, global variable read, global variable write, struct member read, struct member write, ...). On the other hand, a C++/CLI backend can handle "extern from" in exactly the same way that the current C/C++ backend does. Once the C++/CLI backend works, a C# backend is a possible next step. All of the code generation for C# to interface with IronPython would be exactly the same as C++/CLI (modulo minor syntactic issues that can easily be localized). Even if the ultimate goal is a C# backend, I think that very little of the work on a C++/CLI backend would be wasted. >> compiler, I can refactor to merge most of the methods back together >> (eliminating the duplicate code) while still not being very intrusive >> to the original codebase. >> > > Have you considered writing a transform instead of adding more methods > to the nodes? E.g. something like Cython/CodeWriter.py for the .NET > backend? That would be even less intrusive...ideally, one would just > configure the pipeline differently depending on what the backend is. I did consider this briefly. Given the choice between writing a backend basically from scratch, or being able to copy a working backend and incrementally modify it, the latter seemed a lot easier. :) Once I have a working compiler, and it's time to clean up the code for submission, I'll definitely consider this approach. Based on the tiny amount of work I've done so far, though, I suspect that I may be able to share a lot of code with the existing backend that would end up duplicated if I made my backend into a transform. > (I once suggested that the CPython generation was also moved into a > seperate generator class like this as well; of course, that's a lot of > unnecessary work) Sounds like a good idea to me. Also, if the existing backend and the C++/CLI backend were both transforms, that would make it a lot easier for them to share code (they could both inherit from a generic "code generation" transform, for instance). But I doubt if I'll have time to work on this... > I'm just not too sure about having "if dotnet:" all over the place > (eventually). Of course, you should just do whatever gives results > quickest at this point (and I very much trust your judgement), I'm just > making sure the option is mentioned. Keeping the number of "if dotnet:" down is definitely an important long-term goal. (For now, I'm adding lots of them, but I expect to remove them and handle the cases some other way before I submit the code.) > Dag Sverre Carl _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
