I talked a bit about memory in this thread, which is somewhat related although about the shared memory.
viewtopic.php?f=13&t=1655For on-core code the "easiest" "solution" is to hard-code the memory locations if you want to write to them from the arm - but this is really only easy for simple prototypes and doesn't scale. You can also read the memory on the core using dma (or e_memcpy iirc) so only the epiphany code needs to know it's local address. In general you want to do this anyway due to the fan-out of the number of cores. That just shifts the addressing problem to the shared memory though and it still needs a solution.
When I hit this problem last year my first solution was to use a script to extract the symbol offsets from the compiled elf file and turn them into a header file that I could include. The ARM code would then use the offsets to calculate on-core or shared-memory addresses "by hand". At least I could write code without having to manually implement a linker with pen and paper.
Putting everything in a single struct can help with the work involved. You can also use the linker to assign fixed addresses but TBH I find this even less acceptable because again you're literally using a pen and paper to do what the linker is supposed to be doing.
But that still sucked hard so I spent a couple of months writing my own solution based on a more realistic and flexible model of the cpu capabilities. However I have no idea if the "new sdk" with the new device driver will simply break all that: and if it breaks it too hard i'm not sure when (or even if) i would have it working again. I may just never "upgrade".
Elf is designed to be simple so it isn't much work to add symbolic lookup to the esdk. I was pretty amazed when I saw the initial solution of using srec files: I mean I though that was pretty arcane and clumsy when I used it once in uni around '91 and it's
much less code to just read the elf file directly. I could understand it being used as a first-cut prototype to get something booted (actually not really) but it should never have been part of the public release.
You really shouldn't be using volatile for any of those pointers fwiw.