Ada Implementation of functions and produce C for exotic architectures (Expressif)

Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Patrice Freydiere]

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

Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Dan'l Miller]

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.

Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Patrice Freydiere]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Dan'l Miller]

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)?

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Paul Rubin]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Niklas Holsti]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Dan'l Miller]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Simon Wright]

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.

Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Dan'l Miller]

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.

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Randy Brukardt]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Patrice Freydiere]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[rrr.eee.27]

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

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Simon Wright]

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.

Re: Ada Implementation of functions and produce C for exotic architectures (Expressif)

[Mark Lorenzen]

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