[Announce] AVR-Ada V0.1 released

Interesting. I presume this outputs C, which is then compiled ? How does this then handle symbolic debug in the AVR source, in (eg) AVR Studio ?

Is anyone working on Ada for 51MX core (FAR calls etc extensions, just starting to appear in FLASH), and/or perhaps for the 128KF/256KF 80C51variants from Winbond, Cygnal, STm ? Of these, the ST and Cygnal devices have good In Circuit DEBUG support.

There was talk a while ago of Ada for the XA51, but that has only 2 flash models, with smallish code size and not a wide market base.

-jg

That would be a strange thing to presume. While there are Ada compilers that take that approach I would assume that since this is based on the Ada front end of GCC with a GNAT heritage that it produces code just like every other (well nearly every other) GCC/GNAT compiler.

No. Like all other language front-ends in GCC, GNAT does directly generate assembler code for the target processor. All compilers in GCC share the same code generator back end.

AVR studio up to V4.07 uses the old COFF format which is quite limited. Get the V4.08 beta and use the extended COFF format. The easiest is to use the WinAVR distribution (winavr.sourceforge.net) to get used to GCC on Windows first.

I do not know about Ada compilers for other processors. In my project I use the AVR AT90S2313 which has only 2kB of flash for program space and 128 bytes RAM. The generated Ada code isn't any bigger as the equivalent C code. You can write lots of useful programs with a good compiler like gcc despite the size limitations.

Rolf

No, gcc is built in two halves - the front-ends and back-ends are fairly well seperated. When the back-end has been ported to a processor (such as the avr), you get all the front-ends for free. That means that once the gcc C compiler was working on the AVR, much of the gnu ada, fortran, C++, objective C, and possibly even java compilers were also done. There is a certain amount of interaction between the front-end and the back-end that needs to be catered for, but I expect that the main bulk of the work in getting AVR-Ada in action was the support libraries.

gdb works with the jtag ice, and will support Ada fine. You could use that with gvd as a front-end, which will probably work very well since the gvd authors are ADA addicts themselves (gvd is written in ADA).

I hear native gcc-avr file format support will probably appear in AVR Studio, but it will take quite some time (end 2004?).

In comp.arch.embedded Ulf Samuelsson wrote: : > No. Like all other language front-ends in GCC, GNAT does directly : > generate assembler code for the target processor. All compilers in : > GCC share the same code generator back end. : >

: > > How does this then handle symbolic debug in the AVR source, in (eg) AVR : > > Studio ? : >

: > AVR studio up to V4.07 uses the old COFF format which is quite : > limited. Get the V4.08 beta and use the extended COFF format. The : > easiest is to use the WinAVR distribution (winavr.sourceforge.net) to : > get used to GCC on Windows first. : >

: I hear native gcc-avr file format support will probably appear in AVR : Studio, : but it will take quite some time (end 2004?).

During Electronica 2002 I talked to Atmel representatives, and heard the same for 2003

If they said that it would take time, then I guess they were correct ! I have no clue about schedule, so your geuss is as good as mine.

GCC vss GCC :-)

Some people I know of are not aware of the true meaning to GCC. To them (mostly people doing embedded development work, using windows based development hosts) GCC stands for the "GNU C compiler" and not a lot more, they are not fully aware of it's origins or how it internally is architectured. They might know of other GNU compilers for languages such as Pascal, Ada or Fortran etc but they are not totally aware of how they are related with GCC.

However, explaining GCC as the "GNU Compiler Collection" helps clarify things up quite a lot.

GCC is made up of two major "components". Front-ends which parse languages such as C, C++, Fortran and Ada etc into an intermediate form and a series of back-ends which take the intermediate form and end up generating machine code for a particular architecture.

Some things are shareable between the particular targets, for example there is a whole range of optomisations which can be done on the intermediate form which is not backend (target) specific and hence is shared across the different compilers. On the other hand there are optomisations which are exteremly architecture dependant and hence belong in code developed specifically for that port.

A compiler built as part of the GNU Compiler collection is obviously the combination of a selected front end intergrated with a selected backend. The avr-gcc executable on my box is obvioulsy the combination of the avr backend and the C front end, while m68k-palmos-gcc is the same front end married to a different backend.

Hopefully I havn't messed up that simplified description too much...

There has been a backend for the AVR architecture for a while now, however the original developers (as far as I can remember off the top of my head) only worried about getting the C front end working reasonably well.

As the original poster commented, there are various aspects of all languages which mean work before a "raw" backend code generator for that architecture can be utilised. Things such as how language constructs such as exceptions should map to architecture capabilities and any runtime library support required. In the case of a C compiler choices include things such as what size a long or short int should be etc etc.

Hopefully I've clarified things slightly for those interested, and hopefully I havn't mucked up my simpilified description too much.

Hope it helps, Christopher Fairbairn.