From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,d8e3cd3d8dbaa4fb X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.98.234 with SMTP id el10mr1288941wib.3.1343312944977; Thu, 26 Jul 2012 07:29:04 -0700 (PDT) Path: ge7ni75568486wib.0!nntp.google.com!feed-C.news.volia.net!volia.net!news2.volia.net!feed-A.news.volia.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!newsfeed.straub-nv.de!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Niklas Holsti Newsgroups: comp.lang.ada Subject: Re: Ada "library only" compiler ? Date: Sat, 21 Jul 2012 00:11:18 +0300 Organization: Tidorum Ltd Message-ID: References: <2879c45e-f8e0-4434-9f82-968c585a4539@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net KY7hCS8fXG7Q/XS+jUP8hQ8/Tfx+Qc7rpgTIz4iCPFodDcnN02HeY1aIv4HaFUnj1d Cancel-Lock: sha1:gq8CiCwwssuD+qESIMQ8oeOwVWU= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <2879c45e-f8e0-4434-9f82-968c585a4539@googlegroups.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-07-21T00:11:18+03:00 List-Id: 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 . @ .