Within this framework for EC++, the aim of the Architecture SIG becomes well defined:
These tasks can all be viewed as separate, but together will provide a sufficient level of detail to constitute a specification for EC++, and thus a standard for acceptable architectures of parallel C++ variants. These tasks are not exclusively the domain of the Architecture SIG, however - interaction with the other SIGs will be required to ensure that the results generated by Architecture SIG are acceptable and suitable to the need of the other SIGs, and ultimately the end users of any implementation of the standard.
To expand on this, in the case of the communications interface, input from the Implementations SIG will be required to ensure that any proposed communications interface is usable in terms of the communications packages and libraries available on real parallel machines.
A similar situation exists with the systems management libraries, in that some of the contents and requirements specified in Architecture SIG may be peculiar to particular machine architectures or exclusively not available on others. There is a further consideration in this section, however. As it is expected that their will be an interface to the systems management libraries which is accessible to the applications programmer, then input from the Applications SIG will be required stating what functionality and what tools are required in this section of the language by the end users as they are ultimately the ones who will use this section. It may be investigation will suggest that this section of the model will require further refinement to distinguish between language SM calls and User SM calls - Architecture SIG will be responsible for investigating this issue.
The contents of the Data Parallel libraries will require input both from the Applications SIG (for the reasons mentioned above) and from previous investigations into Data Parallel C++. At present the Architectures SIG has no members with Data Parallel Class library implementations and it is felt that the experience offered by such members would be an invaluable aid to the definition of this section of the standard. It is worth noting on this point that the Architectures SIG is currently contacting various Parallel C++ research groups with a view to broadening the input to Europa WG.
The most difficult issue to address and perhaps the most fundamental is the the issue of call libraries/language extensions in expressing parallelism. Earlier in this document approaches to this have been proposed - this is what will largely define the relationship between EC++ and C++. A standard definition in this area is fundamental to the definition of EC++ and fundamental to the appearance which EC++ instantiations will take. It will be the job of the Architecture SIG to define acceptable approaches to this issue and to ensure that these proposed approaches are acceptable to the other SIGs.