Ada "library only" compiler ?

Ada "library only" compiler ?

[Patrick]

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
-I slept 5 minutes last night, in a chair, in a hospital.
-I have good intentions, this is not meant to be hostile.

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.

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.

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.

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.

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?

So I am clueless at the moment as to how GNAT implements Tasking, OO or even the Ada type system but if I studied and eventually moved these to an Ada to ASM translator 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?

If I used the FSF code base rather then straight from Adacore the code could also be used to generate proprietary code at no cost like the FSF version can. 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.

Thanks for reading-Patrick

Re: Ada "library only" compiler ?

[Niklas Holsti]

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
       .      @       .

Re: Ada "library only" compiler ?

[Ludovic Brenta]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
> 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.

+1

>> 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.

I know a lot about GCC internals (well, not as much as AdaCore folks)
and I confirm that what you said is 100% correct.  A lot of C code in
the GNAT sources is located in the directory gcc/ada/gcc-interface;
there is a good reason for that.

You will also notice, besides the C code, a lot of Makefiles,
Makefile.in, Makefile.ac.  The build system of GCC is horribly complex
and consists of hundreds of thousands of lines of configury and
makefiles.

Niklas, everything else you said is correct, especially about the Ada
run-time library interfacing with the target operating system and
tasking.

> 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.

And package them for Debian for easy installation and use by the masses
:)

-- 
Ludovic Brenta.

Re: Ada "library only" compiler ?

[Peter C. Chapin]

On 2012-07-20 17:11, Niklas Holsti wrote:

> 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).

I don't think this is quite right. Entrance into the operating system is 
ultimately done in machine language. The C API functions you're talking 
about are thin wrappers that present a C callable interface and then do 
what must be done to actually invoke the system. For some systems "doing 
what must be done" involves executing exotic instructions that 
(standard) C compilers can't generate. Thus one supposes that functions 
like open(), etc, are written in assembly language or its moral equivalent.

This could be done for Ada. An Ada procedure could be written that wraps 
the same assembly language magic but that provides an Ada interface to 
the system... no need to use clib in that case.

Of course the system interface isn't standardized whereas the C 
interface is (POSIX). If the raw interface to the underlying system 
changed the Ada interfacing code would have to change. Of course the 
same could be said for clib (the clients of clib wouldn't have to change 
but clib itself would).

I believe there is, in fact, an Ada standard interface to POSIX-like 
systems. My understanding is that there is no requirement that says the 
implementation of that interface must be done on top of C.

Peter

Re: Ada "library only" compiler ?

[Ludovic Brenta]

Peter C. Chapin writes on comp.lang.ada:
> On 2012-07-20 17:11, Niklas Holsti wrote:
>
>> 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).
>
> I don't think this is quite right. Entrance into the operating system
> is ultimately done in machine language. The C API functions you're
> talking about are thin wrappers that present a C callable interface
> and then do what must be done to actually invoke the system. For some
> systems "doing what must be done" involves executing exotic
> instructions that (standard) C compilers can't generate. Thus one
> supposes that functions like open(), etc, are written in assembly
> language or its moral equivalent.

Just two days ago I spent some time browsing the sources of glibc to
discover how the stat(2) C library call translates to a _stat64 kernel
call then converts the 64-bit result back to 32-bit, explicitly detects
overflows, sets ERRNO and returns a status code (0=success, -1=error).
This alone involves several dozen lines of C, interspersed with dozens
of #define, #ifdef and #endif.  glibc must work at least with Linux,
kFreeBSD and HURD.  This increases its complexity and would likewise
increase the complexity of a raw Ada-to-kernel interface.

Add to this that glibc has maintained strict binary compatibility since
January 1997, resorting to more magic ("symbol versioning") that most
anyone would care to learn about.  Achieving the same thing in Ada would
require a careful definition of "semantic dependence" such that
recompiling the kernel-interface library does not systematically
invalidate all compilation units that depend on it, per ARM 10.1.4(5).
IOW, magic at the source level in addition to the binary level.

So the conclusion is: while it is theoretically possible to write an Ada
run-time library that interfaces directly with the kernel, it is
practically undesirable.  The huge effort required would bring almost no
benefit and should be spent elsewhere.

For the same reason, Florist (the free implementation of POSIX.3) uses C
wrappers and the C library.

-- 
Ludovic Brenta.

Re: Ada "library only" compiler ?

[Patrick]

Hi Niklas

Thanks for your detailed answer. I am sure you are right about all of this but if you don't mind chatting about it a little more, I could learn a lot.

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.

Ada is 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.

So for instance it looks like Ada has a library to retrieve command line arguments. However it looks to be just thin wrapper over ARGV and ARGC. 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. At the moment the Ada binding is there whether or not you use it. I am assuming there will be many more examples of this.

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

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. 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.

Re: Ada "library only" compiler ?

[Patrick]

Thanks Denn_s

Yes, an Ada to C compiler would be great but it looks like there are not any open source +  modern Ada ones around. The fact that AdaMagic got eaten by Adacore might also indicate it's hard to implement modern Ada this way.

Re: Ada "library only" compiler ?

[Randy Brukardt]

"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message 
news:a6tvrmFdinU1@mid.individual.net...
...
>> 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.

This isn't quite right. Janus/Ada contains 0% C code (there is not a single 
line of C in Janus/Ada, the only exception being the never released Sun OS 
compiler and some parts that Unisys built for their hardware). That's true 
even on Windows. The Windows Win32 API does not require using any C code; it 
can be accessed directly. (Even the calling convention is not "C", it's 
"StdCall" which originally was "Pascal" until Microsoft got rid of their 
Pascal compiler.)

