Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[Slava Pestov via swift-users]

> On Aug 15, 2016, at 3:36 PM, Rick Mann  wrote:
> 
> Well, even C++ requires some amount of run time. On a larger MCU, the runtime 
> shouldn't be a problem at all. What I want to do is minimize the amount of OS 
> I have to implement. For example, using newlib 
> (https://sourceware.org/newlib/ ), I can stub 
> out 20-odd functions, and everything gets statically linked into a monolithic 
> block of code that is a combination of my code, the runtime, and those 20-odd 
> function stubs. A special chunk of code, usually containing assembly 
> language, ensures the processor and MMU are properly set up just after boot, 
> and you're off to the races.
> 
> I imagine there will be additional burden to support threading and GCD (which 
> would be nice to have). But before that, supporting synchronization and 
> interrupt routines.
> 
> Ah, interrupt routines. Is there any way to mark a function as "naked" in 
> Swift? How would I request that feature?

This would require significant design work. The main problem is that the Swift 
runtime is not re-entrant, because typical malloc() implementations are not 
re-entrant, and also because of how metadata caching uses locks. So even if you 
could emit a function with the right calling convention, it wouldn't be safe to 
use as an interrupt handler.

Slava

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

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[David Sweeris via swift-users]

I don't know what you mean by "naked function", but you'd request it by 
starting a thread on swift evolution (which I would encourage you to do).

- Dave Sweeris

> On Aug 15, 2016, at 17:36, Rick Mann  wrote:
> 
> Well, even C++ requires some amount of run time. On a larger MCU, the runtime 
> shouldn't be a problem at all. What I want to do is minimize the amount of OS 
> I have to implement. For example, using newlib 
> (https://sourceware.org/newlib/), I can stub out 20-odd functions, and 
> everything gets statically linked into a monolithic block of code that is a 
> combination of my code, the runtime, and those 20-odd function stubs. A 
> special chunk of code, usually containing assembly language, ensures the 
> processor and MMU are properly set up just after boot, and you're off to the 
> races.
> 
> I imagine there will be additional burden to support threading and GCD (which 
> would be nice to have). But before that, supporting synchronization and 
> interrupt routines.
> 
> Ah, interrupt routines. Is there any way to mark a function as "naked" in 
> Swift? How would I request that feature?
> 
>> On Aug 11, 2016, at 21:46 , Slava Pestov  wrote:
>> 
>> 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 
>>>  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 
  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
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
___
swift-users mailing list
swift-users@swift.org

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[Rick Mann via swift-users]

Well, even C++ requires some amount of run time. On a larger MCU, the runtime 
shouldn't be a problem at all. What I want to do is minimize the amount of OS I 
have to implement. For example, using newlib (https://sourceware.org/newlib/), 
I can stub out 20-odd functions, and everything gets statically linked into a 
monolithic block of code that is a combination of my code, the runtime, and 
those 20-odd function stubs. A special chunk of code, usually containing 
assembly language, ensures the processor and MMU are properly set up just after 
boot, and you're off to the races.

I imagine there will be additional burden to support threading and GCD (which 
would be nice to have). But before that, supporting synchronization and 
interrupt routines.

Ah, interrupt routines. Is there any way to mark a function as "naked" in 
Swift? How would I request that feature?

> On Aug 11, 2016, at 21:46 , Slava Pestov  wrote:
> 
> 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 
>>  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  
>>> 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
> 


-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[Slava Pestov via swift-users]

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

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[Rick Mann via swift-users]

> On Aug 10, 2016, at 09:31 , Jens Alfke  wrote:
> 
> If you’re going for something bigger than that, why not just use a Raspberry 
> Pi or C.H.I.P. or one of the other tiny ARM PC boards? They all run Linux, 
> and I believe people are already working on porting Swift to run on those. 
> C.H.I.P. costs $9, and I saw a blurb somewhere about a competitor that’s only 
> $5.

Well, that doesn't work for custom hardware, and importantly, I don't want to 
run Linux. It's very hard to make a fast-booting device with Linux.



-- 
Rick Mann
rm...@latencyzero.com


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

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[Saagar Jha via swift-users]

Sent from my iPhone

> On Aug 10, 2016, at 08:31, Jens Alfke via swift-users  
> wrote:
> 
> 
>> On Aug 9, 2016, at 1:10 PM, Rick Mann via swift-users 
>>  wrote:
>> 
>> 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).
> 
> I have never seen the Swift source code, but I’d be surprised if Swift 
> binaries didn’t require at least the standard C runtime library. (It’s pretty 
> hard to get anything done without at least having malloc/free!)
> 
> Don’t forget that the binary will have to include the implementations of the 
> standard Swift library classes, at least the ones used by your program. I’m 
> sure String in particular is a significant chunk of code, since it has to do 
> all kinds of Unicode stuff. (In fact it might have a dependency on ICU, which 
> is a pretty hefty C library.)
> 
>> 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.).
> 
> Arduinos are probably right out, since there’s no way anyone’s going to port 
> Swift to an 8-bit CPU!
> 
> If you’re going for something bigger than that, why not just use a Raspberry 
> Pi or C.H.I.P. or one of the other tiny ARM PC boards? They all run Linux, 
> and I believe people are already working on porting Swift to run on those.

Minor correction: Swift already builds and runs on the Raspberry Pi :)

> C.H.I.P. costs $9, and I saw a blurb somewhere about a competitor that’s only 
> $5.
> 
> —Jens
> ___
> 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

Re: [swift-users] Swift in bare-metal embedded programming/Swift runtime

[David Sweeris via swift-users]

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  
> 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] Swift in bare-metal embedded programming/Swift runtime

[Rick Mann via swift-users]

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