* Ada "library only" compiler ? @ 2012-07-20 20:05 Patrick 2012-07-20 21:11 ` Niklas Holsti 2012-07-23 5:02 ` Miles Bader 0 siblings, 2 replies; 41+ messages in thread From: Patrick @ 2012-07-20 20:05 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 20:05 Ada "library only" compiler ? Patrick @ 2012-07-20 21:11 ` Niklas Holsti 2012-07-20 21:47 ` Ludovic Brenta ` (4 more replies) 2012-07-23 5:02 ` Miles Bader 1 sibling, 5 replies; 41+ messages in thread From: Niklas Holsti @ 2012-07-20 21:11 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 21:11 ` Niklas Holsti @ 2012-07-20 21:47 ` Ludovic Brenta 2012-07-20 22:25 ` Peter C. Chapin ` (3 subsequent siblings) 4 siblings, 0 replies; 41+ messages in thread From: Ludovic Brenta @ 2012-07-20 21:47 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 21:11 ` Niklas Holsti 2012-07-20 21:47 ` Ludovic Brenta @ 2012-07-20 22:25 ` Peter C. Chapin 2012-07-20 22:51 ` Ludovic Brenta 2012-07-21 11:05 ` Niklas Holsti 2012-07-20 23:30 ` Patrick ` (2 subsequent siblings) 4 siblings, 2 replies; 41+ messages in thread From: Peter C. Chapin @ 2012-07-20 22:25 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 22:25 ` Peter C. Chapin @ 2012-07-20 22:51 ` Ludovic Brenta 2012-07-21 0:32 ` Randy Brukardt 2012-07-21 11:05 ` Niklas Holsti 1 sibling, 1 reply; 41+ messages in thread From: Ludovic Brenta @ 2012-07-20 22:51 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 22:51 ` Ludovic Brenta @ 2012-07-21 0:32 ` Randy Brukardt 2012-07-21 12:39 ` Pascal Obry 0 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2012-07-21 0:32 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 0:32 ` Randy Brukardt @ 2012-07-21 12:39 ` Pascal Obry 2012-07-22 4:59 ` Shark8 ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Pascal Obry @ 2012-07-21 12:39 UTC (permalink / raw) To: Randy Brukardt 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 12:39 ` Pascal Obry @ 2012-07-22 4:59 ` Shark8 2012-07-22 7:04 ` Pascal Obry 2012-07-22 10:17 ` Florian Weimer 2012-07-24 1:54 ` Randy Brukardt 2 siblings, 1 reply; 41+ messages in thread From: Shark8 @ 2012-07-22 4:59 UTC (permalink / raw) Cc: Randy Brukardt 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 4:59 ` Shark8 @ 2012-07-22 7:04 ` Pascal Obry 0 siblings, 0 replies; 41+ messages in thread From: Pascal Obry @ 2012-07-22 7:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 12:39 ` Pascal Obry 2012-07-22 4:59 ` Shark8 @ 2012-07-22 10:17 ` Florian Weimer 2012-07-24 1:54 ` Randy Brukardt 2 siblings, 0 replies; 41+ messages in thread From: Florian Weimer @ 2012-07-22 10:17 UTC (permalink / raw) * 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 12:39 ` Pascal Obry 2012-07-22 4:59 ` Shark8 2012-07-22 10:17 ` Florian Weimer @ 2012-07-24 1:54 ` Randy Brukardt 2012-07-24 16:50 ` Pascal Obry 2 siblings, 1 reply; 41+ messages in thread From: Randy Brukardt @ 2012-07-24 1:54 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-24 1:54 ` Randy Brukardt @ 2012-07-24 16:50 ` Pascal Obry 2012-07-24 18:01 ` Vasiliy Molostov 2012-07-25 23:34 ` Randy Brukardt 0 siblings, 2 replies; 41+ messages in thread From: Pascal Obry @ 2012-07-24 16:50 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-24 16:50 ` Pascal Obry @ 2012-07-24 18:01 ` Vasiliy Molostov 2012-07-24 21:30 ` Pascal Obry 2012-07-25 23:34 ` Randy Brukardt 1 sibling, 1 reply; 41+ messages in thread From: Vasiliy Molostov @ 2012-07-24 18:01 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-24 18:01 ` Vasiliy Molostov @ 2012-07-24 21:30 ` Pascal Obry 2012-07-25 6:33 ` Vasiliy Molostov 2012-07-25 23:44 ` sbelmont700 0 siblings, 2 replies; 41+ messages in thread From: Pascal Obry @ 2012-07-24 21:30 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-24 21:30 ` Pascal Obry @ 2012-07-25 6:33 ` Vasiliy Molostov 2012-07-25 23:44 ` sbelmont700 1 sibling, 0 replies; 41+ messages in thread From: Vasiliy Molostov @ 2012-07-25 6:33 UTC (permalink / raw) 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/ ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-24 21:30 ` Pascal Obry 2012-07-25 6:33 ` Vasiliy Molostov @ 2012-07-25 23:44 ` sbelmont700 1 sibling, 0 replies; 41+ messages in thread From: sbelmont700 @ 2012-07-25 23:44 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-24 16:50 ` Pascal Obry 2012-07-24 18:01 ` Vasiliy Molostov @ 2012-07-25 23:34 ` Randy Brukardt 1 sibling, 0 replies; 41+ messages in thread From: Randy Brukardt @ 2012-07-25 23:34 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 22:25 ` Peter C. Chapin 2012-07-20 22:51 ` Ludovic Brenta @ 2012-07-21 11:05 ` Niklas Holsti 1 sibling, 0 replies; 41+ messages in thread From: Niklas Holsti @ 2012-07-21 11:05 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 21:11 ` Niklas Holsti 2012-07-20 21:47 ` Ludovic Brenta 2012-07-20 22:25 ` Peter C. Chapin @ 2012-07-20 23:30 ` Patrick 2012-07-21 16:47 ` Niklas Holsti 2012-07-21 0:27 ` Randy Brukardt [not found] ` <olpj085ii9fpifpligh6jerghoaieiim1d@invalid.netcom.com> 4 siblings, 1 reply; 41+ messages in thread From: Patrick @ 2012-07-20 23:30 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 23:30 ` Patrick @ 2012-07-21 16:47 ` Niklas Holsti 2012-07-21 17:47 ` Patrick 0 siblings, 1 reply; 41+ messages in thread From: Niklas Holsti @ 2012-07-21 16:47 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 16:47 ` Niklas Holsti @ 2012-07-21 17:47 ` Patrick 2012-07-21 19:22 ` Simon Wright ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Patrick @ 2012-07-21 17:47 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 17:47 ` Patrick @ 2012-07-21 19:22 ` Simon Wright 2012-07-21 19:38 ` Patrick 2012-07-21 22:53 ` Brian Drummond 2012-07-22 21:18 ` Niklas Holsti 2 siblings, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-07-21 19:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 19:22 ` Simon Wright @ 2012-07-21 19:38 ` Patrick 0 siblings, 0 replies; 41+ messages in thread From: Patrick @ 2012-07-21 19:38 UTC (permalink / raw) thanks Simon, this is sure to help ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 17:47 ` Patrick 2012-07-21 19:22 ` Simon Wright @ 2012-07-21 22:53 ` Brian Drummond 2012-07-22 3:25 ` Patrick 2012-07-22 21:18 ` Niklas Holsti 2 siblings, 1 reply; 41+ messages in thread From: Brian Drummond @ 2012-07-21 22:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 22:53 ` Brian Drummond @ 2012-07-22 3:25 ` Patrick 2012-07-22 17:54 ` Brian Drummond 2012-07-22 21:25 ` Niklas Holsti 0 siblings, 2 replies; 41+ messages in thread From: Patrick @ 2012-07-22 3:25 UTC (permalink / raw) 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 :( ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 3:25 ` Patrick @ 2012-07-22 17:54 ` Brian Drummond 2012-07-22 17:59 ` Brian Drummond [not found] ` <m2a9yrsbf5.fsf@nidhoggr.home> 2012-07-22 21:25 ` Niklas Holsti 1 sibling, 2 replies; 41+ messages in thread From: Brian Drummond @ 2012-07-22 17:54 UTC (permalink / raw) 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 --------------------------------------------------- ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 17:54 ` Brian Drummond @ 2012-07-22 17:59 ` Brian Drummond 2012-07-22 18:44 ` Patrick [not found] ` <m2a9yrsbf5.fsf@nidhoggr.home> 1 sibling, 1 reply; 41+ messages in thread From: Brian Drummond @ 2012-07-22 17:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 17:59 ` Brian Drummond @ 2012-07-22 18:44 ` Patrick 2012-07-22 21:03 ` Brian Drummond 2012-07-25 19:10 ` J-P. Rosen 0 siblings, 2 replies; 41+ messages in thread From: Patrick @ 2012-07-22 18:44 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 18:44 ` Patrick @ 2012-07-22 21:03 ` Brian Drummond 2012-07-25 19:10 ` J-P. Rosen 1 sibling, 0 replies; 41+ messages in thread From: Brian Drummond @ 2012-07-22 21:03 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 18:44 ` Patrick 2012-07-22 21:03 ` Brian Drummond @ 2012-07-25 19:10 ` J-P. Rosen 1 sibling, 0 replies; 41+ messages in thread From: J-P. Rosen @ 2012-07-25 19:10 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <m2a9yrsbf5.fsf@nidhoggr.home>]
[parent not found: <jui36a$hs0$1@dont-email.me>]
* Re: Ada "library only" compiler ? [not found] ` <jui36a$hs0$1@dont-email.me> @ 2012-07-23 10:10 ` Simon Wright 2012-07-24 10:55 ` Brian Drummond 0 siblings, 1 reply; 41+ messages in thread From: Simon Wright @ 2012-07-23 10:10 UTC (permalink / raw) 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! ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-23 10:10 ` Simon Wright @ 2012-07-24 10:55 ` Brian Drummond 0 siblings, 0 replies; 41+ messages in thread From: Brian Drummond @ 2012-07-24 10:55 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 3:25 ` Patrick 2012-07-22 17:54 ` Brian Drummond @ 2012-07-22 21:25 ` Niklas Holsti 2012-07-22 22:00 ` Patrick 1 sibling, 1 reply; 41+ messages in thread From: Niklas Holsti @ 2012-07-22 21:25 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-22 21:25 ` Niklas Holsti @ 2012-07-22 22:00 ` Patrick 0 siblings, 0 replies; 41+ messages in thread From: Patrick @ 2012-07-22 22:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 17:47 ` Patrick 2012-07-21 19:22 ` Simon Wright 2012-07-21 22:53 ` Brian Drummond @ 2012-07-22 21:18 ` Niklas Holsti 2 siblings, 0 replies; 41+ messages in thread From: Niklas Holsti @ 2012-07-22 21:18 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 21:11 ` Niklas Holsti ` (2 preceding siblings ...) 2012-07-20 23:30 ` Patrick @ 2012-07-21 0:27 ` Randy Brukardt 2012-07-21 7:36 ` Dmitry A. Kazakov 2012-07-21 13:31 ` Niklas Holsti [not found] ` <olpj085ii9fpifpligh6jerghoaieiim1d@invalid.netcom.com> 4 siblings, 2 replies; 41+ messages in thread From: Randy Brukardt @ 2012-07-21 0:27 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 0:27 ` Randy Brukardt @ 2012-07-21 7:36 ` Dmitry A. Kazakov 2012-07-21 13:31 ` Niklas Holsti 1 sibling, 0 replies; 41+ messages in thread From: Dmitry A. Kazakov @ 2012-07-21 7:36 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-21 0:27 ` Randy Brukardt 2012-07-21 7:36 ` Dmitry A. Kazakov @ 2012-07-21 13:31 ` Niklas Holsti 1 sibling, 0 replies; 41+ messages in thread From: Niklas Holsti @ 2012-07-21 13:31 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
[parent not found: <olpj085ii9fpifpligh6jerghoaieiim1d@invalid.netcom.com>]
* Re: Ada "library only" compiler ? [not found] ` <olpj085ii9fpifpligh6jerghoaieiim1d@invalid.netcom.com> @ 2012-07-20 23:38 ` Patrick 2012-07-21 13:12 ` Niklas Holsti 1 sibling, 0 replies; 41+ messages in thread From: Patrick @ 2012-07-20 23:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? [not found] ` <olpj085ii9fpifpligh6jerghoaieiim1d@invalid.netcom.com> 2012-07-20 23:38 ` Patrick @ 2012-07-21 13:12 ` Niklas Holsti 1 sibling, 0 replies; 41+ messages in thread From: Niklas Holsti @ 2012-07-21 13:12 UTC (permalink / raw) 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 . @ . ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: Ada "library only" compiler ? 2012-07-20 20:05 Ada "library only" compiler ? Patrick 2012-07-20 21:11 ` Niklas Holsti @ 2012-07-23 5:02 ` Miles Bader 1 sibling, 0 replies; 41+ messages in thread From: Miles Bader @ 2012-07-23 5:02 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2012-07-26 16:37 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-07-20 20:05 Ada "library only" compiler ? Patrick 2012-07-20 21:11 ` Niklas Holsti 2012-07-20 21:47 ` Ludovic Brenta 2012-07-20 22:25 ` Peter C. Chapin 2012-07-20 22:51 ` Ludovic Brenta 2012-07-21 0:32 ` Randy Brukardt 2012-07-21 12:39 ` Pascal Obry 2012-07-22 4:59 ` Shark8 2012-07-22 7:04 ` Pascal Obry 2012-07-22 10:17 ` Florian Weimer 2012-07-24 1:54 ` Randy Brukardt 2012-07-24 16:50 ` Pascal Obry 2012-07-24 18:01 ` Vasiliy Molostov 2012-07-24 21:30 ` Pascal Obry 2012-07-25 6:33 ` Vasiliy Molostov 2012-07-25 23:44 ` sbelmont700 2012-07-25 23:34 ` Randy Brukardt 2012-07-21 11:05 ` Niklas Holsti 2012-07-20 23:30 ` Patrick 2012-07-21 16:47 ` Niklas Holsti 2012-07-21 17:47 ` Patrick 2012-07-21 19:22 ` Simon Wright 2012-07-21 19:38 ` Patrick 2012-07-21 22:53 ` Brian Drummond 2012-07-22 3:25 ` Patrick 2012-07-22 17:54 ` Brian Drummond 2012-07-22 17:59 ` Brian Drummond 2012-07-22 18:44 ` Patrick 2012-07-22 21:03 ` Brian Drummond 2012-07-25 19:10 ` J-P. Rosen [not found] ` <m2a9yrsbf5.fsf@nidhoggr.home> [not found] ` <jui36a$hs0$1@dont-email.me> 2012-07-23 10:10 ` Simon Wright 2012-07-24 10:55 ` Brian Drummond 2012-07-22 21:25 ` Niklas Holsti 2012-07-22 22:00 ` Patrick 2012-07-22 21:18 ` Niklas Holsti 2012-07-21 0:27 ` Randy Brukardt 2012-07-21 7:36 ` Dmitry A. Kazakov 2012-07-21 13:31 ` Niklas Holsti [not found] ` <olpj085ii9fpifpligh6jerghoaieiim1d@invalid.netcom.com> 2012-07-20 23:38 ` Patrick 2012-07-21 13:12 ` Niklas Holsti 2012-07-23 5:02 ` Miles Bader
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox