The projects are base on a view that the entire world is one big computer. Everything cooperats in some way. On some places there are more processors and a more powerful network. In this system one should be able by using proper semantics to express what is assumed to be necessary to run the processors professionally.
In a first study the entire world is not used but a number of subsystems (later on they are connected to form the world). The resulting systems can be considered separate workstations, a multiprocessor or a computer with massive parallelism, or why not an embedded system in some equipment.
The concept parallelism for most of the computer society has evolved from sequnetial computers. Here, it is just the contrary. At the starting point everything is parallel and this has to be ordered hierarchically or sequentially.
In order to understand the performance issues for such systems a resource theory for multiprocessors was developed. It is based on the existens of only three resources: execution, storing and communication. The theory gives relations between these and the program executed in such a computer. The theory is the base for subsequent work.
The allocation of the resources above is considered in an abstract enviroinment whithout considering the semantics of the execution. In a stepwise research process the program is first allocated on a massive and homogeneous multiprocessor. In the next step it is not considered homogeneous but consisting of a number of clusters. In a subsequent step there are also hierachies of resources.
In order to be able to work in a global system identifiers are used to refer to objects. Extensive demands are put on these identifiers. In a special project their semantics are investigated.
Finally a model is studied that could be used to express most problems. It should be a base for the semantics of programming language, execution mechanisms and other details.
The concepts imperative and applicative are for the matematician essentially different. Of this reason the processors based on the two principles have been very different. It is probably not necessary. In a special part it is shown how similar the principles are. Especially, it is shown that for current code allocation and scheduling have been woven together to a program, but the basic principles are the same. It is true that the imperative semantics has side effects, but in this case it is more a detail.