ffc team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

Just want to chip in here. FYI I'm currently adding a new representation to
ffc based on lp:uflacs, where I reuse some of the quadrature representation
code and new generate tabulate_tensor bodies with completely separate code.
I'm using my own code formatting utilities, which probably has its pros and
cons. I've also done some minor refactoring in ffc, so there will be a
merge soonish (when Anders gets the dolfin-ufc-geometry branch up to
speed). Hopefully this won't be difficult for you to merge with your
branch, I don't think it's too extensive.

As for the language differences, I think it will be practical to generate
code kernels that are both C99 and C++ compatible:

a) Usage of functions like sqrt, abs, pow from the std namespace.

- Instead of using std::foo in the code, we can add "using std::foo;"
in code targeted for C++. Makes the generated code cleaner as well.

b) Usage of C++ exceptions (only when hitting invalid orientation
markers).

- This can be removed and checked on the dolfin side like everything else,
as I
see it it's mainly there for a safe gradual introduction of the orientation
markers.

c) Usage of the static keyword (which has a different meaning in C99).

- Are you sure?
  http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1012
I think we can wrap global static declarations in an unnamed namespace
if the code is target for C++, and otherwise use the same declarations.

These should all be simple changes. Adding fortran support however
will not be as simple, because the code formatting framework is quite
low level and close to the structure of C/C++ code, so that's a completely
different project. Probably easier to generate C and call from fortran then
:)

Martin



On 26 February 2013 08:00, Kristian Ølgaard <k.b.oelgaard@xxxxxxxxx> wrote:

> On 25 February 2013 17:07, Florian Rathgeber
> <florian.rathgeber@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~ffc
> > More help   : https://help.launchpad.net/ListHelp
> >
>
> _______________________________________________
> Mailing list: https://launchpad.net/~ffc
> Post to     : ffc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ffc
> More help   : https://help.launchpad.net/ListHelp
>