Version 1.1 of ai12s/ai12-0346-1.txt

Unformatted version of ai12s/ai12-0346-1.txt version 1.1
Other versions for file 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