You might not have a kernel for the syscall. I imagine print should be something that will be easy to add back though.
That is just on the most embedded version of Embedded Swift.
1 Like
Is there a real prototype of this somewhere or are the images just mockups?
I would add that "print" in embedded systems is frequently a sub call of a serial library or similar, so that's where it would be best added back in.
4 Likes
It is not clear to me, why
This is something I think we should really think about as part of the Embedded Swift movement. IMO Rust does this pretty well, with a distinction between std and core, and allowing you to substitute in pieces of std, allowing you then to access more and more abstractions on top of the pieces of std that you've replaced. Implement an allocator? Nice, you get fmt!().
12 Likes
There is a prototype, the images/videos are real, and we plan to add the functionality of the prototype under experimental flags into the compiler soon, so that it's available for early experimental use.
9 Likes
You can send the output to a particular stream. I use it for stderr. Some embedded platforms I’ve worked with had printf that would do nothing unless you provide your implementation. But the program would compile.
Yes, but fixed size Arrays are essentail for precisely those usecases where malloc is missing imo.
1 Like
It is not clear to me, why
There's no intention to remove print(), the vision document just states that we have to provide some alternative implementation (compared to what's in the stdlib today); and your suggestion is one possible option for that, yes.
9 Likes
One interesting intersection is where the artifact bundle definitions of sdks can interplay here. I could imagine that the definition could ferry along information of what type of restrictions are made. E.g. some restricted environments may not have malloc, but others may have full-on concurrency support. Targeting AVR wouldn't be able to have nearly as much available to it as say targeting ESP32-S3/H2.
This may need some alteration linguistically to support additional parameters to #if style guards (or something to that effect). A low level interface to bare metal systems is definitely useful, but it would also be interesting to consider what a more user-welcoming library space would look like too (not just the stdlib).
I see three layers of experiences that could be tackled here: platform engineering (folks bringing in new chips/boards etc), library engineering (folks building out the standard library or other under-pinning libraries for smol swift), and end use engineering (folks building products for that hardware). Each of those audiences have distinct needs, and there likely are tunings that can be focused on each of them.
To be honest - if done well this could be really exciting for many developers - not just large projects but to maker level projects too!
9 Likes
- The types of thrown errors will be restricted in some manner, because thrown errors are of existential type
any Error(which is disallowed by the prior item).
Sounds like this has Typed throws as a prerequisite?
#if os(Darwin), a shorthand for checking for Darwin platforms also seems relevant re. the need in Embedded Swift for # if checks against more complicated environment possibilities.
Not necessarily. There are other restrictions we could possibly place on errors that allow them to be propagated without requiring the full expressivity of general existentials. Typed throws might be a good feature in and of itself, but requiring its use in embedded Swift could be a pretty severe dialectization wedge. Our guidance for long-term stable APIs will likely still be to recommend untyped errors to allow for library evolution, and we'd want libraries that intend to target both desktop and embedded Swift to follow that guidance without having to diverge their APIs.
12 Likes
My 2 cents is that I'm perfectly willing to trade almost any language feature to squeeze onto a smaller chip... something Raspberry Pico / RP2040 size would be wicked. (ARM M0)
4 Likes
RP2040 is relatively powerful - to be honest I don't think many features really would have to be skipped.
7 Likes
That's wonderful but surprising news. Can I hear an ATtiny? (kidding, but honestly can't think of a single language feature I personally wouldn't be willing to give up to make it fit)
2 Likes
If one was really excited and wanted to reproduce the example the minute it was possible is this the board? https://www.st.com/en/evaluation-tools/32f746gdiscovery.html
Yup that's the one! In fact if you really really wanted to, you could build a custom stdlib for arm7em with the hermetic seal at link support @kubamracek mentions above, massage it into a swift sdk bundle and use swift package manager to recreate/build that demo.
swift build \
--configuration release \
-Xswiftc -target -Xswiftc armv7em-apple-none-macho \
-Xswiftc -experimental-hermetic-seal-at-link \
-Xswiftc -Xfrontend -Xswiftc -experimental-platform-c-calling-convention=arm_aapcs_vfp \
--experimental-swift-sdk stm32f746 \
--experimental-lto-mode full \
--static-swift-stdlib
Note: this would be the 500kb version of the demo firmware mentioned above.
9 Likes
I wanted to draw some attention to the significant efforts already made over at Swift for Arduino: https://www.swiftforarduino.com
They've already got some great progress in compiling small code. I believe the implementation is more the subset of the language idea mentioned earlier, but I've used it a little myself and was thoroughly impressed.
It would be great to have their efforts mainstreamed, for sure!
15 Likes
RP2040 is my favorite maker chip too. It is really fast, just need to keep the binary sizes and memory use small. I have a few of them sitting on my desk.
6 Likes
To clarify - this should work with which branch(s) of Swift? I'm getting error: Unknown option '--experimental-lto-mode' when I tried to build an empty package (just to see). Do I need a enableExperimentalFeature setting somewhere?
FWIW I also tried a little mini project and swiftc main.swift -o hello_swift_blink -lto=llvm-full -experimental-hermetic-seal-at-link works fine, but the target, xfrontend, and -static-stdlib all seem dependent on getting the sdk linked first (as would be expected).
swift-driver version: 1.87.1 Apple Swift version 5.9 (swiftlang-5.9.0.128.2 clang-1500.0.40.1)
Target: x86_64-apple-macosx14.0
This is all going to be really nice with the C++ interop...
Oops! I added the flag in this pr: BuildDescription: Set output path for bc files by rauhul · Pull Request #6611 · apple/swift-package-manager · GitHub but it has not been cherry picked into 5.9 so you will need to use a nightly toolchain until the spm change makes it into a release.
4 Likes
This is amazing! Thank you