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 <rm...@latencyzero.com> 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 <spes...@apple.com> 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 >>> <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 > > > -- > Rick Mann > rm...@latencyzero.com > > _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
