<div>Hi, Alex, and thank you so much for such a throroughly reply!<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div><div>The "Builtin" comes from a number of different places, e.g.:<br></div><div><br></div><div><a class="" href="https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def">https://github.com/apple/swift/blob/master/include/swift/AST/Builtins.def</a><br></div><div><a class="" href="https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp">https://github.com/apple/swift/blob/master/lib/AST/Builtins.cpp</a>&nbsp;<br></div><div><br></div><div>They aren't directly implemented in LLVM IR as such, but rather the parser replaces uses of Builtin.Word with the appropriate type via&nbsp;SILType::getBuiltinWordType and&nbsp;BuiltinIntegerType::getWordType.<br></div><div><br></div><div>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.)<br></div></div></blockquote><div><br></div><div>It looks I was mistaken then. Thanks for the clarification.<br></div><div><br></div><blockquote class="protonmail_quote" type="cite"><div><div>The SwiftShims are a set of additional functions that allow C functions to be exposed as platform-independent Swift functions:<br></div><div><br></div><div><a class="" href="https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims">https://github.com/apple/swift/tree/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims</a><br></div><div><br></div><div><a class="" href="https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h">https://github.com/apple/swift/blob/9354a93b1861efe14c4a72fd581c746b48334ccc/stdlib/public/SwiftShims/LibcShims.h</a>&nbsp;<br></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="protonmail_quote" type="cite"><div><blockquote class="" type="cite"><div class=""><div class="">2) Are you aware of any project out there that aims to minimize, or at least make more consistent (...)<br></div></div></blockquote></div><div class="">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.<br></div><div class=""><br></div><div class="">Alex<br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Thanks again!<br></div><div><br></div><div>David</div>