On Feb 11, 2014, at 16:49 , Roland Haas <[email protected]> wrote:
> Signed PGP part > Hello all, > > > Log: Separate C and C++ APIs for complex numbers > I am updating the UserGuide and Reference guide to reflect this > change. In particular I will mark the CCTK_CmplxAdd etc arithmetic > functions as deprecated. There is one issue left even with the current > change: > > On 32bit (not on 64bit) machines when one returns a complex number > from C or Fortran to a C++ caller (but not when accessing a > CCTK_COMPLEX grid function in memory) there is an API incompatibility > that makes the C++ caller see the wrong result. Should we mention this > in the UserGuide (for the occasional user that still has a 32bit build > eg in a virtual machine which are slightly smaller when using 32bit code)? > Or just stay silent and hope for the best (not really my preferred > option)? (a) This incompatibility may also exist on other (non-Intel) systems. It just so happens that the 64-bit Intel ABI has an optimization built in that returns C++ complex numbers (structs) the same way as Fortran complex numbers. (b) This incompatibility has existed for a long time. Previously, we defined our own complex numbers, in a way compatible with the way C++ defines them. This meant that Fortran and C were not interoperable (with Fortran more efficient). Currently, C++ is the odd one out (with C++ less efficient). (c) ABIs are difficult beasts. For example, whether AVX instructions are enabled or not (using -march=native/-xHost or not) changes the ABI for vector data types, i.e. CCTK_REAL_VEC. Luckily we don't support CCTK_REAL_VEC in Cactus, only thorns using thorn Vectors use it, presumably only internally. I would mention the problem, stating that cross-language calls between C/Fortran on one hand and C++ on the other hand cannot return CCTK_COMPLEX. (The alternative is to return complex numbers by reference, i.e. via an additional argument.) I would not particularly emphasize the problem, since it doesn't seem to be important as it didn't surface for 14 years. -erik -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Users mailing list [email protected] http://cactuscode.org/mailman/listinfo/users
