Re: Ada "library only" compiler ?

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

On 12-07-21 02:30 , Patrick wrote:
> Hi Niklas
>
> ...
>
> So just to clarify, I am not advocating an Ada interpreter, it's just
> that Lua's developers are quite resistant to implementing more then
> the tiniest set of standard libraries. Lua and all the standard
> libraries are less then 18K lines of code and they are determined to
> keep it that way. Lua programmers are supposed to rely on C.

Lua is explicitely meant to be an "extension language", to make some 
application "scriptable". The heavy application functions are meant to 
be implemented in C (or whatever the host application language is), with 
calls from and to Lua code to add flexibility.

I don't think that C libraries can be used easily to extend "Lua the 
language" with more language features.

Ada is not meant to be an extension language, but to be a full language 
in which one can implement entire applications.

So I don't quite understand why you are using Lua as a comparison. 
Perhaps we can approach this in another way, by asking you why you would 
prefer to use Ada rather than Lua? Which features of Ada are absent from 
Lua, or are better than the corresponding features in Lua? We can then 
discuss if and how these features could be implemented in the same way 
that Lua is currently implemented.

> Ada is huge

That is debatable. But even if you consider "Ada the language" to be 
huge, this just means that an Ada compiler has a lot to do, so the 
compilers are "huge" and hard to write. This is in harmony with the 
goals of the Ada language: to allow lots of compile-time checking. The 
generated code is not necessarily huge.

> and I am not proposing some sort of limit like this but I
> do think that a strategic retreat might be in order, at least for
> some of us and Lua is an example of this. There are not really that
> many libraries and bindings relative to C. If someone had a small Ada
> compiler that they knew had to be supplemented with C that might
> offer a little more clarity of purpose and perhaps leaning on C for
> library support is the better way to go for some people and a toolset
> tailor made for this might be good. Again I don't mean to bash Ada, I
> do like it a lot.

Which parts of "Ada the language" would you omit and replace by "library 
support"?

Historically, some Ada developers avoided the tasking features and 
instead used some non-Ada real-time kernel. Instead of creating 
tasks/threads with the Ada "task" keyword, they would call a kernel 
function to create the thread at run-time, providing some ordinary Ada 
subprogram as the "main function" of the thread. This can be seen as an 
example of replacing Ada language features with libraries (and, I regret 
to say, this practice still goes on in some places).

It is not so clear what other language features could profitably be 
replaced in this way. At the moment, only the fixed-point types come to 
my mind. An Ada program could avoid the Ada fixed-point types and 
instead call some fixed-point library, much like some Ada programs now 
use libraries for unbounded numbers ("bignums"). It seems to me that 
removing fixed-point types from Ada would simplify the compilers -- but 
probably not by much.

> So for instance it looks like Ada has a library to retrieve command
> line arguments.

Yes, Ada.Command_Line, a standard predefined package.

> However it looks to be just thin wrapper over ARGV and ARGC.

The services of Ada.Command_Line are similar to ARGV/ARGC, yes. This was 
a natural minimum level to provide. However, Ada.Command_Line can be 
implemented on systems that have a different method to access 
command-line parameters.

> If someone wanted to use something a little higher up like
> getopts, they could rework ARGV/ARGC out this part of their C
> boilerplate code.

An Ada program can certainly use the getopt() library function, although 
it may have to provide a C "main" function to do so (and how that is 
done depends on the Ada compiler).

> At the moment the Ada binding is there whether or
> not you use it.

So? The package Ada.Command_Line is unlikely to be linked into your Ada 
program if you don't use it explicitly. And the mere existence of this 
package is a trivial burden on the compiler. And I would bet that the 
code in this package is of trivial size.

> I am assuming there will be many more examples of
> this.

Examples of what, exactly?

If you look at the rest of the Ada predefined standard library packages, 
they either provide substantial functionality that is not standard in C 
(e.g. Ada.Calendar, Ada.Strings.Unbounded, Ada.Containers.*), or they 
are simple wrappers (e.g. Ada.Characters.Handling) for C or POSIX 
functions. The former can mostly be implemented in Ada itself, in a 
portable way; the latter can be implemented by calling system functions 
or libraries, in C or other languages. So I don't believe that the 
library packages are a significant obstacle to making Ada available on 
more devices, in particular since one can just say "sorry, my compiler 
does not (yet) support package X".

> However also as an example of my ignorance, I tried this to see if I
> could generate ASM from gnat: gnatmake -S first_procedure.adb
>
> It calls GCC right away: gcc -c -S first_procedure.adb gnatmake:
> "first_procedure.ali" WARNING: ALI or object file not found after
> compile gnatmake: "first_procedure.adb" compilation erro

GCC does not mean "GNU C Compiler", it means "GNU Compiler Collection" 
or "GNU Compiler Caller". The "gcc" program is a driver that parses the 
arguments and then calls the real compiler programs according to the 
chosen or deduced source language. The program "gnat1" is the real GNAT 
Ada compiler and gcc will call it eventually. (The program "cc1" is the 
real GNU C compiler.)

> It looks like GNAT does not generate it's own ASM but relies on GCC
> for this, so the idea of reworking GNAT into an Ada to ASM converter
> is certainly false, they must interact with an internal
> representation.

Your understanding of how GNAT and GCC work is a bit confused.

The principle is that the GNU compilers are separated into a "front end" 
part, distinct for each language, and a "back end" part that is distinct 
for each target processor. The front end for language X translates the X 
source code into the GCC internal representation; the back end for 
processor P translates the internal representation into 
assembly-language source code for P. The assembler for P then translates 
the assembly-language source code into binary machine code for P.

The Ada-specific part of GNAT is in the front end, which (as I 
understand it) is the "gnat1" program. But perhaps I should not say 
more, since I really don't know the details.

 > So at best it would be an Ada to GCC IR converter and
 > then other then a simpler to understand compiler, i guess the
 > proposal really doesn't offer much.

The core of GNAT is already an Ada-to-GCC-IR converter.

But the main point is that much of what an Ada compiler does, and most 
of what is due to the "hugeness" of Ada, does not depend on the target 
processor. When an Ada compiler sees "I+J", where I and J are some 
integer variables, it does not immediately decide to use a specific ADD 
instruction from the target processor's instruction set. Instead, after 
many checks on the legality of the expression, and after deciding which 
function called "+" is meant, the expression "I+J" is translated into 
the compiler's intermediate language and passed to the back end, which 
chooses the instructions. It may well be that the instructions chosen to 
compute I+J are quite different when the expression is used in a 
statement like K:=I+J, and when it is used in an expression like 
K:=Some_Array(I+J).

To conclude, if the goal is to make Ada available on some device D that 
is supported by the GCC back-end, then:
- most of the Ada-specific work is already done in GNAT, and
- most of the D-specific work is already done in GCC.

What is left to do is to take care of the details (where the devil is, 
of course), and implement the run-time support for Ada on device D. As 
can be seen from the AVR-Ada example, the compiler can be useful even 
with rudimentary run-time support.

If performance is not important, an alternative is to choose some 
virtual machine V, add support for that virtual machine to the GCC 
back-end, and port GNAT into an Ada-to-V compiler. The run-time system 
could then be written once, for V, and the V simulator could probably be 
written in a fairly portable way, to run on several devices with small 
adaptations. This was the JGNAT route (GNAT ported to compile Ada into 
byte code for the Java Virtual Machine). I'm not sure if JGNAT is still 
with us; it seems it had few users.

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