[swift-dev] how much of non-Swift in Swif

blaster_in_black blaster_in_black at protonmail.com
Wed Sep 6 05:29:40 CDT 2017


Hi, Alex, and thank you so much for such a throroughly reply!

> The "Builtin" comes from a number of different places, e.g.:
>
> https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def
> https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp
>
> They aren't directly implemented in LLVM IR as such, but rather the parser replaces uses of Builtin.Word with the appropriate type via SILType::getBuiltinWordType and BuiltinIntegerType::getWordType.
>
> Normally these aren't accessible to Swift programs, but if you compile with -parse-stdlib you can see what effect it has on the generated output. Looking at the -emit-sil is an interesting way of seeing what is produced. (You can also use a GUI tool I wrote called SILInspector, which runs the commands and hosts them in a text field for ease of use.)

It looks I was mistaken then. Thanks for the clarification.

> The SwiftShims are a set of additional functions that allow C functions to be exposed as platform-independent Swift functions:
>
> https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims
>
> https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h

I get it. Again, I was getting only part of the picture here. I thought LibcShims was not intended for that purpose but just "happened" to be implemented in C more than not.

>> 2) Are you aware of any project out there that aims to minimize, or at least make more consistent (...)
>
> I'm not sure what question you are asking here. If you are asking "Is there a desire or goal to move away from C based functions into Swift functions" then the answer is likely to be no; some of the functions need to be implemented in C because they are platform specific or use e.g. C++ like namespaces, and the bulk of the compiler and intrinsics are written in C++ already.
>
> Alex

I was partially mistaken. Before your clarifications above, I was wrongly perceiving what seemed like a lot of "embedded C code" here and there, and so I was wondering whether in the future that would be somehow taken together into a one central C/C++ external library or runtime (e.g. into a BuiltIn-like class or some other). But I see now there is no such lack of consistency, so my question is not valid anymore.

Abusing your good will, let me ask you yet another question. I understand, as you've pointed out, that certain parts of functionality shall always be implemented in low-level language with direct access to syscalls, such as C/C++. Are you able to suggest me a way to find all, or at least most of those parts? I'd like to estimate what they represent - what they build and provide on top of syscalls and libc.

Thanks again!

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170906/d93f0c63/attachment.html>


More information about the swift-dev mailing list