digitalmars.D.learn - Unixes support
- Ricardo Navarro Vasquez (16/16) Mar 27 2006 Hi,
- Thomas Kuehne (26/34) Mar 28 2006 -----BEGIN PGP SIGNED MESSAGE-----
- Ricardo Navarro Vasquez (21/55) Mar 29 2006 Embedded systems are mostly FPGA's or ASIC's (64bits and SPARC's) runing
- Ricardo Navarro Vasquez (21/55) Mar 29 2006 Embedded systems are mostly FPGA's or ASIC's (64bits and SPARC's) runing
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
-----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
Ricardo Navarro Vasquez <Ricardo_member pathlink.com> 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
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