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