Re: Ada "library only" compiler ?

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 12-07-21 20:47 , Patrick wrote:

> Thanks for explaining GCC to me, I was mixed up. I assumed that each
> compiler(C, Ada, C++) got the code down to ASM to be passed off to
> GAS and GCC was a dispatcher to full blown compilers that could exist
> on their own if used with an ASM compiler.

Googling "gcc architecture" gives some promising hits, including a 
Wikibook, 
http://en.wikibooks.org/wiki/GNU_C_Compiler_Internals/GNU_C_Compiler_Architecture. 
It may not be up to date (last GCC version named there is 4.1).

> I am such a poor writer, I do seem to be having trouble explaining
> myself, let me try again.

Ok. I probably haven't understood your real point yet.

> So I spent a couple of years with Lua and my experience with it was
> that it is a language being pulled in two directions. The Lua team
> seem to think it is best used for extending and embedding in C but
> the community also want more libraries written in lua itself. The Lua
> team does not bless more then a tiny set of libraries(just a few
> thousand lines)

What do you mean by "blessing" a library? That the library is included 
in the default Lua distribution/installation? But why should this 
matter? If the Lua language itself is stable, and the library is 
available in source form with a suitable licence, just use it, blessed 
or not.

Perl is an example of a language with a huge number of libraries that 
are not included in the default distribution, but are easy to get and 
install. I haven't used Perl much, but some of the libraries that I've 
used have been good, others not so good. That's life.

> My Lua experience has left me shell-shocked and worried about using a
> lot of the Ada libraries. It took a lot of time to learn various Lua
> libraries and after finding two or three crappy ones in a row, it got
> frustrating.

The quality of free (or even commercial) libraries is always in doubt. 
Same for all languages, in principle. My experience from about 25 years 
of using Ada libraries and compilers has been generally positive. I 
haven't entirely escaped bugs, but I think that the number of compiler 
and library bugs that I have seen is about five and definitely less than 10.

> I am not saying that the same thing will be true for Ada
> but it might be nice if all the Ada binding code was in a certain
> place.

I don't understand. What "Ada binding code" do you mean?

> I like Lua still but if I am going to use it again, I am going
> to mix C libraries and Lua and pretty much forego the Lua libraries.
> It's easy enough to do this as Lua and it's tiny libraries are easy
> to keep separate.

I am still confused. How could it not be easy to "keep separate" a 
language from its libraries?

> If GNAT had a clearer separation of concerns between C and Ada, I
> could do the same with Ada or use Ada libraries when I want to but
> right now a lot seems to be bundled together and it is hard to tell
> what is binding and what is not.

The innards of GNAT are irrelevant to an Ada programmer who just uses 
GNAT to compile the program. You can mix C and Ada code in the same 
application, whether or not GNAT uses some C code internally.

Note that GCC and GNAT entirely separate the compilation of a program 
from the execution of that (compiled) program. GNAT generates an 
executable file that is then executed stand-alone, without involving 
GNAT. So what GNAT does with C code or C libraries during compilation 
has no relevance to what the compiled Ada program does with C libraries 
(if any) during execution.

> I think Ada the language itself is perfect and don't have any
> interest in changing it in any way, it's the C portion I would like
> to tinker more with.

The "C portion" of what? There is no "C portion" in the Ada language, 
except for Ada.Interfaces.C, but I hardly think that is what you mean.

> If GNAT had C split off somewhere and that code
> was "withed" into Ada code later, I might have a better understand of
> how it interacts with the OS and other topics.

Sorry, I have no idea what you mean here.

> Right now I don't know where the runtimes live or even what language
> they are written in. I don't know how they act on bare metal or with
> an OS. Keeping the syntax translation of Ada separate from
> interaction with everything else might give people like me a fighting
> chance of understand what is going on and perhaps even moving the
> language to new targets.

If your goal is to port GNAT to new targets, then of course you need to 
look into how GNAT and GCC are implemented. That is not a small task, as 
I understand it (without any experience of my own), but not out of reach 
for a reasonably skilled programmer. However, you shouldn't except much 
similarity with Lua's implementation.

Note also that if the target is a small device, then it is probably a 
good idea to make a cross-compiling GNAT which runs on an ordinary host 
machine (a PC) but generates executables for the target device. Again, 
AVR-Ada is an example.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .