Consider adding language extensions (e.g., Swift) #20

The ELFv2 ABI is primarily written with C and C++ in mind, with a smattering of Fortran references. Occasionally we are going to run into languages that require extensions to the ABI. For example, Swift requires a mechanism for handling multiple return values, as well as special registers for SwiftSelf and SwiftError. At the moment, Swift will only be implemented with an LLVM back end, but history teaches that this is unlikely to always be the case. For compatibility we should state how these extensions should be implemented under ELFv2.

It's also likely that other languages will require similar treatment in the future, so we should add a section for extensions, with Swift being one subsection of this.

The LLVM implementation for System z can be found as shown below (thanks, Uli!). Currently there is not yet an LLVM implementation for POWER, but one is needed and is expected to be added soon.

http://reviews.llvm.org/D19414 (LLVM)
http://reviews.llvm.org/D19432 (clang)

The ELFv2 ABI is primarily written with C and C++ in mind, with a smattering of Fortran references. Occasionally we are going to run into languages that require extensions to the ABI. For example, Swift requires a mechanism for handling multiple return values, as well as special registers for SwiftSelf and SwiftError. At the moment, Swift will only be implemented with an LLVM back end, but history teaches that this is unlikely to always be the case. For compatibility we should state how these extensions should be implemented under ELFv2. It's also likely that other languages will require similar treatment in the future, so we should add a section for extensions, with Swift being one subsection of this. The LLVM implementation for System z can be found as shown below (thanks, Uli!). Currently there is not yet an LLVM implementation for POWER, but one is needed and is expected to be added soon. http://reviews.llvm.org/D19414 (LLVM) http://reviews.llvm.org/D19432 (clang)

From Ian:

We should add information for multiple languages, not just swift. We need to get the details from the implementers of each language.

The questions are what the new sections need to say and where they need to be. For example, they might need to say:

What each language's fundamental types are with their sizes and alignments (like section 2.1.2.2 and tables 2-11 to 2-15).
Their padding rules (like section 2.1.2.3 and figures 2-1 to 2-10).
Other types (like section 2.1.2.4, tables 2-16 to 2-18 and figures 2-11 to 2-15 (BTW, how did we decide what's a table and what's a figure?)).
How each language-specific type is passed as a parameter (section 2.2.3 and 2.2.3.2) and returned as a result (section 2.5).
Whether variables can be in auto, static or extern, or just on the heap.

So the additional information could be in additional subsections mixed in with those, or a whole new section with subsections for each language and issue, or an additional chapter or appendix. We might want to reserve empty (sub)sections now to simplify later additions, or maybe we can wait without causing trouble later.

From Ian: We should add information for multiple languages, not just swift. We need to get the details from the implementers of each language. The questions are what the new sections need to say and where they need to be. For example, they might need to say: - What each language's fundamental types are with their sizes and alignments (like section 2.1.2.2 and tables 2-11 to 2-15). - Their padding rules (like section 2.1.2.3 and figures 2-1 to 2-10). - Other types (like section 2.1.2.4, tables 2-16 to 2-18 and figures 2-11 to 2-15 (BTW, how did we decide what's a table and what's a figure?)). - How each language-specific type is passed as a parameter (section 2.2.3 and 2.2.3.2) and returned as a result (section 2.5). - Whether variables can be in auto, static or extern, or just on the heap. So the additional information could be in additional subsections mixed in with those, or a whole new section with subsections for each language and issue, or an additional chapter or appendix. We might want to reserve empty (sub)sections now to simplify later additions, or maybe we can wait without causing trouble later.

To be deferred beyond revision 1.4.

Labels Milestones

Consider adding language extensions (e.g., Swift) #20