Unixes support
Ricardo Navarro Vasquez
Ricardo_member at pathlink.com
Wed Mar 29 02:10:03 PST 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 at 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-----
More information about the Digitalmars-d-learn
mailing list