[swift-evolution] ABI in Layman's terms?

Jonathan Hull jhull at gbis.com
Fri Aug 12 16:28:17 CDT 2016


This is an excellent explanation!  I think I (mostly) understand.

Thanks,
Jon

 
> 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.
> 
> John.
> 
>> 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...
>> 
>> Thanks,
>> Jon
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 



More information about the swift-evolution mailing list