Epiphany ABI Change Proposal

In order to improve software performance in the current silicon and to make forward binary compatibility practical, I am proposing the following changes to the Epiphany Application binary interface (ABI). ABI changes get more painful the more successful a platform gets and with the Epiphany starting to gain momentum, I feel this may be our last chance. These changes will all be incorporated into the compiler and linker so for the vast majority of you, the changes will be applied automatically once you recompile your code with an up to date Epiphany compiler.

List of proposed changes:

  1. Make register R32-R63 caller saved. Currently R32-R63 is a mix of caller and callee saved registers. Reason: Better (code size, performance, ease of assembly, energy) for leaf cell type libraries (like PAL).
  2. Move Frame Pointer to R15. Reason: Better performance/code density for software caching
  3. Reserve addresses below 0x100 for internal use. Reason:  Reserved for future systems and SDKs. “Get out of jail card for Adapteva.” Compiler user code starts at 0x100
  4. Disallow fetching instructions from external memory. Programs must be fetched from the local memory (currently 32KB). For large programs some kind of software caching should be used. Reason: Very expensive feature from a chip standpoint and provides poor performance. Not scalable for future silicon.
  5. The “-” option for TESTSET has been removed.

An updated SDK will be released shortly to reflect these ABI changes. If you have objections to any of these changes, speak now, or forever hold your peace. These proposals will become final in 30 days unless there are serious objections.  Please leave comment in the section below or write an email to “support@adapteva.com” to voice concerns.

Andreas

9 Comments

  • Andreas, I have doubts whether you can just “change” the ABI with multiple versions of GCC out there using the old ABI… We’ll surely need some command line switch for selecting v1 vs. v2 ABI, and maybe you can then default to the new one. Don’t forget that not everyone is using your SDK.

  • Sylvain Munaut says:

    Also need to make sure that the ELF header is modified appropriately so that different ABI object file can’t link

  • Piotr5 says:

    I have some questions:
    ad 3), afaik registers are stored in 0-0x100 before the program starts. so I guess it means also during execution this area will be unavailable. does it cause other changes than merely program-start at 0x100?
    ad 4) does that mean no sync flags in arm memory is possible? suppose I wait for arm to finish reading old data before sending new, and want to sync communication off-chip with other cores, keep it strictly regulated (i.e. disallow all communication initiated by arm). or is this change only affecting code-fetch? does it affect (code-)fetching from neighbouring epiphany cores? if it’s about code-fetching, can there be made an exception for never-used code like error-handling or handling out-of-mem situations on epiphany cores? where I completely agree with 4) is that code-placement in external memory should be turned off by default. but that’s no abi-change, it’s a change of default behaviour…
    other than these, I see no problem with the changes, from a logical point of view…

  • Eduardo Lopes says:

    I have no problems with points (1) , (2) or (3) because 256 bytes is a very small chunk.

    For point (4) i have the same doubts that Piotr manifested, but up front i would not recommend remove the feature of fetching user-data from other cores. i was working on some fft test codes that relied on partial data stored on neighbouring cores and it seemed a promising path, but i could totally work with the main RAM (shared with the Zynq) if the communication speed between the epiphany and the RAM gets significantly improved.

  • Tomas Nordström says:

    I also have some concerns regarding “Disallow fetch from external. Application must use software caching or fit everything in internal memory.”
    If that was intended only for code/instructions it is somewhat understandable, but if it also concerns data I would strongly protest.
    Still, even for code/instructions we have, with our restricted local memory, a clear problem fitting larger applications onto Epiphany. Thus, having some mechanism to at least run a large application (even if it is super slow) on the Epiphany is beneficial. This is especially true during the development of your application (as you most likely do not want to run the final application out of external memory).

  • Andreas,
    Point taken, just as long as we don’t go overboard. The Epiphany ABI is niche. Consider the cost of reminding the whole world to use “-std=c99” in 2015! Backwards compatibility carries enormous costs.
    Andreas

  • Sylvain. Good point, will be implemented!

  • Post has been clarified to specify that change #4 applies only to program(instructions) not data.

  • Paul Gater says:

    Could you confirm when the updated SDK/compiler will be released?

    Regards,

    Paul

Leave a Reply