www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Unixes support

reply Ricardo Navarro Vasquez <Ricardo_member pathlink.com> writes:
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.
Mar 27 2006
parent reply Thomas Kuehne <thomas-dloop kuehne.cn> writes:
-----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-----
Mar 28 2006
next sibling parent Ricardo Navarro Vasquez <Ricardo_member pathlink.com> writes:
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-----
Mar 29 2006
prev sibling parent Ricardo Navarro Vasquez <Ricardo_member pathlink.com> writes:
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-----
Mar 29 2006