It's true that the Win32 API is defined in C, but an Ada system can 
interface directly to it without using any intermediate C code.

(Truth-in-advertising statement: Janus/Ada does link with the C runtime; we 
only use that for program initialization, as Microsoft does not document [at 
least the last time I looked] the state that a raw executable starts in. One 
thing is clear: that initial state does not include Standard_Input and 
Standard_Output, which makes it hard to do much! Anyway, we don't use an C 
APIs in our executable files. I'd (optionally) dispense with the C runtime 
if I knew how to do the needed initialization.)

Janus/Ada is written solely in Ada; the Janus/Ada runtime is about 95% in 
Ada and 5% in assembler.

                                           Randy.


                                                   Randy.

Re: Ada "library only" compiler ?

[Randy Brukardt]

"Ludovic Brenta" <ludovic@ludovic-brenta.org> wrote in message 
news:87mx2ucags.fsf@ludovic-brenta.org...
> Peter C. Chapin writes on comp.lang.ada:
...
> So the conclusion is: while it is theoretically possible to write an Ada
> run-time library that interfaces directly with the kernel, it is
> practically undesirable.  The huge effort required would bring almost no
> benefit and should be spent elsewhere.

You're talking specifically about Linux, and you should make this fact 
clear.

Janus/Ada 83 for SCO Unix directly accessed the kernel traps. This was made 
necessary by the fact that we hadn't invented any way to do C interfacing, 
and by that point were waiting to see how Ada 9x would handle that before 
doing anything. (This was about 1991, I think.) This compiler could only do 
Ada, and still could do pretty much any Unix operations that were needed.

And of course, the situation on Windows is very different. The basic OS API 
(Win32) is defined via a set of DLL interfaces that are consistent across 
all modern versions of Windows specifically so binary compatibility is 
possible. No C is really required there, either.

                                                Randy.

Re: Ada "library only" compiler ?

[Dmitry A. Kazakov]

On Fri, 20 Jul 2012 19:27:25 -0500, Randy Brukardt wrote:

> It's true that the Win32 API is defined in C,

The stdcall convention indicates that it is not all C. At least in the
beginning it was something else.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada "library only" compiler ?

[Niklas Holsti]

On 12-07-21 01:25 , Peter C. Chapin wrote:
> On 2012-07-20 17:11, Niklas Holsti wrote:
>
>> 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).
>
> I don't think this is quite right. Entrance into the operating system is
> ultimately done in machine language. The C API functions you're talking
> about are thin wrappers that present a C callable interface and then do
> what must be done to actually invoke the system.

You are right, in principle, and I was simplifiying. With "low-level 
Ada" I meant accessing machine-level stuff like I/O ports.

> For some systems "doing what must be done" involves executing exotic
> instructions that (standard) C compilers can't generate.

I would guess that they mostly use assembly-code insertions in C source.

> Thus one supposes that functions  like open(), etc, are written in
> assembly language or its moral equivalent.
>
> This could be done for Ada. An Ada procedure could be written that wraps
> the same assembly language magic but that provides an Ada interface to
> the system... no need to use clib in that case.

True, and Randy Brukardt says in a later post they did it in that way 
for the Janus/Ada compiler on SCO Unix.

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

Re: Ada "library only" compiler ?

[Pascal Obry]

Randy,

> And of course, the situation on Windows is very different. The basic OS API 
> (Win32) is defined via a set of DLL interfaces that are consistent across 
> all modern versions of Windows specifically so binary compatibility is 
> possible. No C is really required there, either.

I don't see your point. Interfacing to a DLL is just like interfacing to
C or whatever. In fact the Win32 DLL API are in C, same on Linux where
the lib C is used, no? On Windows you interface to fopen() as done on
UNIXes I suppose or maybe to an even higher level using OpenFile().

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada "library only" compiler ?

[Niklas Holsti]

On 12-07-21 02:22 , Dennis Lee Bieber wrote:
> On Sat, 21 Jul 2012 00:11:18 +0300, Niklas Holsti
> <niklas.holsti@tidorum.invalid> declaimed the following in
> comp.lang.ada:
>
>> On 12-07-20 23:05 , Patrick wrote:
>
> 	<snips>
>
>> 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.
>>
> 	As I recall, that is also how the first qualified Ada compiler
> worked -- the NYU/AdaEd translator converted Ada to C source code.

My understanding is that the first version of Ada/Ed was an interpreter 
written in the SETL language, and a later version was an interpreter 
written in C, but not a translator to C. See 
http://www2.informatik.uni-stuttgart.de/iste/ps/AdaBasis/pal_1195/ada/userdocs/html/cardcat/adaed.html.

Perhaps the C implementation of Ada/Ed is close to what the OP, Patrick, 
has in mind: a C program (that could be presented as a library) that can 
execute Ada programs.

>>> 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.
>
> 	The main hang-up would be creating some sort of transportable Ada
> run-time to handle the core I/O devices and tasking system. At the
> minimum, you (all of you) are talking the equivalent of a portable BIOS
> system (and look how rapidly M$ operating systems had to find ways to
> bypass said "common" BIOS).

It is well known how to make semi-portable tasking systems -- look at 
all the RT kernels that support multiple processors. For Ada, the Open 
Ravenscar Kernel ORK should be a good point to start from.

IMO there is no well-defined set of "core I/O devices" for embedded 
systems and other kinds of "devices" such as handsets. Ok, most systems 
that interact with the user have some kind of text I/O that could be 
provided as Ada.Text_IO, but some have nothing else; some have only 
volatile memory, while some have non-volatile storage with files and 
directories, etc. I don't see a need for a BIOS, portable or not; 
rather, each device would have its own set of I/O packages. I think that 
is the case for GNAT on Lego Mindstorms.

