I assume we do not want a flag day, where the user flips a switch, and long double is now IEEE 128-bit. That would involve having 2 sets of libraries, etc. to work with existing programs and new programs. Even if the user does not directly use long double, it still may be visible with the switch, since many of the math libraries use long double internally to get more precision. I assume that the current IBM extended double format gives better performance than the emulation functions.
I assume the way forward is to initially have a __float128 type that gives IEEE 128-bit support for those that need/want it, and keep long double to be the current format. When all the bits and pieces are in place, we can think about flipping the switch. However, there we have to think about appropriate times for distributions to change over. In terms of calling sequence, there are 2 ways to go: Either pass/return the IEEE 128-bit value in 2 registers (like long double is now) or treat it like a 128-bit vector. The v2 ELF abi explicitly says that it is treated like a vector object, and I would prefer the v1 ELF on big endian server PowerPC's also treat it like a vector. If we are building a compiler for a server target, to prevent confusion, I think it should be a requirement that you must have -mvsx (or at least -maltivec -mabi=altivec) to use __float128. Or do I need to implement two sets of conversion functions, one if the user builds his/her programs with -mcpu=power5 and the other for more recent customers? I don't have a handle on the need for IEEE 128-bit floating point in non-server platforms. I assume in these environments, if we need IEEE 128-bit, it will be passed as two floating point values. Do we need this support? -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
