Re: Ada "library only" compiler ?

["Randy Brukardt" <randy@rrsoftware.com>]

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