If we are talking about a portable Ada interpreter (I'm not sure that we 
are), it could perhaps link dynamically to the device-specific I/O 
packages, as plug-ins.

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

Re: Ada "library only" compiler ?

[Niklas Holsti]

On 12-07-21 03:27 , Randy Brukardt wrote:
> "Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
> news:a6tvrmFdinU1@mid.individual.net...
> ...
>>> 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.
>
> This isn't quite right. Janus/Ada contains 0% C code (there is not a single
> line of C in Janus/Ada, the only exception being the never released Sun OS
> compiler and some parts that Unisys built for their hardware). That's true
> even on Windows. The Windows Win32 API does not require using any C code; it
> can be accessed directly. (Even the calling convention is not "C", it's
> "StdCall" which originally was "Pascal" until Microsoft got rid of their
> Pascal compiler.)
>
> It's true that the Win32 API is defined in C, but an Ada system can
> interface directly to it without using any intermediate C code.

Sure. I didn't say that the compiler or other Ada program must contain 
some C source; I said that it must use the OS API, which is almost 
always defined in C (unless it chooses to use the low-level, 
machine-specific OS-invocation mechanisms, as Peter Chapin pointed out).

Still, I have sometimes found it easier to write a thin interface layer 
in C, as I also said, just to have a simpler Ada/C interface.

> Janus/Ada is written solely in Ada; the Janus/Ada runtime is about 95% in
> Ada and 5% in assembler.

But you still use the Win32 C API and its services, translated into Ada 
form. Which is nice, if you can afford the effort (including the 
maintenance effort).

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

Re: Ada "library only" compiler ?

[Niklas Holsti]

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
       .      @       .

Re: Ada "library only" compiler ?

[Patrick]

Hi Again Niklas

Thanks for spending so much time with me on this.

"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."

Good point, I'm totally wrong here

I only meant that the Ada language is huge, I didn't mean to say anything bad about the final executable.

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.

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

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) and there is no official way to do many things such as serializing data.

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. 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 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.

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.


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.  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.

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.

Thanks again-Patrick

Re: Ada "library only" compiler ?

[Simon Wright]

Patrick <patrick@spellingbeewinnars.org> writes:

> 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.

You might find this (somewhat old, being based on GNAT 3.15p) document
helpful to give you a flavour.

http://www.iuma.ulpgc.es/users/jmiranda/gnat-rts/gnat-rts.pdf

Re: Ada "library only" compiler ?

[Patrick]

thanks Simon, this is sure to help

Re: Ada "library only" compiler ?

[Brian Drummond]

On Sat, 21 Jul 2012 10:47:26 -0700, Patrick wrote:


> The Lua team does not
> bless more then a tiny set of libraries(just a few thousand lines) and
> there is no official way to do many things such as serializing data.
> 
> 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. 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.

If the language developers do not (much) endorse Lua libraries, then the 
available libraries are likely to be poor!

Ada is strongly intended to support code re-use. Its package facilities 
encourage design for re-use, and re-using already-proven code is one good 
way to reduce the defect rate in a program.

So I would expect your experience with Ada libraries to be better.

(Perfection is not guaranteed however. There don't seem to be many uses 
of the AVR-Ada libraries supporting the AVR processors yet. So I am 
finding missing or incorrect features in some of these, but so far they 
are easy to find or fix)

> 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.

Rather than writing a C library, it's probably easy to write an Ada 
library, exporting its functionality via "convention C", and then access 
it in Lua... 

I have not done this, but I have imported C into Ada, and exported Ada 
functionality into a (C++) program. It's reasonably easy (the C/C++ main 
needs to call adainit and adafinal functions) but some messing with 
makefiles is involved to tie them together.

You would probably need a minimal C wrapper to call adainit and adafinal 
functions, accessible from Lua. (Or if you can start the Lua code from a 
C main, it may be as easy to start it from Ada instead). But no messing 
about inside the compiler should be needed.

> 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.

I think the lack of separation may work FOR you in the above case...

- Brian

Re: Ada "library only" compiler ?

[Patrick]

Hi Brian

Thanks for your feedback 
Yes, thankfully with the help of people on the list I can work in both directions with C and Ada now and as such could write code in Ada and export it as C for use with other languages like Lua.

On another note I ran sloccount on glibc and it's over 900K lines of code. Newlib is about half that but is still mind crushingly huge. C is smaller then Ada. It must be even harder to create a runtime for it. I am hopelessly out of my league. Reworking GNAT a little bit  is one thing, writing runtimes looks like a totally different story :( 

Re: Ada "library only" compiler ?

[Shark8]

On Saturday, July 21, 2012 6:39:59 AM UTC-6, Pascal Obry wrote:
> Randy,
> 
>> And of course, the situation on Windows is very different. The basic OS API 
>> (Win32) is defined via a set of DLL interfaces that are consistent across 
>> all modern versions of Windows specifically so binary compatibility is 
>> possible. No C is really required there, either.
> 
> I don't see your point. Interfacing to a DLL is just like interfacing to
> C or whatever.

No, not really. The whole point of dynamic- vs. static-linking [libraries] is that in the case of the former it eliminates the need to recompile [your application] if the underlying DLL's implementation is changed, with static-linking this is not so, any change in the library mandates a recompile/relink of your application.

It's somewhat like the interface/body separate compilation in Ada but applied to the software-system instead of the language/compiler-system.

