[swift-evolution] ABI in Layman's terms?
jhull at gbis.com
Fri Aug 12 16:28:17 CDT 2016
This is an excellent explanation! I think I (mostly) understand.
> On Aug 11, 2016, at 9:16 AM, John McCall <rjmccall at apple.com> wrote:
>> On Aug 11, 2016, at 1:52 AM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> wrote:
>> Could someone explain in simple terms what the ABI is and what sorts of things might affect it?
> The ABI for a compiled programming language is the set of rules for how all of its interoperating features are implemented in the compiled result.
> For example, in Java the primary ABI is the JVM specification plus some common-sense rules about how language features are mapped to JVM features. JVMs do not typically interoperate with other code at a direct binary level, and so the details of actual memory layout are not ABI.
> Not all language features require interoperation, or only require it a certain kind of opaque interoperation. For example:
> - Type aliases do not currently have any ABI impact because by design they are erased at compile time. However, a complete reflection design might provide some mechanism for introspecting type-aliases at runtime, which would require information about type aliases to be present in the compiled output; the representation of that information would be ABI.
> - Closures in most programming languages do not allow external code to modify their captured values; only the closure's invocation function can access them, and that is generated together with the capturing code, so the exact methodology of performing a capture is not ABI. However, arbitrary code can invoke the closure, and so the opaque representation of a closure value and the process for invoking it are ABI.
> And so on.
>> I had thought it was the layout in memory of structs/classes/etc… and how the program knows where to go to find a particular field. This seems to be incorrect though, as I have seen many features that I would assume have some affect on this layout ruled “out of scope for phase 1”. For example, I would think that many generics features would have an impact on the ABI, or the idea of COW (via secret boxing) for structs, or even union types.
>> At the very least, I would think that mix-ins would have a fairly significant effect.
>> I am obviously missing something here, and I want to provide constructive effort to the community (as opposed to distracting from the task at hand), so I would appreciate some clarification/guidance...
>> swift-evolution mailing list
>> swift-evolution at swift.org
More information about the swift-evolution