Re: Ada "library only" compiler ?

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

On 12-07-20 23:05 , Patrick wrote:
> This thread could be a bit inflammatory, please bear in mind:
> -I love Ada
> -I've been with Ada for 7 months and I am only learning it.
> -Programming is not my day job

Good, but I don't think that the above either qualifies or disqualifies
you as a critic of Ada. The substance of the criticism is what matters.

> I spent a few minutes today going through GNAT internals. I was just
> planning on looking at high quality Ada code and just studying a well
> respected project.

While many Ada compilers are written in Ada, compilers are (or at least 
were) not the main kind of applications for which Ada was desiged. So 
perhaps GNAT is not a typical Ada application. But this is a bit beside 
the point.

> I was surprised to see so much C code. I know  Ada has facilities for
> low level programming but it seems to be that the momentum of C
> hasn't allowed for Ada to grow as much as it could have in this
> department. It seems to me that even within GNAT, it has just been
> easier to piggyback on C, rather then rewrite things in Ada and ASM.

I don't know much about GNAT and GCC internals, but the Ada part has to 
interface with the rest of GCC, through an interface that I assume is 
defined in C, or through files with a format defined in C terms. When 
using such interfaces from Ada, it is often easiest to write an 
application-specific, thin, in-between layer in C. This layer can then 
directly use the interface-defining C header files, without translating 
the header files to Ada (which can be a lot of work, especially if 
#defines are used a lot). Perhaps the C code you found has this role.

> So again, I don't mean to be harsh but if we are always building on C
> through the GNAT compilation progress would it be logical to decouple
> the two to create a simple Ada "as library" compiler? It seems that
> we can't open a file or get a command line argument without C
> anyways.

GNAT runs on operating systems (Windows, Linux, etc.) in which the 
Application Programming Interface is defined in C. In order to open a 
file under Linux, the application (here GNAT) *must* use the open() or 
fopen() functions, which are defined in the API as C functions. Trying 
to open a file using "low-level Ada" would be breaking the OS interface 
which is obviously a bad idea (and probably impossible because an 
application does not have the necessary low-level access rights for that).

Likewise, when a GNAT-compiled Ada program runs on Windows or Linux and 
accesses files, the GNAT-provided libraries (Ada.Text_IO etc.) must use 
the Windows/Linux C-style I/O libraries, for the same reasons.

On the other hand, when an Ada application runs in other environments, 
for example on an embedded "bare board" with only an Ada run-time 
system, there doesn't have to be any C code around. The same is (or was) 
the case on the computers that were built on Ada from the ground up, for 
example the Nokia MPS-10, where the operating system presented an Ada API.

> Lua is called a language and has it's own file extension etc but it's
> developers are open about the fact that it is not a language but a C
> library.

For sure it is a language, even if the compiler/interpreter and run-time 
are written in C, and intended for integration in C programs (and 
therefore implemented as libraries).

> Would a compiler that took this approach to the language be much
> smaller and simpler and perhaps make it easier to get Ada onto other
> devices?

I don't think so. I believe that the structure of an Ada program, and of 
its data, can be more complex and varied than for Lua. Writing an Ada 
interpreter (which is how I understand your suggestion) does not seem 
much simpler than writing a compiler, especially if the compiler can 
reuse an existing compiler's back-end, as GNAT does with GCC.

But there is at least one Ada compiler (AdaMagic) that can compile Ada 
source to C source, using C as the target language, instead of compiling 
to machine code. Through this compiler, Ada is available on most devices.

> So I am clueless at the moment as to how GNAT implements Tasking,

Tasking: on Windows/Linux by using the thread/process API of the 
underlying OS, or of some add-on library such as pthreads, with an API 
defined in C. On ORK, tasking is implemented in Ada.

> or even the Ada type system

Here I don't see any reason for GNAT to use C. The type system should be 
a front-end concern, mainly, and thus implemented in the Ada part of GNAT.

> but if I studied and eventually moved
> these to an Ada to ASM translator

Translating Ada to some assembly language in one step is a bad idea, 
both from basic engineering principles and because it makes it hard to 
support multiple targets. It is better to use an intermediate language.

> then a C boilerplate file(s) could
> implement what the Ada-as-a-language implementation would need to
> behave as a language. The C boilerplate piece would be in one place
> and could easily be reworked by anyone.
>
> Just some sleep deprived daydreaming and this would take me months if
> not years to get done at the part time pace I would have to do it at
> but would it be useful if it did get done?

I don't think so.

What would be more useful, and much easier, would be to port GNAT and 
ORK to more GCC-supported targets. Use AVR-Ada as an example.

> I really hope it will be easier one day to write
> full implementation Ada embedded code for a larger number of devices
> then it is now.

A direct Ada-to-assembler compiler is not the easier way, IMO. And an 
Ada interpreter, even if you could write one, would be too large for 
many devices, and too slow for many applications.

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