With interfacing to another language the compiler has to know certain things about that language, most specifically symbol-generation, argument ordering and calling-conventions. {This is the whole reason for the convention pragma.}

> In fact the Win32 DLL API are in C, same on Linux where
> the lib C is used, no? On Windows you interface to fopen() as done on
> UNIXes I suppose or maybe to an even higher level using OpenFile().

Not necessarily. So long as the Win32 API DLL presents the same interface to the world its internals could be ASM, Prolog, Ada, LISP, etc. And so long as the compiler is able to generate calls/returns to properly interface with the DLL the actual language of the compiler doesn't matter either.

Re: Ada "library only" compiler ?

[Pascal Obry]

Le 22/07/2012 06:59, Shark8 a �crit :

> No, not really. The whole point of dynamic- vs. static-linking
> [libraries] is that in the case of the former it eliminates the need
> to recompile [your application] if the underlying DLL's
> implementation is changed, with static-linking this is not so, any
> change in the library mandates a recompile/relink of your
> application.

Yes I know, but we are talking about API there. If the API change the
fact that we are using a DLL instead of plain C code does not change
this fact.

> With interfacing to another language the compiler has to know certain
> things about that language, most specifically symbol-generation,
> argument ordering and calling-conventions. {This is the whole reason
> for the convention pragma.}

Likewise for DLL, the convention must be Stdcall. And for C it can be
defined as C, Stdcall (to name only those 2).

> Not necessarily. So long as the Win32 API DLL presents the same
> interface to the world its internals could be ASM, Prolog, Ada, LISP,
> etc.

So long that the C code provides the same API with the same convention...

> And so long as the compiler is able to generate calls/returns to
> properly interface with the DLL the actual language of the compiler
> doesn't matter either.

Right.

Again at the API level I really don't see what the difference here. The
API definition has nothing to do with DLL. The API is defined by the
vendor or the library implementer. Then this code can be delivered
statically or as a shared library, it is only a way to encapsulate the code.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada "library only" compiler ?

[Florian Weimer]

* Pascal Obry:

> I don't see your point. Interfacing to a DLL is just like interfacing to
> C or whatever. In fact the Win32 DLL API are in C, same on Linux where
> the lib C is used, no? On Windows you interface to fopen() as done on
> UNIXes I suppose or maybe to an even higher level using OpenFile().

There are different types of functions.  For example, fopen is
implemented in user space, while open just moves the arguments into
the right positions and invokes the transition to kernel space, and
sets errno based on the result.  (This is roughly the difference
between section 3 and section 2 of the manual pages.)  Functions like
open are not implemented in C on the user space side.  Whether the
kernel language still counts as C, I'm not sure.

Re: Ada "library only" compiler ?

[Brian Drummond]

On Sat, 21 Jul 2012 20:25:48 -0700, Patrick wrote:

> Hi Brian
> 
> Thanks for your feedback Yes, thankfully with the help of people on the
> list I can work in both directions with C and Ada now and as such could
> write code in Ada and export it as C for use with other languages like
> Lua.

I can now call Lua from Ada. 
Calling Ada from Lua ought to work, but I haven't tried it yet.

I downloaded Lua 5.21 today and tried this (c) example
http://lua-users.org/wiki/SimpleLuaApiExample

I needed to modify the compile process a little (linking with -ldl) to 
overcome missing "dlopen" etc functions; after that, it worked as 
expected. Then I made a basic port of the example to Ada.

This port uses a "thin binding", which can be (mostly) auto-generated by 
GCC, using the -fdump-ada-spec[-slim] option. (This assumes gcc4.6.1 or 
later)

gcc -fdump-ada-spec ../lua-5.2.1/install/include/lua.h
gcc -fdump-ada-spec ../lua-5.2.1/install/include/lauxlib.h
gcc -fdump-ada-spec ../lua-5.2.1/install/include/lualib.h

