Skip to content

Commit 633d6a1

Browse files
rauhulDougGregorshahmishalheckjdavelester
authored
Add Embedded Swift update blog post (#1236)
Adds a what's new in embedded swift in swift 6.3 blog post. --------- Co-authored-by: Doug Gregor <[email protected]> Co-authored-by: Mishal Shah <[email protected]> Co-authored-by: Joseph Heck <[email protected]> Co-authored-by: Dave Lester <[email protected]>
1 parent 6cada21 commit 633d6a1

File tree

2 files changed

+222
-0
lines changed

2 files changed

+222
-0
lines changed

‎_data/authors.yml‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -602,3 +602,8 @@ davelester:
602602
github: davelester
603603
gravatar: "376decb8be2d1c50df06daf50ef3b6b5"
604604
about: "Dave Lester is a Senior Product Manager at Apple and member of the Swift website workgroup."
605+
606+
doug_gregor:
607+
name: Doug Gregor
608+
github: DougGregor
609+
about: "Doug Gregor is a member of the Language Steering Group and works on the Swift compiler and runtime."

‎_posts/2025-11-17-embedded-swift-improvements-coming-in-swift-6.3.md‎

Lines changed: 217 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,217 @@
1+
---
2+
layout: new-layouts/post
3+
published: true
4+
date: 2025-11-17 12:00:00
5+
title: "Embedded Swift Improvements Coming in Swift 6.3"
6+
author: [doug_gregor, rauhul]
7+
category: "Language"
8+
---
9+
10+
[Embedded Swift](/get-started/embedded/) is a subset of Swift that’s designed for low resource usage, making it capable of running on constrained environments like microcontrollers. Using a special compilation mode, Embedded Swift produces significantly smaller binaries than regular Swift. While a subset of the full language, the vast majority of the Swift language works exactly the same in Embedded Swift. Additional information is described in the [Embedded Swift vision document](https://github.com/swiftlang/swift-evolution/blob/main/visions/embedded-swift.md).
11+
12+
Embedded Swift is evolving rapidly. This post describes a number of improvements made in the last few months, covering everything from improved C interoperability to better debugging and steps toward a complete linkage model for Embedded Swift.
13+
These features and bug fixes are included in the upcoming [Swift 6.3](https://forums.swift.org/t/swift-6-3-release-process/82843) release, and you can try them out today with a [Swift development snapshot](https://www.swift.org/install/).
14+
15+
## Libraries and Diagnostics
16+
17+
### Printing floating point numbers
18+
19+
Previously, the `description` and `debugDescription` properties for floating-point types (`Float`, `Double`, etc.) were not available in the Embedded Swift standard library. With a new [all-Swift implementation](https://github.com/swiftlang/swift/pull/84826), you can now use these with Embedded Swift.
20+
21+
### Embedded restriction diagnostics
22+
23+
There is a new opt-in set of warnings in the [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions) diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as uses of untyped throws or calling generic functions on existential values.
24+
These diagnostics are enabled by default when building Embedded Swift, and can also be enabled in non-Embedded Swift using the compiler flag `-Wwarning EmbeddedRestrictions` or in the package manifest with:
25+
26+
```swift
27+
swiftSettings: [
28+
.treatWarning("EmbeddedRestrictions", as: .warning),
29+
]
30+
```
31+
32+
Read the full details at [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions).
33+
34+
### Swift MMIO 0.1.x
35+
36+
The [0.1.x release](https://github.com/apple/swift-mmio/releases/tag/0.1.0) of Swift MMIO, a package for memory-mapped I/O, includes many bug fixes and quality-of-life improvements, plus newly written comprehensive [documentation](https://swiftpackageindex.com/apple/swift-mmio/documentation/mmio) on the Swift Package Index.
37+
38+
The biggest addition is code generation support. There's now an [svd2swift tool](https://swiftpackageindex.com/apple/swift-mmio/documentation/svd2swift) and corresponding [SwiftPM plugin](https://swiftpackageindex.com/apple/swift-mmio/documentation/svd2swift/usingsvd2swiftplugin) that generates Swift MMIO interfaces directly from CMSIS System View Description (SVD) files. You can run it manually from the command line, or configure the plugin to handle everything automatically at build time.
39+
40+
Debugging also got a nice upgrade with [SVD2LLDB](https://swiftpackageindex.com/apple/swift-mmio/documentation/svd2lldb).
41+
This LLDB plugin lets you work with device registers using their actual names instead of fumbling with the raw memory addresses.
42+
It even includes visual decoding support to help you make sense of register values.
43+
For example, here's what it looks like when you decode a hypothetical timer control register:
44+
45+
```swift
46+
(lldb) svd decode TIMER0.CR 0x0123_4567 --visual
47+
TIMER0.CR: 0x0123_4567
48+
49+
╭╴CNTSRC ╭╴RST
50+
╭╴S ╭╴RELOAD╭╴CAPEDGE ╭╴MODE
51+
┴ ┴─ ┴─ ┴─── ┴── ┴
52+
0b00000001001000110100010101100111
53+
┬─ ┬─ ┬─── ┬ ┬─ ┬
54+
╰╴IDR ╰╴TRGEXT ╰╴PSC ╰╴EN
55+
╰╴CAPSRC ╰╴CNT
56+
57+
[31:31] S 0x0 (STOP)
58+
[27:26] IDR 0x0 (KEEP)
59+
[25:24] RELOAD 0x1 (RELOAD1)
60+
[21:20] TRGEXT 0x2 (DMA2)
61+
[17:16] CAPEDGE 0x3
62+
[15:12] CAPSRC 0x4 (GPIOA_3)
63+
[11:8] CNTSRC 0x5 (CAP_SRC_div32)
64+
[7:7] PSC 0x0 (Disabled)
65+
[6:4] MODE 0x6
66+
[3:2] CNT 0x1 (Count_DOWN)
67+
[1:1] RST 0x1 (Reset_Timer)
68+
[0:0] EN 0x1 (Enable)
69+
```
70+
71+
## C Interoperability
72+
73+
### `@c` functions and enums
74+
75+
The Swift evolution proposal [SE-0495](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0495-cdecl.md) provides support for defining C-compatible functions and enums with the `@c` attribute. For example, the following declaration defines a function that is callable from C with the name `MyLib_initialize`:
76+
77+
```swift
78+
@c(MyLib_initialize)
79+
public func initialize() { ... }
80+
```
81+
82+
The Swift generated header from the above example, which can be included in any C/C++ code, contains a declaration of this C function:
83+
84+
```c
85+
void MyLib_initialize(void);
86+
```
87+
88+
This feature also works with the `@implementation` attribute introduced in [SE-0436](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0436-objc-implementation.md). If you have a pre-existing C header that documents a C interface, you can implement that C interface with a Swift function such as:
89+
90+
```swift
91+
@c @implementation
92+
public func MyLib_initialize() { ... }
93+
```
94+
95+
The Swift compiler ensures that the signature of the Swift function matches that of the C header. This allows you to replace an existing C library with a Swift implementation without affecting C clients.
96+
97+
The `@c` attribute formalizes the `@_cdecl` attribute, fixing a number of corner cases in the process.
98+
99+
### Improved tolerance of mismatching C signatures
100+
101+
The Swift compiler has historically required precise consistency between the Swift types for C functions imported from headers or declared in Swift with `@c` (formerly `@_cdecl`) or `@_extern(c)`. For example, if you declared a C function without nullability annotations in a header:
102+
103+
```c
104+
void takePointer(const double *);
105+
```
106+
107+
And then separately defined in Swift with, for example:
108+
109+
```swift
110+
@c func takePointer(_ values: UnsafePointer<Double>) { ... }
111+
```
112+
113+
The compiler could fail to compile when it noticed the mismatch, often with a hard-to-understand “deserialization” failure. The compiler now keeps the different views on the underlying C declaration separate, diagnosing problems when the underlying C declarations themselves are inconsistent. This allows subtle differences such as nullability or sendability annotations to occur in C signatures without failing to compile.
114+
115+
## Debugging
116+
117+
### Debugger printing of values
118+
119+
LLDB’s support for printing the values of Swift types in Embedded Swift has been improved. In addition, the `memory read` command now supports an optional Swift type name, so that you can take an arbitrary address and render it as a value of that named Swift type.
120+
The following example shows interpreting the address as the type `MyMessage`:
121+
122+
```swift
123+
(lldb) memory read -t MyMessage 0x000000016fdfe970
124+
(MessageLib.MyMessage) 0x16fdfe970 = {
125+
id = 15
126+
timestamp = 793219406
127+
payload = "hello"
128+
...
129+
}
130+
```
131+
132+
### More data types inspectable in core dumps
133+
134+
LLDB needs access to type layout information so it can display variables. Since Embedded Swift doesn't contain reflection metadata, the Swift compiler emits all the type layout information as DWARF debug info.
135+
There have been several improvements to the Swift compiler's debug info output, such as support for type declarations nested inside an extension.
136+
At the same time, LLDB added support for nested generic type aliases in Embedded Swift.
137+
These two improvements together make it possible to inspect many common standard library data types, such as `Dictionary` and `Array`, in Embedded Swift core dumps.
138+
Previously these data types were only accessible via the expression evaluator, which requires a live process.
139+
140+
LLDB also has native support for the new `InlineArray` data type.
141+
142+
### Debugger armv7m exception frames unwinding
143+
144+
LLDB's support for producing backtraces after taking exceptions in armv7m has been greatly improved. Previously after taking an exception, you would be presented with a back trace like the following:
145+
146+
```swift
147+
(lldb) bt
148+
* thread 1
149+
* frame #0: 0x0020392c NeoPixelRainbow`NeoPixelRainbow.swift_UsageFault_Handler() -> () + 28
150+
frame #1: 0x00203910 NeoPixelRainbow`UsageFault_Handler + 8
151+
frame #2: 0xfffffff8
152+
frame #3: 0x00202a86 NeoPixelRainbow`NeoPixelRainbow_main + 8
153+
frame #4: 0x00200256 NeoPixelRainbow`cinit_ctor_loop_end at startup.S:98
154+
frame #5: 0x00200210 NeoPixelRainbow`Reset_Handler at startup.S:33
155+
```
156+
157+
However this back trace would often be missing one or more frames before the start of the exception frame (`UsageFault_Handler` above).
158+
159+
Now, LLDB is able to walk back through exception frames into the standard program frames and produce a backtrace that contains the missing frames.
160+
161+
```swift
162+
(lldb) bt
163+
* thread #1
164+
* frame #0: 0x0020392c NeoPixelRainbow`swift_UsageFault_Handler() + 28
165+
frame #1: 0x00203910 NeoPixelRainbow`swift_UsageFault_Handler()
166+
frame #2: 0x00203366 NeoPixelRainbow`static Application.main() + 2270 // Real exception location
167+
frame #3: 0x00202a86 NeoPixelRainbow`NeoPixelRainbow_main + 8
168+
frame #4: 0x00200256 NeoPixelRainbow`cinit_ctor_loop_end + 18
169+
frame #5: 0x00200210 NeoPixelRainbow`Reset_Handler + 16
170+
```
171+
172+
## Linking
173+
174+
### `@section` and `@used` attributes
175+
176+
The Swift evolution proposal [SE-0492](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0492-section-control.md) introduced two new attributes that are useful in Embedded Swift. The `@section` attribute specifies that a particular global variable should be emitted into the named section:
177+
178+
```swift
179+
@section("__DATA,mysection")
180+
@used
181+
let myLinkerSetEntry: Int = 42
182+
```
183+
184+
Also included is an `objectFormat` check that can be used within `#if` to conditionalize code on the various object formats (ELF, COFF, MachO, Wasm), that you can use to provide different section names:
185+
186+
```swift
187+
#if objectFormat(ELF)
188+
@section("mysection")
189+
#elseif objectFormat(MachO)
190+
@section("__DATA,mysection")
191+
#endif
192+
var global = ...
193+
```
194+
195+
The `@used` attribute lets the compiler know that the entity it’s attached to should always be emitted, even if it appears unused.
196+
197+
### Progress on the Embedded Swift linkage model
198+
199+
Embedded Swift uses a different compilation model from regular Swift that delays code generation to later in the compilation process. This compilation model has not been fully defined and has various practical problems. One such issue involves duplicate symbols: if you have four Embedded Swift libraries whose dependencies form a diamond, like this:
200+
201+
```
202+
A
203+
/ \
204+
B C
205+
\ /
206+
D
207+
```
208+
209+
Then symbols from `A` that are used in both `B` and `C` would cause duplicate definition errors when linking both into `D`. The Swift compiler now emits symbols from imported modules using weak definitions, so the linker can de-duplicate them. This eliminates the need for flags like `-mergeable-symbols` and `-emit-empty-object-file` that provided partial workarounds.
210+
211+
Another step along the path to formalizing the Embedded Swift linkage model is [SE-0497](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0497-definition-visibility.md), which defines a new `@export` attribute that controls how a function is visible to clients. The spelling `@export(implementation)` makes the implementation available for clients to emit, specialize, or inline, subsuming the longstanding but unofficial `@_alwaysEmitIntoClient` attribute. The spelling `@export(interface)` ensures that only the interface and *not* the definition of the function is made available to clients by emitting a callable symbol, allowing library developers to fully hide the implementation of a function even in Embedded Swift.
212+
213+
## Try it out!
214+
215+
Embedded Swift support is available in the [Swift development snapshots](/install/). The best way to get started is through the examples in the [Swift Embedded Examples](https://github.com/swiftlang/swift-embedded-examples) repository, which contains a number of sample projects to get Embedded Swift code building and running on various hardware.
216+
217+
If you have questions about the improvements described here, or want to discuss your own Embedded Swift work, we encourage you to join the conversation on the Swift forums. You can ask about this post in the [associated thread](https://forums.swift.org/t/embedded-swift-improvements-coming-in-swift-6-3/83268), and share your experiences in the [Embedded Swift category](https://forums.swift.org/c/platform/embedded/).

0 commit comments

Comments
 (0)