Version 1.1 of ai12s/ai12-0346-1.txt
!standard 5.5(2/3) 19-10-11 AI12-0346-1/00
!standard 5.5.2(5/4)
!standard 5.5.2(7/3)
!class Amendment 19-10-11
!status work item 19-10-11
!status received 19-10-07
!priority Medium
!difficulty Medium
!subject Ada and OpenMP
!summary
** TBD.
!problem
Systems like OpenMP are commonly used to provide the framework for
lightweight threading, GPU usage, and similar capabilities. (OpenMP directly
supports C and Fortran.) Since these frameworks are already in industrial
usage, it would be useful if Ada (particularly the new parallelism features)
could use them.
!proposal
** TBD.
!wording
** TBD.
!discussion
The OpenMP session at ARG meeting #62 showed that implementing the proposed
parallel constructs of Ada on top of OpenMP is feasible. In many of the
semantic choices, OpenMP arrived at the same solution that the ARG did
(particularly in the case of termination semantics), so the amount of extra
mapping needed seems fairly minimal.
The Ada Standard probably should not directly reference the OpenMP standard;
it should remain possible to implement Ada in a variety of ways (including on
bare machines). Moreover, it's not clear that ISO rules would allow referencing
OpenMP at all; generally, we can only reference other ISO standard. Thus, any
OpenMP-specific mechanisms have to be implementation-defined.
Ada does need additional mechanisms for tuning (many of the capabilities of
OpenMP are aimed at tuning particular parallel code). In the case of
declarations and overall configuration, aspects and pragams have the correct
semantics (including the ability to define implementation-defined aspects
and pragmas). It is possible that some of these aspects and pragmas can be
generalized enough to put them into the standard (for instance, the target
aspect to specify where a data object is stored could be language-defined
if we decide to have a standard parallelism library which would necessarily
include types/objects for defining target capabilities. The details of the
the supported targets would, of course, remain implementation-defined).
We do need a way to specify tuning mechanisms for individual parallel
constructs. Chunk_specifications provide this for one such parameter, but
there are many others that are relevant. We could use pragmas for this
purpose, but that is not ideal for the same reasons that we have moved aways
from entity-specific pragmas for declarations in favor of aspect
specifications.
[There's lots more to say here, but your editor is not the person to say it.]
!ASIS
[Not sure. It seems like some new capabilities might be needed,
but I didn't check - Editor.]
!ACATS test
ACATS B- and C-Tests are needed to check that the new capabilities are
supported.
!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent