Add functions to access PE-local memories to CPP API

[wirthjohannes]

This adds some functions to the C++ API, which allow to remove a PE (with a given PEID) from the scheduler (so it can't be used by normal launch() calls anymore). After removing the PE from the scheduler, it is available as a "standalone PE", allowing to manually handle this PE. A manually handled PE allows the user to start jobs on it and access it's PE-local memory.

This allows to main things (which are not possible with the standard scheduler and launch()):

• Launch multiple, sequential jobs on the same PE instance (e.g. if the PE keeps local state).
• Manually access (read/write) the PE-local memory from the host software.

Short example of using this:

auto pe = tapasco.acquire_pe_without_job(PEID);
pe->get_local_memory().copy_to() // Same arguments as with standard copy_to()
pe->launch(...); // Same arguments as with standard launch()
...
pe->release(); // Return the PE to the normal scheduler

[cahz]

I am not sure if we should include this in TaPaSCo, as it circumvents the existing way of interacting with PEs in a hacky way. The function acquire_pe_without_job was only a workaround to make the debugger work. Someone else should add their feedback.

Apart from that:

• Does this work when you have more than one instance of the same PE?
• Please add a comment that this should not be used in the general case (only if the user knows what he/she is doing)

[wirthjohannes]

You are correct, the current suggestion does not work when you have multiple instances of one PE. I didn't consider this. It is definitely possible to support this, but this will require more additions. Not saying we shouldn't do this, but this of course is very relevant to your main paint (whether we should include this, as it circumvents the existing way).

My opinion on this: I completely agree that the tapasco.launch() call (in conjunction with makeWrappedPointer, makeLocal, ...) should be the main, default way of interacting with PEs. However I do think that there are valid cases, where - for some reason - you can't use this convenient standard API, but need something with more "custom" control. We actually already support this in some places, e.g. by manually using tapasco.copy_to() instead of makeWrappedPointer. I think it is reasonable to also support such advanced options, which are more flexible (but require some knowledge by the user). In my opinion this PR also falls under this category (as do further changes which will be required to make this work with multiple instances of one PE).

So I think it does make sense to include this in TaPaSCo. Just to offer this flexibility if it required and the user knows what he/she is doing). I agree that we should mark such stuff as "advanced" in comments or so (or even somehow separate this advanced API from the basic API; but I'm not sure right now how this would look like).

[wirthjohannes]

I changed this to be more generally applicable, see the updated description