Hi,

I've been reading a lot and there are some questions I would like to ask:

- How well supported are the Unixes/Posix OS's? Compared with Windows?
- Are DMD and GDC incompatibles?
- What about GDB? Will it be fully supported?
- For wich architectures are compilers planed? SPARC, x86-64?
- Is D well suited for developing real-time and embedded systems?

I'm very intersted to migrate to D as it greatly improves C. However, the
industry I'm currently working in (Aerospatial), reliability is a must, Windows
is seldom seen and SPARC's wander everywhere.
"THE" debugging tool is GDB, not only because it is a fine piece of art, it also
can be used to remote debug embedded's via RS232 or ethernet, supports emulated
real-time (with rdbmon) and works with all the standard languages of the
industry (Fortran, ADA & C).

Thank you very much,

Ricardo.

Ricardo Navarro Vasquez schrieb am 2006-03-27:
> I've been reading a lot and there are some questions I would like to ask:

[snip]

> - Are DMD and GDC incompatibles?

GDC's frontend is based on DMD's frontend. Source code incompatibles are
limited to OS specific issues (e.g. GDC runs on Macs, DMD doesn't),
the time lag it takes to adapt changes in the DMD frontend for GDC
and plain implementation bugs.

Don't try to mix object files created by DMD and GDC.
(internals like the GC implementation differ)

> - What about GDB? Will it be fully supported?

Basic GDB support(stepping) is supported and a patch for name demangling can be found on dsource. Full support would require a bit more detailed ABI documentation and someone implementing the necessary parts in GDB.

[snip]

> - Is D well suited for developing real-time and embedded systems?

Define "embedded". Using D for smart phones seems OK, but the runtime (Phobos) might require some review and stripping - Ares might be a starting point.

> I'm very intersted to migrate to D as it greatly improves C. However, the industry I'm currently working in (Aerospatial), reliability is a must, Windows is seldom seen and SPARC's wander everywhere.

I don't know what level of reliability you are thinking of: Unittests and invariants will help at the start, but using formal verification for a D program might be difficult.

Thomas

Embedded systems are mostly FPGA's or ASIC's (64bits and SPARC's) runing real-time numerical simulations or flight/actitude models. A lot of low level programing.

It is often necessary to verify formally the code, and as the software is almost always developed in diferent companies/agencies or even different countries, the program shall be easy to understand and modify. In addition, large test campaigns, always performed by a different group than the makers, try to ensure the software reliability.

When ADA is not mandatory, C or Fortran can be used. Java is not suited to this kind of work and C++ is too much error prone for programmers. The rest of languages are seldom seen.

More and more often COTS are used instead of in-house or GOTS, so programming in LabVIEW or Matlab is very common. However, as C and ADA are supported in those languages (or programming environments) is very common to see mixed code.

Well this is more or less the situation in Aerospace industry. D is currently too young but has the potential to become very well suited for those tasks. However, its adoption depends mainly on easy debugging and easy maintainability, even for large software, developed by many groups. In addition, support for more architectures enables a broader range of companies/agencies considering its use.

Ricardo.

In article <q6bof3-tqi.ln1@birke.kuehne.cn>, Thomas Kuehne says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Ricardo Navarro Vasquez schrieb am 2006-03-27:
>> I've been reading a lot and there are some questions I would like to ask:
>
>[snip]
>
>> - Are DMD and GDC incompatibles?
>
>GDC's frontend is based on DMD's frontend. Source code incompatibles are
>limited to OS specific issues (e.g. GDC runs on Macs, DMD doesn't),
>the time lag it takes to adapt changes in the DMD frontend for GDC
>and plain implementation bugs.
>
>Don't try to mix object files created by DMD and GDC.
>(internals like the GC implementation differ)
>
>> - What about GDB? Will it be fully supported?
>
>Basic GDB support(stepping) is supported and a patch for name demangling can be found on dsource. Full support would require a bit more detailed ABI documentation and someone implementing the necessary parts in GDB.
>
>[snip]
>
>> - Is D well suited for developing real-time and embedded systems?
>
>Define "embedded". Using D for smart phones seems OK, but the runtime (Phobos) might require some review and stripping - Ares might be a starting point.
>
>> I'm very intersted to migrate to D as it greatly improves C. However, the industry I'm currently working in (Aerospatial), reliability is a must, Windows is seldom seen and SPARC's wander everywhere.
>
>I don't know what level of reliability you are thinking of: Unittests and invariants will help at the start, but using formal verification for a D program might be difficult.
>
>Thomas
>
>
>-----BEGIN PGP SIGNATURE-----
>
>iD8DBQFEKX2z3w+/yD4P9tIRAinLAKC7GkOsoilX964SZa53fYNcabloLACgyu4c
>kuYg00mokSFjNXmuCX3uZag=
>=acdf
>-----END PGP SIGNATURE-----

Embedded systems are mostly FPGA's or ASIC's (64bits and SPARC's) runing real-time numerical simulations or flight/actitude models. A lot of low level programing.

It is often necessary to verify formally the code, and as the software is almost always developed in diferent companies/agencies or even different countries, the program shall be easy to understand and modify. In addition, large test campaigns, always performed by a different group than the makers, try to ensure the software reliability.

When ADA is not mandatory, C or Fortran can be used. Java is not suited to this kind of work and C++ is too much error prone for programmers. The rest of languages are seldom seen.

More and more often COTS are used instead of in-house or GOTS, so programming in LabVIEW or Matlab is very common. However, as C and ADA are supported in those languages (or programming environments) is very common to see mixed code.

Well this is more or less the situation in Aerospace industry. D is currently too young but has the potential to become very well suited for those tasks. However, its adoption depends mainly on easy debugging and easy maintainability, even for large software, developed by many groups. In addition, support for more architectures enables a broader range of companies/agencies considering its use.

Ricardo


In article <q6bof3-tqi.ln1@birke.kuehne.cn>, Thomas Kuehne says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Ricardo Navarro Vasquez schrieb am 2006-03-27:
>> I've been reading a lot and there are some questions I would like to ask:
>
>[snip]
>
>> - Are DMD and GDC incompatibles?
>
>GDC's frontend is based on DMD's frontend. Source code incompatibles are
>limited to OS specific issues (e.g. GDC runs on Macs, DMD doesn't),
>the time lag it takes to adapt changes in the DMD frontend for GDC
>and plain implementation bugs.
>
>Don't try to mix object files created by DMD and GDC.
>(internals like the GC implementation differ)
>
>> - What about GDB? Will it be fully supported?
>
>Basic GDB support(stepping) is supported and a patch for name demangling can be found on dsource. Full support would require a bit more detailed ABI documentation and someone implementing the necessary parts in GDB.
>
>[snip]
>
>> - Is D well suited for developing real-time and embedded systems?
>
>Define "embedded". Using D for smart phones seems OK, but the runtime (Phobos) might require some review and stripping - Ares might be a starting point.
>
>> I'm very intersted to migrate to D as it greatly improves C. However, the industry I'm currently working in (Aerospatial), reliability is a must, Windows is seldom seen and SPARC's wander everywhere.
>
>I don't know what level of reliability you are thinking of: Unittests and invariants will help at the start, but using formal verification for a D program might be difficult.
>
>Thomas
>
>
>-----BEGIN PGP SIGNATURE-----
>
>iD8DBQFEKX2z3w+/yD4P9tIRAinLAKC7GkOsoilX964SZa53fYNcabloLACgyu4c
>kuYg00mokSFjNXmuCX3uZag=
>=acdf
>-----END PGP SIGNATURE-----