This builds package spec files (lua_h.ads, etc) for these header files. 
Without -slim, actually the transitive closure of all the headers they 
include, which can get VERY large. (This is not a problem with the tools, 
just a reflection of the disastrous character of C's #include mechanism)

It is probably better to use -slim, and collect the (few) missing 
dependencies into one small additional package. But for Lua, the closure 
only generated 11 files, so I didn't try for this experiment.

Now there are a few problems with this binding; two trivial, one large, 
because -fdump-ada-spec cannot parse everything in every header file.
I am detailing these below in case you want to reproduce the result.

Small problems (minimising the dependencies would eliminate these): 
(1) compiling lauxlib_h.ads reports 
"lauxlib_h.ads:289:25: "FILE" not declared in "stdio_h"
Workaround : comment out the problematic declaration (type luaL_Stream) 
in lauxlib_h.ads. (I can't see the problem)
(2) compiling libio_h.ads reports
libio_h.ads:49:28: "anon652_anon676_array" is undefined
libio_h.ads:58:27: "anon652_anon679_array" is undefined
which turns out to be missing declarations for fields in a record

   type u_IO_FILE is record
...
      u_shortbuf : aliased anon652_anon676_array;  
...
      u_unused2 : aliased anon652_anon679_array;  
   end record;

Considering that one of these fields is declared in C as
--------------------------------------------------------
  /* Make sure we don't get into trouble again.  */
  char _unused2[15 * sizeof (int) - 4 * sizeof (void *) 
	- sizeof (size_t)];
--------------------------------------------------------
I can't blame -fdump-ada-spec for failing to translate it!

Workaround : add subtype declarations ahead of the record decln in 
libio_h.ads, as follows... (size was experimentally determined)
subtype anon652_anon676_array is Interfaces.C.char_array (0 .. 0);
subtype anon652_anon679_array is Interfaces.C.char_array (0 .. 39);
   type u_IO_FILE is record ...

Bigger problem : -fdump-ada-spec can't translate macros; they just don't 
have enough context to define their meaning.

I have resolved this by adding a new package, lua_macros (below), to 
define constants, procedures and functions to replace the missing macros. 
(There are probably 150 missing macros; I have only replaced enough to 
run this example, but the remainder are mostly boilerplate)

Then a straight port of the test program (below) works as expected.
I have left all the gory details explicit in the source; a few "use" 
clauses would make it much more readable.

A better approach would be a thick binding, another package which uses 
these, but hides all the C interface details internally and provides a 
clean Ada interface to application code.

-------- output --------------------------------------------------
./test
The table the script received from the Ada main has:
1	2
2	4
3	6
4	8
5	10
Returning data back to Ada
Script returned: 3.00000E+01
Success

--------- source ---------------------------------------------------

with Interfaces.C.Strings; use Interfaces.C;

with lua_h;
with lauxlib_h;
with lua_macros;
with lualib_h; -- why didn't the C version need to #include lualib.h?

with Ada.Text_Io; use Ada.Text_Io;

-- http://lua-users.org/wiki/SimpleLuaApiExample

procedure test is
    status, result 	: Interfaces.C.int;
    sum 		: Interfaces.C.double;
    L	 		: lua_macros.lua_State_Ptr;

begin

    L := lauxlib_h.luaL_newstate;

    lualib_h.luaL_openlibs(L); -- /* Load Lua libraries */

    status := lua_macros.luaL_loadfile(L, 
				Strings.New_String("script.lua"));
    if status /= 0 then 
        -- If something went wrong, error is at the top of the stack 
        Put_Line("Couldn't load file: " & 
		Strings.Value(lua_macros.lua_tostring(L, -1)));
        raise Program_Error;
    end if;

    lua_macros.lua_newtable(L);

    for i in 1 .. 5 loop
        lua_h.lua_pushnumber(L, double(i));   	-- /* Push the table 
index */
        lua_h.lua_pushnumber(L, double(i*2)); 	-- /* Push the cell value 
*/
        lua_h.lua_rawset(L, -3);      		-- /* Stores the pair in 
the table */
    end loop;

    -- /* By what name is the script going to reference our table? */
    lua_h.lua_setglobal(L, Strings.New_String("foo"));

    -- /* Ask Lua to run our little script */
    result := lua_macros.lua_pcall(L, 0, lua_macros.LUA_MULTRET, 0);
    if result /= 0 then
        Put_Line("Failed to run script: "& 
		Strings.Value(lua_macros.lua_tostring(L, -1)));
        raise Program_Error;
    end if;

    -- /* Get the returned value at the top of the stack (index -1) */
    sum := lua_macros.lua_tonumber(L, -1);

    Put_Line("Script returned:"  & float'image(float(sum)));

    lua_macros.lua_pop(L, 1);  	-- /* Take returned value off stack */
    lua_h.lua_close(L);   	-- /* Cya, Lua */

    Put_Line("Success");

end test;

--------- macro spec ---------------------------------------------------
with lua_h;
with System;
with Interfaces.C.Strings;
use Interfaces.C;

package lua_macros is

-- missing macros from lua_h

   --  skipped empty struct lua_State ... lua.h
   subtype lua_State_Ptr is System.Address;

   -- /* option for multiple returns in 'lua_pcall' and 'lua_call' */
   -- #define LUA_MULTRET	(-1)
   LUA_MULTRET : constant Interfaces.C.Int := -1;

   -- #define lua_pcall(L,n,r,f) lua_pcallk(L, (n), (r), (f), 0, NULL)
   function lua_pcall (	L : lua_State_Ptr; 
			n : Interfaces.C.int;
			r : Interfaces.C.int;
			f : Interfaces.C.int ) 
   			return Interfaces.C.int;

   -- #define lua_pop(L,n)		lua_settop(L, -(n)-1)
   procedure lua_pop (L : lua_State_Ptr; n : Interfaces.C.int); 

   -- #define lua_tonumber(L,i)	lua_tonumberx(L,i,NULL)
   function lua_tonumber (L : lua_State_Ptr; i : Interfaces.C.int) 
	return lua_h.lua_Number; 

   -- #define lua_newtable(L)	lua_createtable(L, 0, 0)
   procedure lua_newtable (L : lua_State_Ptr);

   -- #define lua_tostring(L,i)	lua_tolstring(L, (i), NULL)
   function lua_tostring
     (L : lua_State_Ptr;
      i : Interfaces.C.int) return Interfaces.C.Strings.chars_ptr; 

-- missing macros from lauxlib_h

   -- #define luaL_loadfile(L,f)	luaL_loadfilex(L,f,NULL)
   function luaL_loadfile
     (L : lua_State_Ptr;
      f : Interfaces.C.Strings.chars_ptr ) return Interfaces.C.int;

end lua_macros;
--------- macro body ---------------------------------------------------
with lauxlib_h;
with lua_h;
with System;
with Interfaces.C;

package body lua_macros is

   function lua_pcall (	L : lua_State_Ptr; 
			n : Interfaces.C.int;
			r : Interfaces.C.int;
			f : Interfaces.C.int ) 
   			return Interfaces.C.int is
   begin
      return lua_h.lua_pcallk(L, n, r, f, 0, NULL);
   end lua_pcall;

   procedure lua_pop (L : lua_State_Ptr; n : Interfaces.C.int) is
   begin
      lua_h.lua_settop(L, -(n)-1);
   end lua_pop;

   function lua_tonumber (L : lua_State_Ptr; i : Interfaces.C.int) 
	return lua_h.lua_Number is
   begin
      return lua_h.lua_tonumberx(L, i, NULL);
   end lua_tonumber;

   procedure lua_newtable (L : lua_State_Ptr) is
   begin
      lua_h.lua_createtable(L, 0, 0);
   end lua_newtable;

   function lua_tostring
     (L : lua_State_Ptr;
      i : Interfaces.C.int) return Interfaces.C.Strings.chars_ptr is
   begin
      return lua_h.lua_tolstring(L, (i), NULL);
   end lua_tostring;

   function luaL_loadfile
     (L : lua_State_Ptr;
      f : Interfaces.C.Strings.chars_ptr ) return Interfaces.C.int is
   begin
   	return lauxlib_h.luaL_loadfilex
(L,f,Interfaces.C.Strings.Null_Ptr);
   end luaL_loadfile;

end lua_macros;
--------- end        ---------------------------------------------------

Re: Ada "library only" compiler ?

[Brian Drummond]

On Sun, 22 Jul 2012 17:54:02 +0000, Brian Drummond wrote:

> On Sat, 21 Jul 2012 20:25:48 -0700, Patrick wrote:
> 
>> Hi Brian

> I can now call Lua from Ada.
> Calling Ada from Lua ought to work, but I haven't tried it yet.
> 
> I downloaded Lua 5.21 today and tried this (c) example
> http://lua-users.org/wiki/SimpleLuaApiExample
> Then I made a basic port of the example to Ada.

oops, previous post should have included the build instructions for 
completeness... (adjust paths as necessary)

gnatmake test.adb -L../lua-5.2.1/install/lib -largs -llua -largs -lm -
largs -ldl

- Brian

Re: Ada "library only" compiler ?

[Patrick]

Hi Brian

Thanks for sharing your Lua experiments :) Lua could be quite valuable for some Ada projects. It might be very handy if one wants to give end users the power to change some functionality.

Re: Ada "library only" compiler ?

[Brian Drummond]

On Sun, 22 Jul 2012 11:44:09 -0700, Patrick wrote:

> Hi Brian
> 
> Thanks for sharing your Lua experiments :) Lua could be quite valuable
> for some Ada projects. It might be very handy if one wants to give end
> users the power to change some functionality.

See also http://lua-users.org/wiki/BindingCodeToLua
which has two (broken!) links to previous Ada bindings.

- Brian

Re: Ada "library only" compiler ?

[Niklas Holsti]

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
       .      @       .

Re: Ada "library only" compiler ?

[Niklas Holsti]

On 12-07-22 06:25 , Patrick wrote:

> On another note I ran sloccount on glibc and it's over 900K lines of
> code. Newlib is about half that but is still mind crushingly huge.

Why do you care? As a programmer, you only have to understand the API, 
not the library implementation. And any one of your programs is likely 
to use only a small part of the library, and the linker will omit the 
unused parts (if you use static linking).

If you worry about porting the library to another target, that should 
not be very hard, since these libraries have been ported to lots of 
targets already.

> C is smaller then Ada. It must be even harder to create a runtime for
> it.

That is curious reasoning; the run-time is needed to support language 
features, so why should a simpler lanhuage need a more complex run-time?

As I understand it, the difficult parts of the Ada runtime are the 
run-time aspects of tasking, exceptions, the management of dynamically 
sized data, and perhaps finalization. C has none of these language 
features. The C runtime only has to initialize statically allocated 
data, set up the stack, and call main(). Well, there are some fairly 
complex library functions that can be considered part of the runtime, 
such as atexit() and setjmp()/longjmp(). But an implementation of C 
without those functions would probably be acceptable to many users, if 
the target is some small device.

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

Re: Ada "library only" compiler ?

[Patrick]

Hi Niklas

I've been reading Ada books for 7 months and writing on IRC and here for 7 months as well. What I have not been doing enough of is reading other people's Ada code and writing my own Ada code.

I have been basically trying to say that GNAT and the compilation process could perhaps be improved for those who wish to tinker more with the process. However I think it would be better for everyone if I spent more time reading GNAT internals. Even at my skill level I am finding it surprisingly easy to understand. 500K lines of code will take some time but it's mostly Ada, not C. I fell on my face trying to read the 18K lines of C code that Lua is built from.

I also have several projects I have not started or postponed, I better get back to these.

I'll dig this thread up again in 6 months when I have more knowledge and can explain myself better

Re: Ada "library only" compiler ?

[Miles Bader]

Patrick <patrick@spellingbeewinnars.org> writes:
> 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.

No comment on the rest of your post, but the above is just wrong, so I
will correct you.

Lua is very well designed for use as a extension language, and that
(along with other attributes such as small size, speed, etc) has made
it popular in such a role, but it also works great as a "normal"
standalone language.

-miles

-- 
97% of everything is grunge

Re: Ada "library only" compiler ?

[Simon Wright]

Brian Drummond <brian@shapes.demon.co.uk> writes:

> On Sun, 22 Jul 2012 23:01:18 +0100, Simon Wright wrote:
>
>> Brian Drummond <brian@shapes.demon.co.uk> writes:
>> 
>>> I can now call Lua from Ada.
>>> Calling Ada from Lua ought to work, but I haven't tried it yet.
>> 
>> The port at https://github.com/io7m/coreland-lua-ada seems not to have
>> been looked at for a while.
>
> Nevertheless, it looks like a much better starting point than my 
> experiments.

It does seem very complicated, though!

Re: Ada "library only" compiler ?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:500AA31F.8060004@obry.net...
>> And of course, the situation on Windows is very different. The basic OS 
>> API
>> (Win32) is defined via a set of DLL interfaces that are consistent across
>> all modern versions of Windows specifically so binary compatibility is
>> possible. No C is really required there, either.
>
> I don't see your point. Interfacing to a DLL is just like interfacing to
> C or whatever.

Yes and no. It's like *interfacing* to C, but there is no C code used in 
such interfacing. (The C-language description of the APIs is converted into 
Ada interfaces, and only those are called by the compiler.)

> In fact the Win32 DLL API are in C, same on Linux where
> the lib C is used, no?

The language that the OS is written in is irrelevant, no program can see 
that in any case.

> On Windows you interface to fopen() as done on
> UNIXes I suppose or maybe to an even higher level using OpenFile().

Definitely not. We directly use the Win32 APIs for file functions (and there 
is not one called fopen). The Win32 API is called "CreateFile", and it is 
nothing much like the one from Unix or the one for C.

We have out own abstraction package (called "Basic_IO") that abstracts the 
underlying I/O facilities. Remember, we started out on CP/M and MS-DOS 1.0, 
neither of which had anything remotely like the Unix file operations.

As I mentioned, we don't use any code written in C in our compiler; it's all 
written in Ada or assembler. And we directly interface to the lowest-level 
APIs that the OS defines - Win32 for 32-bit Windows. This matters mainly 
because it means we aren't dragging in runtimes from other compilers - which 
usually allows us to generate programs as small as possible.

                                   Randy.

Re: Ada "library only" compiler ?

[Brian Drummond]

On Mon, 23 Jul 2012 11:10:44 +0100, Simon Wright wrote:

> Brian Drummond <brian@shapes.demon.co.uk> writes:
> 
>> On Sun, 22 Jul 2012 23:01:18 +0100, Simon Wright wrote:
>>
>>> Brian Drummond <brian@shapes.demon.co.uk> writes:
>>>> Calling Ada from Lua ought to work, but I haven't tried it yet.
>>> 
>>> The port at https://github.com/io7m/coreland-lua-ada seems not to have
>>> been looked at for a while.
>>
>> Nevertheless, it looks like a much better starting point than my
>> experiments.
> 
> It does seem very complicated, though!

The Ada part looks fine to me, on a quick inspection. But at least 75% of 
it seems to be shell scripts and configuration files for building and 
installation. I wonder how much of that complexity is really necessary?

If I wanted Lua-Ada bindings I think I would start there, extract the Ada 
files and use a much simpler (admittedly less general) build process. I 
suspect it would be much easier to adapt and maintain.

- Brian

Re: Ada "library only" compiler ?

[Pascal Obry]

Randy,

>> On Windows you interface to fopen() as done on
>> UNIXes I suppose or maybe to an even higher level using OpenFile().
> 
> Definitely not. We directly use the Win32 APIs for file functions (and there 
> is not one called fopen). The Win32 API is called "CreateFile", and it is 
> nothing much like the one from Unix or the one for C.

So that's more a Definitely yes, OpenFile() is a Win32 API call too.

> We have out own abstraction package (called "Basic_IO") that abstracts the 
> underlying I/O facilities. Remember, we started out on CP/M and MS-DOS 1.0, 
> neither of which had anything remotely like the Unix file operations.
> 
> As I mentioned, we don't use any code written in C in our compiler; it's all 
> written in Ada or assembler. And we directly interface to the lowest-level 
> APIs that the OS defines - Win32 for 32-bit Windows.

Depending on your view, the Win32 API is not the lowest API on windows
to me. Anyway, what you are describing is exactly what is done in GNAT
(and I know pretty well this part!). But looks like you've changed your
arguments, it was about DLL better that interfacing to C. That's what I
was having difficulty to understand. Now you are talking API (be it
Win32 or libc or whatever OS level API) and that's ok to me.

I said:

   Interfacing to a DLL is just like interfacing to C or whatever.

And I still stand on it. DLL is a container, nothing to do with an API.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada "library only" compiler ?

[Vasiliy Molostov]

Pascal Obry <pascal@obry.net> писал(а) в своём письме Tue, 24 Jul 2012  
20:50:25 +0400:

>
> Randy,
>
>>> On Windows you interface to fopen() as done on
>>> UNIXes I suppose or maybe to an even higher level using OpenFile().
>>
>> Definitely not. We directly use the Win32 APIs for file functions (and  
>> there
>> is not one called fopen). The Win32 API is called "CreateFile", and it  
>> is
>> nothing much like the one from Unix or the one for C.

> I said:
>
>    Interfacing to a DLL is just like interfacing to C or whatever.
>
> And I still stand on it. DLL is a container, nothing to do with an API.
>
> Pascal.
>

Perhaps I am out of the subject, but these are definitely different  
things. Interfacing to any Win32 DLL is much simpler (since there are only  
linkable objects and clearly specified data structures), than interfacing  
to C, where access to linkable objects are not enough, due to C standard  
preprocessor defined constructs, constants and variables. I mean that  
interfacing to C is not the same as interfacing any other library object.

Since DLL is from MS land, there is no posix compatible interface to  
attach (last news from ms presented that posix will not be supported any  
more) - and it is for now. You can imagine what that C interfacing on MS  
windows was a mess in 90's.

Also, please, pay attention to the fact that C in that time was very  
non-portable for that moment, and probably for now, and indeed it is one  
of reasons why we are writing about Ada here, as a portable programming  
language.

Probably, you mean that formally writing source code interface is the same  
as for DLL and C, but practically these are not even like each other.

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada "library only" compiler ?

[Pascal Obry]

Vasiliy,

> Perhaps I am out of the subject, but these are definitely different
> things. Interfacing to any Win32 DLL is much simpler (since there are
> only linkable objects and clearly specified data structures),

I'm probably living in another land then. The above does not makes sense
at all to me. There is no clearly specified data structures or whatever.
A DLL is a container. To use it one need to interface to it, from Ada,
from C, from Pascal, from Python... And for this you need to have a
stable and clear API which has nothing to do with DLL.

The Microsoft Win32 code happen to be in DLLs, but the same code could
be provided as static library. No more or less problem. The same API,
the same way to use it, the same need for an interface to it in C, Ada,
Pascal, Python...

Or we are really not speaking about the same thing...

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|    http://www.obry.net  -  http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: Ada "library only" compiler ?

[Vasiliy Molostov]

Pascal Obry <pascal@obry.net> писал(а) в своём письме Wed, 25 Jul 2012  
01:30:58 +0400:

> Vasiliy,
>
>> Perhaps I am out of the subject, but these are definitely different
>> things. Interfacing to any Win32 DLL is much simpler (since there are
>> only linkable objects and clearly specified data structures),
>
> I'm probably living in another land then. The above does not makes sense
> at all to me. There is no clearly specified data structures or whatever.
> A DLL is a container. To use it one need to interface to it, from Ada,
> from C, from Pascal, from Python... And for this you need to have a
> stable and clear API which has nothing to do with DLL.

If the difference is not clear to you, it can not mean that it  
non-existent at all. Probably the logic is still the same in that another  
land, is not?


-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Ada "library only" compiler ?

[J-P. Rosen]

Le 22/07/2012 20:44, Patrick a �crit :
> Hi Brian
> 
> Thanks for sharing your Lua experiments :) Lua could be quite valuable for some Ada projects. It might be very handy if one wants to give end users the power to change some functionality.
> 
It didn't seem to change for the last two years, but did you try
https://github.com/io7m/coreland-lua-ada ?

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada "library only" compiler ?

