Even if you take care not to create class instances, the compiler emits many 
calls to runtime functions to implement features such as generics, casts and 
existentials. It is possible to write code where a large number of runtime 
calls are optimized away, but I don’t think they can be eliminated completely.

If anyone is interested in taking this on as a community project, it would be a 
fair amount of work, but I think the first step could be to add compiler flags 
where calls to runtime functions become diagnostics. Again though, I’m not sure 
how much effort it would take to eliminate them completely.

Slava

> On Aug 10, 2016, at 3:28 AM, David Sweeris via swift-users 
> <swift-users@swift.org> wrote:
> 
> There's definitely a runtime, but I *think* you can avoid actually using it 
> by being very careful with your data structures. ARC means that classes 
> obviously trigger it, and I think it *might* be involved resizing arrays and 
> strings (they do some tricks behind the scenes, but I can't remember what).
> 
> So... only use structs and don't resize anything? I'm not sure... I think 
> there might be some cases where protocols or indirect enums get stored as 
> references, and that might involve the runtime as well.
> 
> Maybe you should go over to the evolution list and suggest a "no runtime" 
> compiler flag or source code annotation, which disallows anything which would 
> use the runtime. I believe there could be advantages outside of running on 
> bare-metal, since you could use it to get the compiler to yell at you for 
> doing overhead-inducing stuff in a loop, for example. 
> 
> Anyway, best of luck :-)
> 
> - Dave Sweeris
> 
>> On Aug 9, 2016, at 15:10, Rick Mann via swift-users <swift-users@swift.org> 
>> wrote:
>> 
>> Is it possible to use Swift for bare-metal programming on embedded devices? 
>> These devices usually have memory-mapped registers that are read and written 
>> to affect the operation of the device. Some can be quite small (e.g. 8-bit 
>> registers, simple single physical memory address space), and others quite 
>> robust (full 32- or 64-bit machines with MMUs, etc.).
>> 
>> But bare metal development for all of them starts with emitting code with 
>> "raw" packaging (no Mach or ELF headers, etc.), and the ability to read and 
>> write specific memory addresses.
>> 
>> For the smaller devices, runtime library overhead is a concern (mostly due 
>> to code size). Is it possible to write swift code with no runtime library? I 
>> think this is possible in Rust (came up on another list).
>> 
>> Most such development is done in C, and there is always some form of library 
>> to take on some of the standard library tasks and stub out basic IO, as well 
>> as filling in gaps for larger variable sizes not directly supported by the 
>> hardware.
>> 
>> I imagine there's some runtime support for ARC, although maybe that's 
>> handled entirely in the compilation phase?
>> 
>> Anyway, I'd appreciate someone more knowledgable letting me know if this is 
>> something I should experiment with. Thanks!
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
>> 
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
> _______________________________________________
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Reply via email to