Hi Janne,
Janne Blomqvist wrote:
back when I was active I did think about this
issue. IMHO the best of my ideas was to convert these into C++
templates.
I think this will work – but we have to be super careful:
With C++, there is the problem that we definitely do not want to add
dependency on libstdc++ nor to use some features which require special
hardware support (like exceptions [always bad], symbol aliases, ...). —
On some systems, a full C++ support might be not available, like
embedded systems (including some odd embedded OS) or offloading devices.
The libstdc++ dependency would be detected by linking as we currently
do. For in-language features, we have to ensure the appropriate flags
-fno-exceptions (and probably a few more). And it should be clear what
language features to use.
If we do, I think that would surely be an option.
What we're essentially doing with the M4 stuff and the
proposed in-house Python reimplementation is to make up for lack of
monomorphization in plain old C. Rather than doing some DIY templates,
switch the implementation language to something which has that feature
built-in, in this case C++. No need to convert the entire libgfortran
to C++ if you don't want to, just those objects that are generated
from the M4 templates. Something like
template<typename T>
void matmul(T* a, T* b, T* c, ...)
{
// actual matmul code here
}
extern "C" {
// Instantiate template for every type and export the symbol
void matmul_r4(gfc_array_r4* a, gfc_array_r4* b, gfc_array_r4* c, ...)
{
matmul(a, b, c, ...);
}
// And so on for other types
}
Cheers,
Tobias
