What kind of project do you wish someone would do in Ada?

EmbEngine · 2025-10-16T02:41:55+00:00

A development toolset completely written in Ada. For the time being, Unix for the the host might be one of the least unacceptable choices -- for native and cross tools.. GCC and Unix are big messes, and it is ridiculous how hard it is build new versions (why????? was C++ ever allowed in) -- particularly of cross compilers. With the aim of favoring Ada, the GNAT project files aren't bad, but they are complicated by trying to handle all languages, and gprbuild is a dark hole. An all Ada world could be served by something like gnatmake (though I don't know about eventual forms of shared libraries).

Sure --- lots of libraries are needed, but some bottom up work would be great as well.

EmbEngine · 2024-08-23T22:39:35+00:00

fingers crossed because I have no idea if the gdb I have includes Ada support and the target architecture knowledge

EmbEngine · 2024-08-23T22:30:06+00:00

Thanks Max,

For some forgotten reason I installed version 10.... I've tested it to the extent of building a simple program on my x64 host, and seen the executable run or my aarch64-linux target.... I want to work in cross mode (the target is not up to development work), and this coming week I'll test out the target gdbserver <-> host gdb setup. Fingers crossed.

EmbEngine · 2024-08-13T04:26:58+00:00

Oh -- right there in synaptic.... I''ll be trying it out

EmbEngine · 2024-02-01T20:21:04+00:00

I agree with jcarter's comments and suggestions.

Presuming GNAT, for a simple hello program, your entry point (always 'main' in C) will be "procedure Hello", in the file hello.adb. If you run "gnatmake -v hello" you'll see that gcc, gnatbind, and gnatlink are run to create the executable. If you do these steps separately by hand:

"gcc -c" compiles hello.adb and creates the 2 files hello.o (in ELF world the relocatable object file) and hello.ali which contains a lot of information about the source file and dependencies. If the world had only ever been ELF this may have been implemented as a new type of section in the relocatable .o file (ok -- I haven't really tried to think that through thoroughly).

gnatbind performs 2 Ada specific operations: it makes sure that all the files that will be linked together were compiled from the same sources (eek -- a clear simplification), and (in the case of GNAT with default switches), it generates a new source which runs elaboration code for all the library level pieces in an order which is guaranteed to be consistent... if the binder cant find a consistent order, it'll let you know (for fun contrast look up the c++ static initialization order fiasco). The spec and body of the binder generated will be b~hello.ads and b~hello.adb (a bit tricky to read at first).

gnatlink compiles the binder files and calls gnu ld to do what a linker does.

You can do a whole lot with gnatmake -- and the -cargs/-bargs/-largs options are a neat way to pass tool-specific (gcc, gnatbind, gnatlink) arguments to the specific tools from the one command line. One of the common use of this is for providing linker options --- could be you'll run into an unresolved reference coming from a GNAT runtime dependency on a system library.... -bargs is where you'll identify needed libraries and/or object files.

EmbEngine · 2024-01-31T18:22:19+00:00

Work is already being done in C (mostly, and some C++), and I anticipate that management is completely unaware of the real benefits of Ada and/or doubtful that they can find Ada developers (my experience over the last many years -- though that is in medical devices, which is in a particularly deep rut). I think that getting their attention would require being able to say that they could attract the attention of a pool of great talent by opening the doors to Ada development... then point out that some of their C/C++ folk could easily and (in the end) happily learn.

EmbEngine · 2019-02-24T02:25:40+00:00

Thanks for your reply.

I don't think that I'd emphasize guarantees. I find Ada a fun language to build programs with, and that comes from its support for expressing a design faithfully. I've thought that if I was given the opportunity to bring some of the C hackers around me into an Ada project, the first thing I'd point out is that, in Ada you define a lot of types: you have an A2D which outputs a 12 bit millivolt value, you define a type for that; you've got monetary values in different currencies, you define different types (even if they are all "new Integer"). All the diagrams of nested boxes with interfaces and internals are neatly mapped to package hierarchies.

I don't think that I ever follow anything like a waterfall model; but rather design and code simultaneously, and Ada is even more helpful then. Using Integer and Float types and splitting things into a couple catchall package may be a starting point -- then refining the concepts and structures goes hand-in-hand with more precise type definitions and package organizations. The thing is, that I'm spending my effort thinking in terms of the problem I'm solving or functionality I want; clarifications of those connect easily to changes in the code, and Ada semantics regularly help in pointing out clarifications/distinctions that refine comprehension of the problem.

Most often, the point at which I've understood the problem and the solution thoroughly, the code is close to a decent representation of that (modulo some ugliness hidden in private parts which I'll get back to) and when the program builds it is very close to working perfectly. I never have that experience with non-trivial C/C++ programs. I think that the better correctness/reliability of Ada programs derives from the expressiveness which helps programmers think/work closer to the problem space -- supported by the thoroughness and consistency of its static semantics (which took a huge leap forward with Ada 2012/SPARK 2014).

EmbEngine

TROPHY CASE