e_loader and non-SPMD applications

[mhonman]

[ysapir]

On the move from eSDK 4 to eSDK 5, eCore allocation was changed from a static numbering, using the CORE_ROW and CORE_COL constants, to a workgroup relative eCore enumeration. It is true that the change was not 100% backward compatible in using the existing LDF's.

If you examine the sample programs from eSDK 4 (you can create the prototype multicore project in Eclipse, for example), you'll see that there used to be a code module called coords.c which defined those constant on a per-core basis, allowing the linker to allocate the core's DRAM slice accordingly.

With eSDK 5, new methods of managing the shared memory are required. Not all of the corners were addresses, though, so some caution is required.

BTW, even SPDM projects may suffer if the functions in DRAM are not thread-safe.

[mhonman]

[ysapir]

1. The eLib was not intentionally developed as thread-safe, although I don't see why the majority of functions won't be such. As for the GNU libraries, I can't tell. YMMV.

2. You can study the diffs between the three standard LDF's to learn how to relocate functions in different memory regions.