Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Winding down the Swift 3 release

thread.gmane.org

Post reply on HN
Print view View original

61–65 of 65 posts

Re: Winding down the Swift 3 release

#61

Post by whistler »

pjmlp wrote: post #57
the_why_of_y wrote: post #54

Earlier quoted context omitted.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels. http://www.iso-9899.info/n1570.html#4.p6

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios. Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change. If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

It is possible but the Swift stdlib does rely on a minimal set of libc functions including malloc()/free() and the usual str* and mem* functions. Some of the other functionality can be removed eg the math and floating point but even implementing malloc() in Swift would be hard because any data structures that get used eg Arrays will themselves rely on malloc(), and even if you wrote it using UnsafeMutablePointer it would not be much different to a C implentation. Also the globalinit functions that get called at startup themselves rely on malloc() so it ends up being circular.

However if you are willing to accept some functionality will be written in C it is possible to run Swift directly on bare metal.

Re: Winding down the Swift 3 release

#62

Post by pjmlp »

whistler wrote: post #61
pjmlp wrote: post #57

Earlier quoted context omitted.

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios. Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change. If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

It is possible but the Swift stdlib does rely on a minimal set of libc functions including malloc()/free() and the usual str* and mem* functions. Some of the other functionality can be removed eg the math and floating point but even implementing malloc() in Swift would be hard because any data structures that get used eg Arrays will themselves rely on malloc(), and even if you wrote it using UnsafeMutablePointer it w…

> However if you are willing to accept some functionality will be written in C it is possible to run Swift directly on bare metal.

I would rather use Assembly or compiler intrinsics instead, just like many C alternatives, some much older like NEWP, do.

Also many of the C library calls are impossible to implement in pure ANSI C without language extensions or Assembly, malloc() and free() being two of them.

Re: Winding down the Swift 3 release

#63

Post by nardi »

pjmlp wrote: post #60
nardi wrote: post #58

Earlier quoted context omitted.

What I think you're missing is that using a runtime is impossible in an OS kernel, unless the runtime doesn't use any OS features. You at least need to bootstrap enough of an OS before you can use the runtime. It's not the same thing as kexts or IOKit modules.

It is so impossible that history of computing is full of such examples, but the C community likes to re-write history so thay younger generations don't feel the need to dive into ACM papers about how the world was outside AT&T walls.

Sincerely: I would love to learn about one or more of these. Do you have any links to papers?

Re: Winding down the Swift 3 release

#64

Post by whistler »

the_why_of_y wrote: post #59
pjmlp wrote: post #57

Earlier quoted context omitted.

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios. Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change. If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

Could be, I wouldn't rule it out, but if so I've got serious doubts that it would be the full Swift language - the Objective-C style "dynamic" dispatch seems rather inappropriate for kernel space.

I agree that dynamic dispatch is not suitable for a kernel however if you compile Swift on a linux host then there is no ObjC runtime support anyway so its not an issue. However I would still see it as the full Swift language
Post reply on HN