[Randy Brukardt]

"Pascal Obry" <pascal@obry.net> wrote in message 
news:500ed251$0$6189$ba4acef3@reader.news.orange.fr...
>
> Randy,
>
>>> On Windows you interface to fopen() as done on
>>> UNIXes I suppose or maybe to an even higher level using OpenFile().
>>
>> Definitely not. We directly use the Win32 APIs for file functions (and 
>> there
>> is not one called fopen). The Win32 API is called "CreateFile", and it is
>> nothing much like the one from Unix or the one for C.
>
> So that's more a Definitely yes, OpenFile() is a Win32 API call too.
>
>> We have out own abstraction package (called "Basic_IO") that abstracts 
>> the
>> underlying I/O facilities. Remember, we started out on CP/M and MS-DOS 
>> 1.0,
>> neither of which had anything remotely like the Unix file operations.
>>
>> As I mentioned, we don't use any code written in C in our compiler; it's 
>> all
>> written in Ada or assembler. And we directly interface to the 
>> lowest-level
>> APIs that the OS defines - Win32 for 32-bit Windows.
>
> Depending on your view, the Win32 API is not the lowest API on windows
> to me.

What would be lower? Win32 directly makes calls on the DLLs that make up the 
OS kernel. Everything else that I'm aware of sits on top of that.

