Parallella Community

I approve of this thread.

This topic was discussed briefly in this discussion, mentioning the remap() API to get the same effect (and follows the original idea of @dar:

viewtopic.php?f=13&t=646&p=4037&hilit=remap#p4037

As noted by @shodruk, since the functionality does not guarantee that the requested address will indeed be mapped to the physical address, we felt that encapsulating that for the purpose of the eSDK would be the better solution.

This, obviously, should not hold the user from implementing such mapping himself, as the concept is pretty simple.

I'm with ysapir on this. The two addresses are used in different address spaces and the code should reflect that. Not wanting to deal with it is just lazyness. It also restricts the HAL to one particular implementation.

The approach taken by the OP, mapping to a specific requested address range, is quite standard and commonly used for implementing "pointer swizzling" object-oriented systems. mmap will ignore the requested address if it can't meet it (collision), but for this sort of application it should work great, and it would be good if future evolution of the sdk supported this, if only by implicitly avoiding breaking it.

The kittens are safe!

-frank

I'd agree with the OP on this, because the limited internal RAM of the e-cores means that there needs to be a close working relationship between host and core programs. And C does not exactly lend itself to pointerless programming!

If the shared RAM appears at different places in host and Epiphany address space, one has to adopt a FORTRAN IV mentality, i.e. "everything is an array in a COMMON block". Then only the start addresses of the arrays need to be converted - most sensibly at program startup - and things in the common structure are accessed via offsets from its start.

This is OK to do, although it does add another little layer of complexity (a bit annoying when the focus of the exercise is the parallel algorithm). However there is one really nasty side-effect of doing these address conversions - on the zedboard (at least) - if an error in the conversion results in an invalid address, when that address is dereferenced the host processor locks up and has to be rebooted. Makes debugging a bit tedious...

In the case of Parallella - and especially bearing the stated goal of "supercomputing for everyone" in mind - it would thus be very helpful to have locations in shared RAM and on the Epiphany mapped to their Epiphany-side addresses in the host program, as originally suggested by notzed.