how much of non-Swift in Swif

Hi Swift developers,

nice to meet you all in this list.
While having a look at Swift's source code, I am not able to really answer myself two questions:

1) How much and what types of interfaces with non-Swift code is there in the standard library and the runtime? I have seen references to the "Builtin" class, that as I understand is directly implemented in LLVM IR language, and also calls to C++ functions ("SwiftShims" is full of that). Is there any more "boundary" with non-Swift parts of the implementation?
2) Are you aware of any project out there that aims to minimize, or at least make more consistent, the amount of references to non-Swift functions and types in the standard library? I know about Pure Swift's "SwiftFoundation" and other artifacts of them, but as far as I know they do not dig into the standard library.

Thanking you in advance for the answers!

Cheers,

David

1) How much and what types of interfaces with non-Swift code is there in the standard library and the runtime? I have seen references to the "Builtin" class, that as I understand is directly implemented in LLVM IR language, and also calls to C++ functions ("SwiftShims" is full of that). Is there any more "boundary" with non-Swift parts of the implementation?

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.)

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

2) Are you aware of any project out there that aims to minimize, or at least make more consistent, the amount of references to non-Swift functions and types in the standard library? I know about Pure Swift's "SwiftFoundation" and other artifacts of them, but as far as I know they do not dig into the standard library.

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.

Foundation, on the other hand, has a number of C functions that have been inherited from the Darwin codebase, which has a collection of C underlying concepts and then higher level wrappers. While it would be technically possible to rewrite working code with other working code, the focus has been on filling out the gaps in places where there isn't working code at the moment. In addition, it's generally unproductive to rewrite working and tested code with new code unless there's a specific reason (speed, portability, security) to do so.

Alex

···

On 6 Sep 2017, at 10:26, blaster_in_black via swift-dev <swift-dev@swift.org> wrote:

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

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

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.

Well, one way would be to clone the https://github.com/apple/swift/ repository and then find out any files which end in .c or .cpp :slight_smile:

The problem is that there's a lot of stuff there, which means it's difficult to answer your question directly. In addition, Swift builds upon other libraries - for example, using ICU to perform the Unicode boundaries - and it's not clear where you want to draw the line.

Most of the Swift infrastructure is built upon LLVM - in fact, the Swift REPL is really just an extra set of runtime functions on top of the existing LLVM/LLDB type repls (you can switch into LLDB using : in a Swift interpreter, and back to Swift with repl). LLDB in turn has Python embedded within which you can run with 'script':

$ swift
Welcome to Apple Swift version 4.0-dev (LLVM f53eb03c15, Clang 1757394ff0, Swift 75b7e05e20). Type :help for assistance.
  1> :
(lldb) script
Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D.

print("Hello from Python in LLDB in Swift")

Hello from Python in LLDB in Swift

I'm not sure what kind of 'syscalls' and 'libc' you are looking for, but you can use various tracing programs (e.g. strace, dtrace) to find out where they are being called directly, or you could run it under lldb and set various breakpoints to do the same.

Finally, the resulting executable generated by a Swift compiler consists of a number of parts; information generated by the compiler and optimiser phases, calls out to external libraries (like libc or libicu), as well as calls to runtime functionality used by the Swift runtime, such as memory allocation and reference counting. There isn't a clear delineation of where those come from, so unless you want to get a little bit more specific about what you're hoping to find, you're probably best just spelunking through the codebase.

Alex

···

On 6 Sep 2017, at 11:29, blaster_in_black via swift-dev <swift-dev@swift.org> wrote: