Re: Bare-metal programming in D (was GSOC - Holiday Edition)
09-Jan-2015 05:07, Mike пишет: On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky wrote: Truth be told none of listed in this thread feel fundamental to me. It looks more like a set of patches to each specific problem in the compiler or run-time. Yeah, run-time would better be more customizable, but it's just our *current* run-time it's not the language. Perhaps high-impact would be a better word than fundamental. I think moving runtime hooks out of the compiler to .di files and Adam Ruppe's proposal to move TypeInfo to the runtime are great ideas. These are good. I expect more customization points to come as bare-metal stuff moves along. high-impact - I'm not sure I follow? Nobody would notice much except those messing with the compiler and custom run-times. The change itself might be a couple dozen of lines worth. I could understand horror that tweaking something in a compiler may instill but D's compiler is rapidly evolving. I see nothing fundamental in how it depends on run-time and vise-versa, everything is tweakable and we break binary compatibility (and not only that) with every release. Enhancement 11666 [1] is another. That really highlighted a design problem in the runtime for me. If the runtime had better separation of language, platform (OS and architecture) and library, the ports would simply have their own folder in the runtime rather than their own repository. The controversy that followed the pull requests in an attempt address 11666 clearly shows the problems that high coupling to the platform can cause. If the platform were encapsulated and decoupled from the language implementation, we'd already be well on our way. [1] - https://issues.dlang.org/show_bug.cgi?id=11666 This issue mostly affects embedded targets that run full-fledged OS. Somehow I see it as a minor issue. No matter how we pile up platform-specific headers - somebody got to put it somewhere. A couple of conventions were discussed with various drawbacks. Many C projects do this in ad-hoc fashion and survive just fine. There is no inherent design problem or something unfixable - we just need more ports. Also I'm thinking that bare-metal stuff would simply have its own run-time complying with some _spec_ of what compiler expects. Working out that spec and importantly language feature sets would be awesome. But I've been watching how such changes are perceived here, and I'm skeptical they would be accepted because so much in the language is potentially affected by them. We can just ask for them again and see. It's important to voice concerns because there is so much of stuff going on that some important issues may easily slip under radar. What usually works best in prioritizing stuff is highlighting that some actual project is having a problem with issue X, Y and Z. Due to the fact that they only benefit a few bare-metal folks, but impact the full language Again I'm not sure how? In fact nobody would notice a damn thing. Layout of internals of D run-time are just that. A toolkit will need to provide e.g build/fetch with a bootstrap script: - a ready to-go D cross-compiler(s) might be with some patches to disable language features for better experience etc. That's more-or-less what I've suggested in this thread. If that happened, I could get behind the items you listed below. But I don't know how to proceed with the compiler, that's not my interest nor within my current ability. Johannes has been exploring this territory, however, which is encouraging. Great. This helps me understand what is the main impediment at the moment. With that in mind I think we can formulate our GSOC plan better. As far as I can tell it can focus on 2 paths: a) Get embedded-savy student to work on MCU support and stuff while delegating most compiler tweaks to mentor(s) and core team. b) Get a student interested in compilers to deliver on getting robust cross-compiler with minimal run-time. Getting actual boards to work is then delegated to mentors. I am in favor of a). - a stripped run-time instead of Phobos (come on C/C++ folks use something much unlike standard library either) - linker scripts for a (growing) set of MCUs - I/O library and register definitions for MCUs (preferably a tool to auto-generate such) - a modified driver that passes all kinds of right options for a given MCU That's a minimum for other Bare Metal D projects to even start to take off. Ideally other tools include debugger, high-level libraries for peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and so on. Let me add that I think the -betterC switch, or similar, is too blunt an instrument. I'd like to have the flexibility to fine tune the language features (even on individual types) for the platform and/or application I'm building. And while compiler switches and attributes may help, I think delegating features from the compiler to the runtime is a better
Re: Bare-metal programming in D (was GSOC - Holiday Edition)
On Friday, 9 January 2015 at 20:24:55 UTC, Dmitry Olshansky wrote: Great. This helps me understand what is the main impediment at the moment. With that in mind I think we can formulate our GSOC plan better. As far as I can tell it can focus on 2 paths: a) Get embedded-savy student to work on MCU support and stuff while delegating most compiler tweaks to mentor(s) and core team. b) Get a student interested in compilers to deliver on getting robust cross-compiler with minimal run-time. Getting actual boards to work is then delegated to mentors. I am in favor of a). I've found that I can only get so far with a), unless you are willing to be rather tolerant with what D currently offers. It could be enough for a summer project, though, and I suppose it could help highlight some of D's current shortcomings in this domain. Eventually, though, a) will need b), and I think b) cannot be done properly without changes in the compiler. Mike
Bare-metal programming in D (was GSOC - Holiday Edition)
On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky wrote: Truth be told none of listed in this thread feel fundamental to me. It looks more like a set of patches to each specific problem in the compiler or run-time. Yeah, run-time would better be more customizable, but it's just our *current* run-time it's not the language. Perhaps high-impact would be a better word than fundamental. I think moving runtime hooks out of the compiler to .di files and Adam Ruppe's proposal to move TypeInfo to the runtime are great ideas. Enhancement 11666 [1] is another. That really highlighted a design problem in the runtime for me. If the runtime had better separation of language, platform (OS and architecture) and library, the ports would simply have their own folder in the runtime rather than their own repository. The controversy that followed the pull requests in an attempt address 11666 clearly shows the problems that high coupling to the platform can cause. If the platform were encapsulated and decoupled from the language implementation, we'd already be well on our way. [1] - https://issues.dlang.org/show_bug.cgi?id=11666 But I've been watching how such changes are perceived here, and I'm skeptical they would be accepted because so much in the language is potentially affected by them. Due to the fact that they only benefit a few bare-metal folks, but impact the full language, I'm quite confident they would be shunned, and that's been very discouraging. Thus I do not believe that immediate upstreaming of everything bare-metal is even a good thing in principle. In my opinion a Bare-Metal D project can live its life along the upstream D by providing bare-metal versions of each successive version. In fact, we do not have all that many embedded guys in core team. All generally useful patches should find their way in upstream, of course, but it takes time and should *not* be a prerequisite. Sure the bare-metal stuff can exist along-side the upstream repository. That's actually what I alluded to in my previous posts, that bare-metal programming in D will likely need to fork. In fact, due to the lack of support, I don't see it happening any other way. A toolkit will need to provide e.g build/fetch with a bootstrap script: - a ready to-go D cross-compiler(s) might be with some patches to disable language features for better experience etc. That's more-or-less what I've suggested in this thread. If that happened, I could get behind the items you listed below. But I don't know how to proceed with the compiler, that's not my interest nor within my current ability. Johannes has been exploring this territory, however, which is encouraging. - a stripped run-time instead of Phobos (come on C/C++ folks use something much unlike standard library either) - linker scripts for a (growing) set of MCUs - I/O library and register definitions for MCUs (preferably a tool to auto-generate such) - a modified driver that passes all kinds of right options for a given MCU That's a minimum for other Bare Metal D projects to even start to take off. Ideally other tools include debugger, high-level libraries for peripherals (HAL), ports or bindings to C FAT, IP, ... libraries and so on. Let me add that I think the -betterC switch, or similar, is too blunt an instrument. I'd like to have the flexibility to fine tune the language features (even on individual types) for the platform and/or application I'm building. And while compiler switches and attributes may help, I think delegating features from the compiler to the runtime is a better investment. Mike