-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[embedded] Add a simple Swift runtime, written in embedded Swift #68735
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
f7d7134
to
179136f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:-) Very nice. Looking forward to the day when we can migrate the main runtime to Swift too.
4f414f6
to
5865fd8
Compare
… fix the driver to avoid linking compat libraries
5865fd8
to
cf1d19e
Compare
@swift-ci please test |
@swift-ci please test |
} | ||
|
||
@_cdecl("swift_slowDealloc") | ||
public func swift_slowDealloc(_ ptr: UnsafeMutableRawPointer?, _ size: Int, _ alignMask: Int) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you going to add the DO_NOT_FREE_BIT here, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it should go here...? I thought swift_slowDealloc is not used on refcounted objects, and only used to implement things like UnsafePointer.deallocate(). This matches how swift_slowDealloc is implemented in the main runtime (no checking of anything, just a direct call to free).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry, I meant to add this comment for swift_deallocClassInstance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aha, then yes -- let me do that as a follow-up in https://github.com/apple/swift/pull/68754/files, I'll rebase it on top of this Swift runtime.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very cool!
@@ -0,0 +1,132 @@ | |||
//===----------------------------------------------------------------------===// |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super cool that you can just put this into the stdlib!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is super awesome to see!
This PR adds a mini Swift runtime to be used in embedded Swift to support heap allocations and deallocations of reference types (classes), reference counting of those, and lazy initialization of global and static variables (swift_once). The runtime is an alternative implementation, separate from the main Swift runtime, and it's entirely written in embedded Swift (!). The initial version is only suitable for strictly single-threaded use (plan is to fix that soon).
The PR also introduces a slightly different model of distribution and use of this runtime (compared to libswiftCore.a/libswiftCore.dylib on mainstream OS's) -- it's bundled into the embedded standard library module, with the expectation that dead-code elimination is going to take care of any unused runtime functionality. To make this work, SILLinker needs to explicitly bring the runtime functions in when building client code (otherwise the functions appear unused at the SIL level). The result is that a single WMO compiler invocation of an embedded Swift app/firmware is going to produce a standalone binary with the necessary runtime support already included, no need to link any extra libraries:
The added
embedded/runtime.swift
test demonstrates that.