> Anyway, what you are describing is exactly what is done in GNAT
> (and I know pretty well this part!). But looks like you've changed your
> arguments, it was about DLL better that interfacing to C. That's what I
> was having difficulty to understand. Now you are talking API (be it
> Win32 or libc or whatever OS level API) and that's ok to me.
>
> I said:
>
>   Interfacing to a DLL is just like interfacing to C or whatever.
>
> And I still stand on it. DLL is a container, nothing to do with an API.

Sure. But that doesn't have anything to do with this thread. The OP asked 
about the "C part" of a runtime, and several of us pointed out there wasn't 
necessarily any such thing. Interfacing to C (or Stdcall) is not remotely 
the same as having code in C as part of the runtime.

I still don't quite understand what point you're trying to make; it seems 
quite irrelevant. The important point (to me) is whether or not there is 
code written in a non-Ada language in the runtime, how much, and in what 
language. Because it's that sort of code that makes it much harder to port 
the Ada runtime. The API will have to be changed in any case, but the 
non-Ada parts usually have to be redone as well (because a different foreign 
compiler is almost always needed on a new target, and that rarely works the 
same way). Maybe works better if you restrict yourself to the GCC universe, 
but I'm dubious.

                                            Randy.

Re: Ada "library only" compiler ?

[sbelmont700]

On Tuesday, July 24, 2012 5:30:58 PM UTC-4, Pascal Obry wrote:
> There is no clearly specified data structures or whatever.
> A DLL is a container. To use it one need to interface to it, from Ada,
> from C, from Pascal, from Python... And for this you need to have a
> stable and clear API which has nothing to do with DLL.
> 
> The Microsoft Win32 code happen to be in DLLs, but the same code could
> be provided as static library. No more or less problem. The same API,
> the same way to use it, the same need for an interface to it in C, Ada,
> Pascal, Python...
> 

Win32 has actually three sets of APIs: the user-land API that the hoi-polloi like us use (CreateFile), which in turn call another 'native' API (NTCreateFile), which in turn traps into the protected mode parts of the OS (INT 2e, platform depending).  In theory, a program written in bare-bones ASM (or the output of a compiler) could target any of these.  However, the problem is that only the outermost Win32 API is gaurenteed not to change and remain backwards compatible; your program is likely to break between versions of Windows if you attempt cut out the middle man.

-sb