You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/EmbeddedSwift/ABI.md
+18-1Lines changed: 18 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -20,14 +20,31 @@ The compiler respects the ABIs and calling conventions of C and C++ when interop
20
20
21
21
## Metadata ABI of Embedded Swift
22
22
23
-
Embedded Swift eliminates almost all metadata compared to full Swift. However, class metadata is still used, because those serve as vtables for dynamic dispatch of methods to implement runtime polymorphism. The layout of Embedded Swift's class metadata is *different* from full Swift:
23
+
Embedded Swift eliminates almost all metadata compared to full Swift. However, class and existential metadata are still used, because those serve as vtables and witness tables for dynamic dispatch of methods to implement runtime polymorphism with classes and existentials.
24
+
25
+
### Class Metadata ABI
26
+
27
+
The layout of Embedded Swift's class metadata is *different* from full Swift:
24
28
25
29
- The **super pointer** pointing to the class metadata record for the superclass is stored at **offset 0**. If the class is a root class, it is null.
26
30
- The **destructor pointer** is stored at **offset 1**. This function is invoked by Swift's deallocator when the class instance is destroyed.
27
31
- The **ivar destroyer** is stored at **offset 2**. This function is invoked to destroy instance members when creation of the object is cancelled (e.g. in a failable initializer).
28
32
- Lastly, the **vtable** is stored at **offset 3**: For each Swift class in the class's inheritance hierarchy, in order starting
29
33
from the root class and working down to the most derived class, the function pointers to the implementation of every method of the class in declaration order in stored.
30
34
35
+
### Witness Tables ABI
36
+
37
+
The layout of Embedded Swift's witness tables is *different* from full Swift:
38
+
39
+
- The first word is always a null pointer (TODO: it can be eliminated)
40
+
- The following words are witness table entries which can be one of the following:
41
+
- A method witness: a pointer to the witness function.
42
+
- An associated conformance witness: a pointer to the witness table of the associated conformance
43
+
44
+
Note that witness tables in Embedded Swift do not contain associated type entries.
45
+
46
+
Witness functions are always specialized for concrete types. This also means that parameters and return values are passed directly (if possible).
47
+
31
48
## Heap object layout in Embedded Swift
32
49
33
50
Heap objects have the following layout in Embedded Swift:
0 commit comments