-----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: 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-----
smime.p7s
Description: S/MIME Cryptographic 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
