* Ada Implementation of functions and produce C for exotic architectures (Expressif) @ 2018-04-11 17:17 Patrice Freydiere 2018-04-11 18:46 ` Dan'l Miller ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Patrice Freydiere @ 2018-04-11 17:17 UTC (permalink / raw) Hi, I've been informed the current gnat is able to target C, especially with ZFP profile. --> https://blog.adacore.com/sparkzumo-part-2-integrating-the-arduino-build-environment-into-gps Seems this target "C" is only available on gnat pro, I don't much program in Ada to have a professional solution, are there any alternatives ? i have an embedded project and wish to implements some core functionality in Ada, Thank's for your pointers. Patrice ^ permalink raw reply [flat|nested] 14+ messages in thread
* Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 17:17 Ada Implementation of functions and produce C for exotic architectures (Expressif) Patrice Freydiere @ 2018-04-11 18:46 ` Dan'l Miller 2018-04-11 19:07 ` Patrice Freydiere 2018-04-11 19:41 ` Paul Rubin 2018-04-11 21:14 ` Simon Wright 2018-04-11 21:57 ` Dan'l Miller 2 siblings, 2 replies; 14+ messages in thread From: Dan'l Miller @ 2018-04-11 18:46 UTC (permalink / raw) In step 5, appears the following text “… header files generated by the CCG tool”. The C code generated is C header files that conform (as an ABI of sorts) to the function/procedure declarations in the Ada spec, but for consumptipn by GCC’s C or C++ compilers. The ALI file provides other useful-for-interworking information to the binder. C is not a backend target of the GNAT compiler, despite C being a syntactic/semantic near-isomorph of PDP-11 assembly language limited to only 1970s-era structured programming control-flow constructs instead of offset-branching. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 18:46 ` Dan'l Miller @ 2018-04-11 19:07 ` Patrice Freydiere 2018-04-11 19:22 ` Dan'l Miller 2018-04-11 19:41 ` Paul Rubin 1 sibling, 1 reply; 14+ messages in thread From: Patrice Freydiere @ 2018-04-11 19:07 UTC (permalink / raw) Hi dan thanks for the rely. I’m a bit dizzled as step 1 “Run CCG on the SPARK/Ada Code to produce C files and Ada Library Information files, or ali files. For more information on these files, see the GNAT Compilation Model documentation.” From a gnat documentation I saw the c target . From my understanding. As mention in the article The c generation permit to use avr or other compiler not directly supported by gnat. If obj are generated even consumed by c compiler they are using the target processor assembly language. So my question is, for hobbyists are there any alternatives ? Thanks ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 19:07 ` Patrice Freydiere @ 2018-04-11 19:22 ` Dan'l Miller 2018-04-11 20:31 ` Niklas Holsti 0 siblings, 1 reply; 14+ messages in thread From: Dan'l Miller @ 2018-04-11 19:22 UTC (permalink / raw) On Wednesday, April 11, 2018 at 2:07:44 PM UTC-5, Patrice Freydiere wrote: > ... > From a gnat documentation I saw the c target . At what URL did you see that C would be a supported backend target of GNAT (instead of merely generating C header files)? > ... > If obj are generated even consumed by c compiler they are using the target processor assembly language. The generated library from Ada is consumable by the C compiler via the generated header files. > So my question is, for hobbyists are there any alternatives ? Alternative to what? I.e., what would you like to do (that is different than what is described herein of linking a GNAT-generated Ada library to C code)? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 19:22 ` Dan'l Miller @ 2018-04-11 20:31 ` Niklas Holsti 2018-04-12 8:10 ` Mark Lorenzen 0 siblings, 1 reply; 14+ messages in thread From: Niklas Holsti @ 2018-04-11 20:31 UTC (permalink / raw) On 18-04-11 22:22 , Dan'l Miller wrote: > On Wednesday, April 11, 2018 at 2:07:44 PM UTC-5, Patrice Freydiere > wrote: >> ... From a gnat documentation I saw the c target . > > At what URL did you see that C would be a supported backend target of > GNAT (instead of merely generating C header files)? http://docs.adacore.com/live/wave/gnat_ccg/html/gnatccg_ug/gnat_ccg.html This seems to be a new AdaCore product which really compiles Ada to C and is not just a header-file generator. There are and have been other such tools, for example AdaMagic from SofCheck. SofCheck merged with AdaCore some time ago; possibly CCG has some heritage from the AdaMagic Ada-to-C translator, possibly not. -- Niklas Holsti Tidorum Ltd niklas holsti tidorum fi . @ . ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 20:31 ` Niklas Holsti @ 2018-04-12 8:10 ` Mark Lorenzen 0 siblings, 0 replies; 14+ messages in thread From: Mark Lorenzen @ 2018-04-12 8:10 UTC (permalink / raw) On Wednesday, April 11, 2018 at 10:31:39 PM UTC+2, Niklas Holsti wrote: > > http://docs.adacore.com/live/wave/gnat_ccg/html/gnatccg_ug/gnat_ccg.html > > This seems to be a new AdaCore product which really compiles Ada to C > and is not just a header-file generator. Indeed, there is a bit of information in the latest newsletter on page 5: https://www.adacore.com/uploads/newsletter/01-10-2018_pages.pdf Regards, Mark L ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 18:46 ` Dan'l Miller 2018-04-11 19:07 ` Patrice Freydiere @ 2018-04-11 19:41 ` Paul Rubin 2018-04-11 20:31 ` Dan'l Miller 1 sibling, 1 reply; 14+ messages in thread From: Paul Rubin @ 2018-04-11 19:41 UTC (permalink / raw) "Dan'l Miller" <optikos@verizon.net> writes: > C is not a backend target of the GNAT compiler, despite C being a > syntactic/semantic near-isomorph of PDP-11 assembly language People erroneously believe that and then freak out when they find it isn't true. Consider signed arithmetic overflow being twos-complement arithmetic in PDP-11 assembly language, vs being undefined behavior in C. In Ada it's supposed to signal a constraint error iiuc. So C wouldn't really be a natural target for an Ada compiler. C is not a "portable assembler" despite the wishes or dreams of some of its users. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 19:41 ` Paul Rubin @ 2018-04-11 20:31 ` Dan'l Miller 2018-04-11 22:30 ` Randy Brukardt 0 siblings, 1 reply; 14+ messages in thread From: Dan'l Miller @ 2018-04-11 20:31 UTC (permalink / raw) On Wednesday, April 11, 2018 at 2:41:49 PM UTC-5, Paul Rubin wrote: > "Dan'l Miller" writes: > > C is not a backend target of the GNAT compiler, despite C being a > > syntactic/semantic near-isomorph of PDP-11 assembly language > > People erroneously believe that and then freak out when they find it > isn't true. Consider signed arithmetic overflow being twos-complement > arithmetic in PDP-11 assembly language, vs being undefined behavior in > C. In Ada it's supposed to signal a constraint error iiuc. > > So C wouldn't really be a natural target for an Ada compiler. C is not > a "portable assembler" despite the wishes or dreams of some of its > users. Allow me to amend in overt words what was previously implied in unstated language: C is syntactic/semantic •near•-isomorph of PDP-11 assembly language [on processors whose behavior sufficiently resemble PDP-11's behavior. The more the processor's behavior diverges from PDP-11's behavior, the more the undefined behavior does something different than what C on PDP-11 did. C usually doesn't rectify divergent-from-PDP-11 behavior; C usually either a) simply washes their standardization hands of it by declaring it undefined behavior (to which the standard will speakest no more of the topic) or b) provides some rudimentary information for the programmer's optional usage to discover the limits of how much this processor resembles versus extrapolates PDP-11 (e.g., MAX_INT).] Not all undefined behavior is created equal though. Relying on undefined behavior regarding pointers is usually fatal eventually, perhaps even on the original processor, not even when porting yet; pointer-related undefined behavior is pure-evil mortal sin that usually results in the capital punishment of a crash. But then there are categories of C's undefined behavior that are more like a white-lie fib in most cases, rather than capital-punishment crimes: Relying numerous times on undefined behavior regarding integers is commonplace in C and C++, especially regarding char, short, int, long, long long instead of int8_t, uint8_t, int16_t, uint16_t, int32_t, uint32_t, int64_t, uint64_t, as well as various dubious typecasts, as long as one is not porting to one of the astronomically weird processors: 1) Prime 50 series (e.g., no 8-bit byte addresses other than via seldom-utilized bit-pointers; ASCII characters are in the range 128 to 255; schizophrenia of sorts between 16-bit char holding one character or two packed 8-bit characters) 2) the GE and Honeywell processors that Multics ran on (e.g., 9-bit bytes; 36-bit integers) 3) various modern-era FPGAs with parity turned off (e.g., 9-bit bytes) 4) various modern-era DSPs (e.g., 32-bit bytes) Fortunately for the cavalier C community, IA32, IA64, MIPS, ARM, POWER/PowerPC, AMD64, 2900, 6800, 68000, 6502, 88000, Z80, 8085, 16016, 32032, DEC VAX, Alpha, and so forth processors & microprocessors & embedded controllers since the 1970s have an ISA behavior that sufficiently resembled PDP-11 (likely intentionally) enough that various integer-related undefined behavior causes noticeable bugs at a manageably-infrequent rate (e.g., once per change to different processor by management or at Apple once a decade or so). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 20:31 ` Dan'l Miller @ 2018-04-11 22:30 ` Randy Brukardt 0 siblings, 0 replies; 14+ messages in thread From: Randy Brukardt @ 2018-04-11 22:30 UTC (permalink / raw) "Dan'l Miller" <optikos@verizon.net> wrote in message news:6975300f-6280-4a45-90fe-75edb881ba26@googlegroups.com... ... >But then there are categories of C's undefined behavior that are >more like a white-lie fib in most cases, rather than capital-punishment >crimes: Relying numerous times on undefined behavior regarding >integers is commonplace in C and C++, especially regarding char, >short, int, long, long long instead of int8_t, uint8_t, int16_t, uint16_t, >int32_t, uint32_t, int64_t, uint64_t, as well as various dubious >typecasts, as long as one is not porting to one of the astronomically >weird processors: >1) Prime 50 series (e.g., no 8-bit byte addresses other than via >seldom-utilized bit-pointers; ASCII characters are in the range >128 to 255; schizophrenia of sorts between 16-bit char holding > one character or two packed 8-bit characters) >2) the GE and Honeywell processors that Multics ran on (e.g., > 9-bit bytes; 36-bit integers) >3) various modern-era FPGAs with parity turned off (e.g., > 9-bit bytes) >4) various modern-era DSPs (e.g., 32-bit bytes) You forgot :-) the Unisys U1100/2200 series, also 9-bit bytes; 36-bit integers. We built a version of Janus/Ada for that processor targetting their C compiler code generator. It was an *interesting* project. The front-end of Janus/Ada is able to target virtually any processor after all of the abstraction work that had to be done for that project. I'm not sure I should say much more, I presume the NDAs are still active. Randy. Fortunately for the cavalier C community, IA32, IA64, MIPS, ARM, POWER/PowerPC, AMD64, 2900, 6800, 68000, 6502, 88000, Z80, 8085, 16016, 32032, DEC VAX, Alpha, and so forth processors & microprocessors & embedded controllers since the 1970s have an ISA behavior that sufficiently resembled PDP-11 (likely intentionally) enough that various integer-related undefined behavior causes noticeable bugs at a manageably-infrequent rate (e.g., once per change to different processor by management or at Apple once a decade or so). ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 17:17 Ada Implementation of functions and produce C for exotic architectures (Expressif) Patrice Freydiere 2018-04-11 18:46 ` Dan'l Miller @ 2018-04-11 21:14 ` Simon Wright 2018-04-12 6:17 ` Patrice Freydiere 2018-04-11 21:57 ` Dan'l Miller 2 siblings, 1 reply; 14+ messages in thread From: Simon Wright @ 2018-04-11 21:14 UTC (permalink / raw) Patrice Freydiere <frett27@gmail.com> writes: > I've been informed the current gnat is able to target C, especially > with ZFP profile. --> > https://blog.adacore.com/sparkzumo-part-2-integrating-the-arduino-build-environment-into-gps > > Seems this target "C" is only available on gnat pro, I think so. > I don't much program in Ada to have a professional solution, are there > any alternatives ? i have an embedded project and wish to implements > some core functionality in Ada, Since the development kit from Expressif doesn't support Ada, the only way forward I can think of would be to find out what the CPU actually is in the chip and build/obtain a compiler for it with Ada enabled. It looks as though it might be ARM-based, in which case it might not be too hard. Once you have a compiler that will target the chip, it should be possible to build an object library that you can call up from C (I'm assuming that you would retain most of the existing C scaffolding). I won't pretend this would be a walk in the park. [Later] Downloading & setting up the virtual machine as spec'd in the ESP8266 Getting Started Guide, the target of the 4.8.2 cross-compiler is xtensa-lx106-elf. Whether this will work with standard unpatched binutils etc I don't know. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 21:14 ` Simon Wright @ 2018-04-12 6:17 ` Patrice Freydiere 2018-04-12 7:19 ` rrr.eee.27 0 siblings, 1 reply; 14+ messages in thread From: Patrice Freydiere @ 2018-04-12 6:17 UTC (permalink / raw) Le mercredi 11 avril 2018 23:14:52 UTC+2, Simon Wright a écrit : > Patrice Freydiere <frett27@gmail.com> writes: > > > I've been informed the current gnat is able to target C, especially > > with ZFP profile. --> > > https://blog.adacore.com/sparkzumo-part-2-integrating-the-arduino-build-environment-into-gps > > > > Seems this target "C" is only available on gnat pro, > > I think so. > > > I don't much program in Ada to have a professional solution, are there > > any alternatives ? i have an embedded project and wish to implements > > some core functionality in Ada, > > Since the development kit from Expressif doesn't support Ada, the only > way forward I can think of would be to find out what the CPU actually is > in the chip and build/obtain a compiler for it with Ada enabled. It > looks as though it might be ARM-based, in which case it might not be too > hard. > > Once you have a compiler that will target the chip, it should be > possible to build an object library that you can call up from C (I'm > assuming that you would retain most of the existing C scaffolding). > > I won't pretend this would be a walk in the park. > > [Later] > > Downloading & setting up the virtual machine as spec'd in the ESP8266 > Getting Started Guide, the target of the 4.8.2 cross-compiler is > xtensa-lx106-elf. Whether this will work with standard unpatched > binutils etc I don't know. Hi Simon, and thank's for your response, Effectively, your path seems promising, as the crosstool can be build on gcc, https://dl.espressif.com/doc/esp-idf/latest/get-started/linux-setup-scratch.html I'll giv it a try and look if the ada frontend can be activated Thank's, Patrice ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-12 6:17 ` Patrice Freydiere @ 2018-04-12 7:19 ` rrr.eee.27 2018-04-12 7:51 ` Simon Wright 0 siblings, 1 reply; 14+ messages in thread From: rrr.eee.27 @ 2018-04-12 7:19 UTC (permalink / raw) On Thursday, April 12, 2018 at 8:17:54 AM UTC+2, Patrice Freydiere wrote: > Le mercredi 11 avril 2018 23:14:52 UTC+2, Simon Wright a écrit : > > > Downloading & setting up the virtual machine as spec'd in the ESP8266 > > Getting Started Guide, the target of the 4.8.2 cross-compiler is > > xtensa-lx106-elf. Whether this will work with standard unpatched > > binutils etc I don't know. > > Hi Simon, and thank's for your response, > Effectively, your path seems promising, as the crosstool can be build on gcc, https://dl.espressif.com/doc/esp-idf/latest/get-started/linux-setup-scratch.html > Some time ago (~2 years) I already had a working Ada compiler for the ESP8266. but that was only the compiler itself, no run-time-system (RTS). I could successfully compile and link a Ada object file into my project. It was enough to simply state the --target at the configure steps of binutils and gcc. I did not find the time and energy, however, to complete the project and publish my work. I had some problems with bugs and the available compiler versions at that time. Rolf ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-12 7:19 ` rrr.eee.27 @ 2018-04-12 7:51 ` Simon Wright 0 siblings, 0 replies; 14+ messages in thread From: Simon Wright @ 2018-04-12 7:51 UTC (permalink / raw) rrr.eee.27@gmail.com writes: > On Thursday, April 12, 2018 at 8:17:54 AM UTC+2, Patrice Freydiere wrote: >> Le mercredi 11 avril 2018 23:14:52 UTC+2, Simon Wright a écrit : >> >> > Downloading & setting up the virtual machine as spec'd in the ESP8266 >> > Getting Started Guide, the target of the 4.8.2 cross-compiler is >> > xtensa-lx106-elf. Whether this will work with standard unpatched >> > binutils etc I don't know. >> >> Hi Simon, and thank's for your response, >> Effectively, your path seems promising, as the crosstool can be >> build on gcc, >> https://dl.espressif.com/doc/esp-idf/latest/get-started/linux-setup-scratch.html Slightly confused about ESP processor architecture - that link is apparently about xtensa-esp32-elf. > Some time ago (~2 years) I already had a working Ada compiler for the > ESP8266. but that was only the compiler itself, no run-time-system > (RTS). I could successfully compile and link a Ada object file into my > project. It was enough to simply state the --target at the configure > steps of binutils and gcc. One thing to watch out for -- you need a working Ada host compiler and its sources in order to build the cross-compiler. Since the host is a Linux system, that should be OK. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Ada Implementation of functions and produce C for exotic architectures (Expressif) 2018-04-11 17:17 Ada Implementation of functions and produce C for exotic architectures (Expressif) Patrice Freydiere 2018-04-11 18:46 ` Dan'l Miller 2018-04-11 21:14 ` Simon Wright @ 2018-04-11 21:57 ` Dan'l Miller 2 siblings, 0 replies; 14+ messages in thread From: Dan'l Miller @ 2018-04-11 21:57 UTC (permalink / raw) http://www.academia.edu/2490736/Integrating_8-bit_AVR_Micro-Controllers_in_Ada Why generate any C at all when you could possibly have an full-fledged Ada development environment? This paper seems to show some promise of that pursuit. ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2018-04-12 8:10 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-04-11 17:17 Ada Implementation of functions and produce C for exotic architectures (Expressif) Patrice Freydiere 2018-04-11 18:46 ` Dan'l Miller 2018-04-11 19:07 ` Patrice Freydiere 2018-04-11 19:22 ` Dan'l Miller 2018-04-11 20:31 ` Niklas Holsti 2018-04-12 8:10 ` Mark Lorenzen 2018-04-11 19:41 ` Paul Rubin 2018-04-11 20:31 ` Dan'l Miller 2018-04-11 22:30 ` Randy Brukardt 2018-04-11 21:14 ` Simon Wright 2018-04-12 6:17 ` Patrice Freydiere 2018-04-12 7:19 ` rrr.eee.27 2018-04-12 7:51 ` Simon Wright 2018-04-11 21:57 ` Dan'l Miller
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox