Thread overview | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 01, 2015 H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
This is related to the recent publication of D's H1 2015 Priorities [1], but I suspect this post could create a few tangents, so I decided to post it under its own thread. IMO D has high potential for kernel programming, embedded systems, and other bare-metal varieties where high-level language features are often not needed or even wanted (but sometimes used). D has some fantastic features for low-level programming with great power and convenience, but it is currently heavily biased towards platforms with a full-featured, resource abundant operating system, and some of it's high-level features get in the way. Periodically, users pop into the forum, ask questions this, give it a try, and then leave [2]. There has been the occasional suggestion for a -minimalD compiler flag or some other twist, but IMO that's not a very elegant or appropriate solution. I think Rust is headed in a better direction with it's "minimal runtime" philosophy [3] and features like #![no_std], #![feature(lang_items)], #[lang = "whatever"], and extern "rust-intrinsic" [4]. I'm not suggesting D mimic Rust's approach, but rather learn from it, and provide an attractive alternative that jives with D's way of doing things. However, when I read "Foster library additions over language changes, and raise the bar on language changes", I suspect changes to accommodate this kind of programming will be viewed as "shuffling the deck". So, I'm currently on the fence with D. Rust and Nim are showing great promise in this domain, Rust has already implemented supporting features (as mentioned above), and Rust's Zinc project [5] is really catching on. Is D's core team genuinely interested in this domain? If you are genuinely interested, are you committed? And if so, what direction would you like to take? So far, my ideas have been very unpopular and I'm growing weary fighting the current. How can I contribute in a way that gets us both where we want to go? If you're not particularly interested in this domain, that's OK. Perhaps you are interested, but not at this time. Perhaps you are only interested in mobile and mico-PC platforms that have full-featured operating systems, but not resource constrained bare-metal platforms. Whatever the case, please let it be known. Thanks in advance for your constructive comments, Mike [1] - 2015 H1 Vision - http://forum.dlang.org/post/majurl$2457$1@digitalmars.com [2] - Why D is not a Systems Programming Language - https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md [3] - Rust Programming Language - http://www.rust-lang.org/ [4] - Writing Safe Unsafe and Low-Level Code in Rust - http://doc.rust-lang.org/0.11.0/guide-unsafe.html [5] - Zinc, the bare metal stack for rust - https://github.com/hackndev/zinc |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | On Sunday, 1 February 2015 at 05:21:15 UTC, Mike wrote:
> ...
> [2] - Why D is not a Systems Programming Language - https://github.com/klamonte/cycle/blob/master/docs/no_more_d.md
I don't have much to add but this is one of the better critiques of D I've seen.
|
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Mike | On 1/31/2015 9:21 PM, Mike wrote: > Is D's core team genuinely interested in this domain? Yes. > If you are genuinely interested, are you committed? And if so, what direction > would you like to take? So far, my ideas have been very unpopular and I'm > growing weary fighting the current. How can I contribute in a way that gets us > both where we want to go? I don't recall what you've suggested in this vein that was very unpopular - can you please post an example? |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote: > On 1/31/2015 9:21 PM, Mike wrote: >> Is D's core team genuinely interested in this domain? > > Yes. > > >> If you are genuinely interested, are you committed? And if so, what direction >> would you like to take? So far, my ideas have been very unpopular and I'm >> growing weary fighting the current. How can I contribute in a way that gets us >> both where we want to go? > > I don't recall what you've suggested in this vein that was very unpopular - can you please post an example? The one of major issues is: how to access hardware. We need a language feature to access hardware registers. This has been discussed twice. Both time you rejected anything but your own idea of library functions. You rejected anything anybody said. No serious programmer will write code that way. It worked in 80's when we had an uart with three registers 8 bit each. Now an usb or ethernet peripheral may have 100 registers 32 bit each. There are workarounds: - disable optimization. the code works but is 3 times bigger and slower - GDC marks shared variables as volatile. This works mostly but is unstandard and unstable and may be removed at any time. - Have an separate templated data type which has its own operators. While this seems to work, it is a little complicated way to do things. ---- There are some areas that might be developed. There are not many people here that work with microcontollers besides Mike and I. Many people make just web services. This is ok, the business is there. If bare metal is a goal for D then it is impostant that we processor people do not feel ourselves as second class people. Our needs and concerns should at least be noticed and respected by leaders. More practioal thing is the runtime library. Mike, Adam and some others have started with empty runtime and added only what they need. This does not get very far because mamy real D features need runtime functions. I may the only one to start with full runtime and remove anything that does not work. I have many D features working now, like exceptions. The runtime needs: - NoSystem should be a supported platform and not a build failure. The build system should leave out files and features that are not available. - Unrelated things should be split in separate files and unnecessary imports should be removed. Object.d is pulling in most of the library with its imports. Imports that are used only in unittests should be in unittest blocks. I know this is worked on. - Runtime library functions should not use gc and free all resources they use. I know this is also being worked on. The absolute minimum set of changes that I had to make can be seen here: https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default These are for GDC 2.065 and some of these may have changed when GDC 2.066 is out. In addition, I still need my own build system to select files and to compile with correct processor options. My skills are not enough to modify the original build system. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | On 2/1/2015 1:38 AM, Timo Sintonen wrote: > The one of major issues is: how to access hardware. We need a language feature > to access hardware registers. This has been discussed twice. Both time you > rejected anything but your own idea of library functions. You rejected anything > anybody said. No serious programmer will write code that way. It worked in 80's > when we had an uart with three registers 8 bit each. Now an usb or ethernet > peripheral may have 100 registers 32 bit each. core.bitop.volatileLoad() and volatileStore() are implemented, and do the job. They are compiler intrinsics that result in single instructions. They support 8, 16, 32 and 64 bit loads and stores. > There are workarounds: > - disable optimization. the code works but is 3 times bigger and slower > - GDC marks shared variables as volatile. This works mostly but is unstandard > and unstable and may be removed at any time. > - Have an separate templated data type which has its own operators. While this > seems to work, it is a little complicated way to do things. I don't see the need for any of these workarounds. The compiler intrinsics are volatile, i.e. they are not optimized away even when optimization is turned on. > The runtime needs: > - NoSystem should be a supported platform and not a build failure. The build > system should leave out files and features that are not available. > - Unrelated things should be split in separate files and unnecessary imports > should be removed. Object.d is pulling in most of the library with its imports. > Imports that are used only in unittests should be in unittest blocks. I know > this is worked on. > - Runtime library functions should not use gc and free all resources they use. I > know this is also being worked on. > > The absolute minimum set of changes that I had to make can be seen here: > https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default The link does not work. I have added https://issues.dlang.org/show_bug.cgi?id=14100 and have also added the "bare-metal" keyword. Please enumerate the issues you're having, file them on bugzilla, and tag them with "bare-metal". |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Timo Sintonen | > The absolute minimum set of changes that I had to make can be seen here: > https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default > corrected link (I think): https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to eles | On Sunday, 1 February 2015 at 10:11:57 UTC, eles wrote: >> The absolute minimum set of changes that I had to make can be seen here: >> https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default >> > corrected link (I think): > > https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default And, for info, pasted here: This file is not a changelog. Instead, this file documents changes that are needed to the current gdc libdruntime sources. (2.065 and 4.10 series gdc/gcc) The files are in the order they were needed when testing core/stdc/stdlib.d 49 default value for RAND_MAX instead of assert core/memory 84-85,123 changed private imports to public gcstub/gc.d 31 removed import stdio 134 removed thread_init object.d 30 removed import minfo 132-142 removed factory (moduleinfo is not used) 562 renamed GC.free gc_free (core.memory not used) 604-657 removed associative arrays 858-873 removed module related code 1561-1732 removed moduleinfo 1733-1932 removed monitor 1933-2283 removed assicoative arrays 2257,2262 changed comment to /* */ core/exception.d 14 removed import stdio 593-596,610-613,627-630,639-642 removed module related functions rt/lifetime.d 246,278,310 removed synchronized 1222-122 removed monitor call rt/adi.d 46-134 removed _adReverseChar (because utf is not supported) 95-96 changed comment to // 320-360 removed _adSortChar and _adSortWchar because of several missing functions core/time.d (optional file) 23 removed import stdc.time 24 removed import stdio 2125 dummy retval for the function PS I have no connection with the OP. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to eles | On 2/1/2015 2:12 AM, eles wrote:
> On Sunday, 1 February 2015 at 10:11:57 UTC, eles wrote:
>>> The absolute minimum set of changes that I had to make can be seen here:
>>> https://bitbucket.org/timosi/minlib/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
>>>
>>>
>> corrected link (I think):
>>
>> https://bitbucket.org/timosi/minlibd/src/8674af49718880021c2777d60ac2091bc99c0107/Changes?at=default
>>
>
> And, for info, pasted here:
>
> This file is not a changelog. Instead, this file documents changes
> that are needed to the current gdc libdruntime sources.
> (2.065 and 4.10 series gdc/gcc)
Please post to bugzilla and tag the issue with "bare-metal".
|
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter Bright | On Sunday, 1 February 2015 at 10:14:28 UTC, Walter Bright wrote: > > Please post to bugzilla and tag the issue with "bare-metal". https://issues.dlang.org/show_bug.cgi?id=14101 Please have a look and correct if necessary. |
February 01, 2015 Re: H1 2015 Priorities and Bare-Metal Programming | ||||
---|---|---|---|---|
| ||||
Posted in reply to eles | On 2/1/2015 2:21 AM, eles wrote:
> On Sunday, 1 February 2015 at 10:14:28 UTC, Walter Bright wrote:
>
>>
>> Please post to bugzilla and tag the issue with "bare-metal".
>
> https://issues.dlang.org/show_bug.cgi?id=14101
>
> Please have a look and correct if necessary.
Thank you.
|
Copyright © 1999-2021 by the D Language Foundation