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.224.39.72 with SMTP id f8mr1292229qae.7.1343312617019; Thu, 26 Jul 2012 07:23:37 -0700 (PDT) Received: by 10.66.76.8 with SMTP id g8mr1620790paw.23.1343312616597; Thu, 26 Jul 2012 07:23:36 -0700 (PDT) Path: a15ni105485768qag.0!nntp.google.com!q21no13410468qas.0!news-out.google.com!p10ni61181651pbh.1!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!novia!news-peer1!btnet!zen.net.uk!hamilton.zen.co.uk!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!nntp.giganews.com!newsfeed.straub-nv.de!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!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 19:47:54 +0300 Organization: Tidorum Ltd Message-ID: References: <2879c45e-f8e0-4434-9f82-968c585a4539@googlegroups.com> <4ec072e1-853f-4210-82aa-9aab335ab0ba@googlegroups.com> Mime-Version: 1.0 X-Trace: individual.net 672nDYdCQduxVtLWHInocAeblBnYg9bjxk0fy+TbOSyfc9p9RIcxQWiOXXz6LEjdlW Cancel-Lock: sha1:tWIuvf74zMoTL0HcEvJckyodEdg= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 In-Reply-To: <4ec072e1-853f-4210-82aa-9aab335ab0ba@googlegroups.com> X-Original-Bytes: 10097 X-Received-Bytes: 10234 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-07-21T19:47:54+03:00 List-Id: 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 . @ .