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

[Alex Blewitt via swift-dev]

> On 6 Sep 2017, at 10:26, blaster_in_black via swift-dev  
> wrote:
> 
> 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
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[blaster_in_black via swift-dev]

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___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

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

[Alex Blewitt via swift-dev]

> On 6 Sep 2017, at 11:29, blaster_in_black via swift-dev  
> wrote:
> 
> 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 :)

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
___
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev