www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Mission-Critical systems

reply Lasheen <hazem.lasheen yandex.com> writes:
Is D language designed for working with [Mission-critical] 
systems?
and what about:

1- Safety, Security and reliability to reach work in avionics 
systems.
2- memory management for [mission-Critical] systems.
3- which compiler i have to use (if yes).
4- which tools i can use for.

I want any information about that.
Thanks.
Mar 15
next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
 Is D language designed for working with [Mission-critical] 
 systems?
 and what about:

 1- Safety, Security and reliability to reach work in avionics 
 systems.
 2- memory management for [mission-Critical] systems.
 3- which compiler i have to use (if yes).
 4- which tools i can use for.

 I want any information about that.
 Thanks.
I asked this earlier: "Sure. It's far better than C is. The biggest impact is simply having array overflow detection. There's a lot more, too, such as protections against uninitialized variables and pointers to expired stack frames." "If C is ready for safety critical applications, then DasBetterC is beyond ready." So, you would have to stick to a specific version of D and compiler, run a bunch of tests, document bugs etc, but other than that I see no problem with using D at all. You just get safer code using D.
Mar 15
parent Lasheen <hazem.lasheen yandex.com> writes:
On Tuesday, 16 March 2021 at 06:57:53 UTC, Imperatorn wrote:
 On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
 Is D language designed for working with [Mission-critical] 
 systems?
 and what about:

 1- Safety, Security and reliability to reach work in avionics 
 systems.
 2- memory management for [mission-Critical] systems.
 3- which compiler i have to use (if yes).
 4- which tools i can use for.

 I want any information about that.
 Thanks.
I asked this earlier: "Sure. It's far better than C is. The biggest impact is simply having array overflow detection. There's a lot more, too, such as protections against uninitialized variables and pointers to expired stack frames." "If C is ready for safety critical applications, then DasBetterC is beyond ready." So, you would have to stick to a specific version of D and compiler, run a bunch of tests, document bugs etc, but other than that I see no problem with using D at all. You just get safer code using D.
Thank you for your useful answer, I tried to search for any tutorials that can help me to get in but all the information i found were just a general information and i need some tutorials to explain how to start, which compiler i can use, how to use real-time in D, ..etc; i normally use Ada and C for AI solutions but i think D can be the future of system languages if Walter and Andrey found the support.
Mar 16
prev sibling next sibling parent Dukc <ajieskola gmail.com> writes:
On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
 Is D language designed for working with [Mission-critical] 
 systems?
 and what about:

 1- Safety, Security and reliability to reach work in avionics 
 systems.
 2- memory management for [mission-Critical] systems.
 3- which compiler i have to use (if yes).
 4- which tools i can use for.

 I want any information about that.
 Thanks.
The language itself would be well upon the task. D is more safety-focused than your average language. It might not be quite the safety-before-all language Rust or Ada seem to be, but since even OpenBSD is written in C, I would not worry about the bar being that high. But currently D is no option for anything that requires a certified compiler since there are none, nor plans to make one. More info here: https://forum.dlang.org/thread/qspiqykabwfmgoibcvsa forum.dlang.org
Mar 16
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
 Is D language designed for working with [Mission-critical] 
 systems?
As others have said, *in theory* the language itself is much better suited for mission-critical applications than C, because of slices, stronger typing, safe, etc. But...
 and what about:

 1- Safety, Security and reliability to reach work in avionics 
 systems.
I would not trust any current D compiler with a human life, because they are all rather buggy in my experience. And, they do not offer stable releases with long-term support, so you will inevitably either miss out on critical bug fixes by sticking with an old version, or expose yourself to regressions by updating often. If the only other option is C, I would probably still pick D, but I suspect there are better options out there than either, once stability and quality of implementation is taken into account - maybe Ada, Rust, or, if a garbage collected language is
 2- memory management for [mission-Critical] systems.
D's stop-the-world garbage collector is not an option for true real time systems, where a missed deadline means someone actually dies. However, in other cases I would use the GC if the goal is maximum reliability: Many of the D features that make typical D code less error-prone than C equivalents require the garbage collector. Moreover, most D code uses the garbage collector and so the non-GC alternatives are generally less well-tested, and thus more likely to trigger compiler bugs. (I speak from personal experience: I am currently working on an nogc D program, and have so far found and reported several serious compiler bugs in the course of the project.)
 3- which compiler i have to use (if yes).
The DMD backend is quite buggy (and also optimizes poorly) compared to those used by GDC and LDC. On the other hand, the GDC frontend is very out of date compared to those used by DMD and LDC. So, definitely use LDC if you are planning to bet human lives and/or millions of dollars on it working fully correctly.
Mar 16
next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 17 March 2021 at 03:44:15 UTC, tsbockman wrote:
 On Tuesday, 16 March 2021 at 04:22:01 UTC, Lasheen wrote:
 3- which compiler i have to use (if yes).
The DMD backend is quite buggy (and also optimizes poorly) compared to those used by GDC and LDC. On the other hand, the GDC frontend is very out of date compared to those used by DMD and LDC. So, definitely use LDC if you are planning to bet human lives and/or millions of dollars on it working fully correctly.
This is misleading as if to say that GDC is not maintained, which is untrue. GDC's current feature freeze means it is currently a stable rock whilst still getting backported bugfixes from dmd master, and is gaining plenty platform support where DMD and LDC don't have a presence - no GDC, no DMD or LDC on Musl - so another way to look at it, you could instead weigh up whether stability or bleeding edge is better suit for critical systems.
Mar 17
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Wednesday, 17 March 2021 at 17:13:00 UTC, Iain Buclaw wrote:
 On Wednesday, 17 March 2021 at 03:44:15 UTC, tsbockman wrote:
 The DMD backend is quite buggy (and also optimizes poorly) 
 compared to those used by GDC and LDC. On the other hand, the 
 GDC frontend is very out of date compared to those used by DMD 
 and LDC.

 So, definitely use LDC if you are planning to bet human lives 
 and/or millions of dollars on it working fully correctly.
This is misleading as if to say that GDC is not maintained, which is untrue. GDC's current feature freeze means it is currently a stable rock whilst still getting backported bugfixes from dmd master,
The latest version of GDC which I have easy access to (Ubuntu's 10.2.0 package, since I can't find up to date binaries on the website) reports a frontend version of 2.076. And, it sounds like you're saying that this GDC version likely includes many improvements not listed in the DMD change logs up to 2.076. But, how am I supposed to know what those backported improvements are? Is there a separate GDC frontend change log somewhere that documents all differences of significance to the user versus the standard 2.076 frontend? If so, I haven't been able to find it. If I write code that requires a specific frontend bug fix or enhancement to work correctly, how can I detect whether GDC has it at compile time? On DMD and LDC I can just check the frontend __VERSION__, but that doesn't help me detect anything after the standard 2.076 with GDC.
Mar 17
parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Wednesday, 17 March 2021 at 19:54:23 UTC, tsbockman wrote:
 [..] Is there a separate GDC frontend change log somewhere that 
 documents all differences of significance to the user versus 
 the standard 2.076 frontend? [..]
I suppose this is what you're looking for: Changelog for the current year: https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog Changelog for previous years: https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog-2020 https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog-2019 https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog-2018 For example: [..] * dmd/MERGE: Merge upstream dmd a3c9bf422. [..] * dmd/MERGE: Merge upstream dmd 7132b3537. These correspond to: https://github.com/dlang/dmd/pull/12190 https://github.com/dlang/dmd/pull/12247
Mar 18
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Thursday, 18 March 2021 at 08:36:51 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Wednesday, 17 March 2021 at 19:54:23 UTC, tsbockman wrote:
 [..] Is there a separate GDC frontend change log somewhere 
 that documents all differences of significance to the user 
 versus the standard 2.076 frontend? [..]
I suppose this is what you're looking for: Changelog for the current year: https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog
Thanks, but I've seen that before. It's an internal development log, and does not describe how code changes translate into different user-facing behavior. So, in order to understand which additional issues are fixed in the current GDC frontend, I have to: 0) Filter all the irrelevant internal changes out of the log. 1) For each "Merge upstream dmd" line, a) Manually look up the relevant DMD commit (no links). b) Find the pull request that introduced that commit, since that's where most of the discussion is. c) Study the DMD pull request to figure out what issue, if any, it fixes. d) Read the discussion and study DMD's commit history to figure out whether *all* required changes have also been backported to GDC from other relevant DMD commits, which other changes may or may not even be mentioned in the DMD pull request discussion. (1.d) is necessary even if I assume the GDC developers never make mistakes or miss anything, because the GDC changelog doesn't even claim to record issues fixed, but only upstream commits merged. An upstream commit may have been merged because it partially fixes some issue, and fully fixing the issue was considered infeasible with a 2.076 base. Or, it may have been merged without all prerequisites simply because backporting the fix is a work in progress. TLDR; Translating that changelog into a list of issues *fixed* (not just affected) is time consuming and can only be done with confidence by someone who is an expert in the development history/process of both DMD and GDC.
Mar 18
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/18/2021 12:44 PM, tsbockman wrote:
      c) Study the DMD pull request to figure out what issue, if any, it
fixes.
We require DMD pull requests that fix a bug to reference a bugzilla issue for the bug, and to have the title of the PR include the title of the bugzilla issue. Also, when I fix a bugzilla issue, I'll often change its title to more accurately reflect what the actual problem was.
Mar 19
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Thursday, 18 March 2021 at 08:36:51 UTC, Petar Kirov 
[ZombineDev] wrote:
 On Wednesday, 17 March 2021 at 19:54:23 UTC, tsbockman wrote:
 [..] Is there a separate GDC frontend change log somewhere 
 that documents all differences of significance to the user 
 versus the standard 2.076 frontend? [..]
