On 25 February 2013 17:07, Florian Rathgeber <florian.rathge...@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FFC generates C++ code, which makes sense given that the UFC interface > is specified in C++. It is however a limitation when you want to use > FFC to generate code for another interface/backend, as we do with > PyOP2 (see our branch https://code.launchpad.net/~mapdes/ffc/pyop2). > > We require all kernels (and by kernels I mean basically every UFC > function that is generated e.g. tabulate_tensor) to be C99 for a > number of reasons - which are not relevant for this discussion but > I'll mention some of them for those who are curious: > > 1) We target multiple hardware architectures (CUDA and OpenCL among > others), which have limited support for C++. We want to keep the door > open for more architectures in the future and the lowest common > denominator will likely remain to be C. > > 2) We rely on pycparser to be able to parse kernels for > instrumentations s.a. adding memory space attributes for OpenCL. To > the best of our knowledge there's no reliable and easy to use C++ > parser available in Python. > > It turns out that FFC generated code is in fact C99, apart from: > > a) Usage of functions like sqrt, abs, pow from the std namespace. > > b) Usage of C++ exceptions (only when hitting invalid orientation > markers). > > c) Usage of the static keyword (which has a different meaning in C99). > > So far we have overcome this issue by specializing those code snippets > we were using and which had C99 incompatible code in them. It seems > this is not a very elegant nor maintainable solution. > > At the moment FFC isn't quite set up for adding another code > generation backend that generates C99 code without introducing lots of > special cases. So my questions are:
The idea is that code formatting for C++ is handled by the module cpp.py which implements the format dictionary. To generate code for a different target language, you should implement a new format dictionary in c.py (or fortran.py). Then in modules like codegeneration.py where we currently do: from ffc.cpp import format, indent the import shold be depending on the target language. At least, that's how the design was intended. However, as C++ has been the only target language available in FFC since the beginning, the concept has never been tested and there are probably many cases, like the above, which are C++ spefic. The above approach would be the _correct_ way as I see it, but might require a bit of work initially. However, I think it will worthwhile in the end, particularly if you want to merge your code back into FFC. Kristian > 1) Is there value in restructuring FFC to better accommodate adding > code generation backends which do not target UFC? If so, where do we > start? You're welcome to look at how we're doing it at the moment, > which is an attempt to minimize changes to existing code and the FFC > pipeline and clearly not very elegant. > > 2) Is there an easier way of generating C kernels given the > constraints a-c we've identified above? > > These questions are related but I think could be treated separately. I > can think of a few options for 2): > > i) Add using declarations to the UFC kernel templates in ufc_utils and > drop the std:: prefix in the function bodies. This would (mostly) > allow functions bodies to remain C99 compatible. > > ii) Add Python string templates to the code snippets allowing to > choose between C++ and C99 specific statements where necessary and > depending on the code generation target i.e. replace "std::sqrt" by > "%(sqrt)s" and then replace that template depending > > I think ii) is more flexible but more "messy" but i) alone might be > too limiting and a combination of both might be required. > > In our branch we have taken great care to make sure we pass all tests > and don't break any UFC/DOLFIN functionality and we plan to add > additional tests exercising the pyop2 code generation backend. We'd > like to propose our branch for merging into the FFC trunk in the near > future and are therefore very keen on any ideas how to overcome the > issues I outlined and any comments and suggestions on the changes we > propose. > > Florian > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlErjFgACgkQ8Z6llsctAxYZIACg5N+c9uxeWwEoJ1x8SSy2rKHo > z/8AoMwa9cAwQwWeGEUi86g/Eilf/ms9 > =E3VL > -----END PGP SIGNATURE----- > > > _______________________________________________ > Mailing list: https://launchpad.net/~ffc > Post to : ffc@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ffc > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~ffc Post to : ffc@lists.launchpad.net Unsubscribe : https://launchpad.net/~ffc More help : https://help.launchpad.net/ListHelp