I suppose this is what you're looking for: Changelog for the current year: https://github.com/D-Programming-GDC/gcc/blob/master-ci/gcc/d/ChangeLog
Nope, that's just a file that contains boring human-readable description of a commit (http://www.gnu.org/prep/standards/standards.html#Change-Log-Concepts). High-level feature changes are mentioned on the GCC site. https://gcc.gnu.org/gcc-9/changes.html#d https://gcc.gnu.org/gcc-10/changes.html#d https://gcc.gnu.org/gcc-11/changes.html#d (content will be added closer to release date). Typically bug-fixes come from PRs (problem references) that are created against D. https://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=d&version=9.0 https://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=d&version=10.0 https://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=d&version=11.0 As I fix ICE's in dmd master, these are typically proactively backported to the dmd-cxx branch as well (this is the upstream that's merged into gcc itself). https://github.com/dlang/dmd/commits/dmd-cxx https://github.com/dlang/druntime/commits/dmd-cxx https://github.com/dlang/phobos/commits/dmd-cxx As a rule of thumb, all stdc bindings are generally kept closely in sync with dmd master to ensure the broadest possible platform support, and expired deprecations removed.
Mar 19
parent reply tsbockman <thomas.bockman gmail.com> writes:
On Friday, 19 March 2021 at 18:21:35 UTC, Iain Buclaw wrote:
 High-level feature changes are mentioned on the GCC site.

 https://gcc.gnu.org/gcc-9/changes.html#d
 https://gcc.gnu.org/gcc-10/changes.html#d
 https://gcc.gnu.org/gcc-11/changes.html#d (content will be 
 added closer to release date).

 Typically bug-fixes come from PRs (problem references) that are 
 created against D.

 https://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=d&version=9.0
 https://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=d&version=10.0
 https://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=d&version=11.0

 As I fix ICE's in dmd master, these are typically proactively 
 backported to the dmd-cxx branch as well (this is the upstream 
 that's merged into gcc itself).

 https://github.com/dlang/dmd/commits/dmd-cxx
 https://github.com/dlang/druntime/commits/dmd-cxx
 https://github.com/dlang/phobos/commits/dmd-cxx

 As a rule of thumb, all stdc bindings are generally kept 
 closely in sync with dmd master to ensure the broadest possible 
 platform support, and expired deprecations removed.
Great! That is far closer to what I was looking for. Maybe you could put these links and a few sentences of explanation somewhere prominent on the GDC website? I think it would significantly increase awareness that GDC isn't really stuck on 2.076's specific mix of features and bugs.
Mar 20
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Saturday, 20 March 2021 at 18:43:43 UTC, tsbockman wrote:
 Great! That is far closer to what I was looking for.

 Maybe you could put these links and a few sentences of 
 explanation somewhere prominent on the GDC website? I think it 
 would significantly increase awareness that GDC isn't really 
 stuck on 2.076's specific mix of features and bugs.
It's been a thing on my todo.txt list to add a releases/change notes tab in the menu, but limited time means I have to focus priorities elsewhere. ;-)
Mar 21
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2021 8:44 PM, tsbockman wrote:
 So, definitely use LDC if you are planning to bet human lives and/or millions
of 
 dollars on it working fully correctly.
The first three years of my career was spent developing the flight critical stabilizer trim gearbox for the 757. Flight critical means if it comes apart, you lose the airplane and everyone aboard. So I know how to build things that are critical for human life. Generally speaking, there is no relying on any tool to be bug-free. Test and verify everything. Design in a backup system to monitor the behavior. For example, there was an autopilot embedded system that commanded the stabilizer trim. We all know how a runaway stab trim system can kill people (see the 737MAX). There were two autopilot computers in parallel. They both had to agree, or both were automatically disconnected. They used different microprocessors, different software algorithms, different programming languages, different compilers. The coding was done by different teams who weren't allowed to talk to each other. A third independent team verified that no problem in one could propagate to the other. Notice there is no reliance on bug-free hardware, bug-free algorithms, bug-free code, bug-free compilers, etc.
Mar 18
parent mw <mingwu gmail.com> writes:
On Friday, 19 March 2021 at 06:32:18 UTC, Walter Bright wrote:
 On 3/16/2021 8:44 PM, tsbockman wrote:
 So, definitely use LDC if you are planning to bet human lives 
 and/or millions of dollars on it working fully correctly.
The first three years of my career was spent developing the flight critical stabilizer trim gearbox for the 757. Flight critical means if it comes apart, you lose the airplane and everyone aboard. So I know how to build things that are critical for human life. Generally speaking, there is no relying on any tool to be bug-free. Test and verify everything. Design in a backup system to monitor the behavior.
...
 Notice there is no reliance on bug-free hardware, bug-free 
 algorithms, bug-free code, bug-free compilers, etc.
In engineering practice, redundancy backup is the way to achieve reliability. On the other hand, programming logic / compiler is also mathematics, where reliability is achieved by theorem provers, e.g. https://en.wikipedia.org/wiki/CompCert https://github.com/AbsInt/CompCert CompCert The formally-verified C compiler. The distinguishing feature of CompCert is that it has been formally verified using the Coq proof assistant: the generated assembly code is formally guaranteed to behave as prescribed by the semantics of the source C code.
Apr 06
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/16/2021 8:44 PM, tsbockman wrote:
 The DMD backend is quite buggy (and also optimizes poorly) compared to those 
 used by GDC and LDC.
Bugzilla lists 22 issues with the DMD backend that are tagged with the 'backend' keyword: https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=backend%2C%20&keywords_type=allwords&list_id=235330&query_format=advanced If you know of other reported issues with the backend that are not so tagged, please do so. If you know of non-reported issues with the backend, please file bug reports for them.
Mar 20
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Saturday, 20 March 2021 at 07:21:21 UTC, Walter Bright wrote:
 On 3/16/2021 8:44 PM, tsbockman wrote:
 The DMD backend is quite buggy (and also optimizes poorly) 
 compared to those used by GDC and LDC.
Bugzilla lists 22 issues with the DMD backend that are tagged with the 'backend' keyword: https://issues.dlang.org/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&keywords=backend%2C%20&keywords_type=allwords&list_id=235330&query_format=advanced If you know of other reported issues with the backend that are not so tagged, please do so.
I've gone through all my current open issues and tagged them where I think it relates to backend.
Mar 21
parent Walter Bright <newshound2 digitalmars.com> writes:
On 3/21/2021 2:40 AM, Iain Buclaw wrote:
 I've gone through all my current open issues and tagged them where I think it 
 relates to backend.
Good!
Mar 22