understanding runtime support

understanding runtime support

[Patrick]

I've been studying Ada for about 6 months now and I am managing on the desktop. I wanted to start a new embedded project. I had assumed that full Ada would be supported on all the targets GCC is capable of targeting, now I am not so sure.

It's my understanding that with a C program, main must be called main because the compiler is depending on this name to create an entry point and that the compiler can insert ASM code to bootstrap an embedded C program. I am also assuming that gcc inserts a runtime for c and is capable of inserting for all the supported targets.

What is the situation with Ada? I was hoping to target various M68K related architectures, ARM and AVR.

I read a recent thread about "Tasking on GNATAVR" and it does not look like there is an officially supported avr runtime. I haven't found anything in the open source world on M68K support. It looks like Gnat Pro supports ARM but does the GPL version support it?

I am pretty mixed up, please help me find the resources to figure out what is supported-Patrick

Re: understanding runtime support

[Shark8]

As I understand it the "Main" subprogram corresponds to some subprogram in the Ada sources, which (under GNAT) corresponds to subprgram.adb {where 'adb' is the extension for an Ada body}.

Furthermore, with the any Ada front-end for GCC it should be possible to use PRAGMA EXPORT with "main" as the link-name to satisfy the C-assumption that 'main' is the default program.

Re: understanding runtime support

[Patrick]

Hi Shark8

Thanks for the clarification and tips. I am sure I have many things ass backwards in my head.

I did get some help on the #ada with this and I am not quite as mixed up as I was when I first posted but do you happen to know if there is some sort of list that shows the various architectures that Ada can run on with full support using GNT GPL ?

For instances it seems there is gnat on debian arm. Is the support complete? Is there somewhere this information is recorded?

-Patrick

Re: understanding runtime support

[Shark8]

On Sunday, May 13, 2012 10:26:29 AM UTC-5, Patrick wrote:
> Hi Shark8
> 
> Thanks for the clarification and tips. I am sure I have many things ass backwards in my head.
> 
> I did get some help on the #ada with this and I am not quite as mixed up as I was when I first posted but do you happen to know if there is some sort of list that shows the various architectures that Ada can run on with full support using GNT GPL ?
> 
> For instances it seems there is gnat on debian arm. Is the support complete? Is there somewhere this information is recorded?
> 
> -Patrick

I think this StackOverflow post asks the same question: http://stackoverflow.com/questions/10554116/list-of-target-architectures-supported-by-gnat

The accepted answer was a link: http://www.adacore.com/gnatpro/embedded/

However, I'm not sure that's the full list, and it may be just for the embedded architectures.

Re: understanding runtime support

[Ludovic Brenta]

Patrick wrote on comp.lang.ada:
> Thanks for the clarification and tips. I am sure I have many things
> ass backwards in my head.
> 
> I did get some help on the #ada with this and I am not quite as
> mixed up as I was when I first posted but do you happen to know if
> there is some sort of list that shows the various architectures that
> Ada can run on with full support using GNAT GPL ?
> 
> For instances it seems there is gnat on debian arm. Is the support
> complete? Is there somewhere this information is recorded?

I don't think there is a place where this information is recorded
because "embedded" is too broad a term.  The first thing you must do
when talking about "embedded" is to define "embedded" :)

Taking Debian ARM as your example, this is not technically "embedded"
because Debian ARM runs the full software stack on fully capable
devices: Linux kernel, GNU libc, GNAT run-time library and your
programs on top.  Thus, Debian ARM does support tasking on ARM exactly
as it does on a desktop or server.  You can even run GPS on Debian
ARM.

At the other end of the spectrum, AVR is a typical case of an
"embedded" target which has no libc, no kernel, no filesystem and no
memory management unit.  On such a target you are pretty much on your
own; you have to implement all of these features in the GNAT run-time,
or not use them at all (i.e. "pragma No_Run_Time").

The three areas where the Ada run-time is necessary (apart from the
obvious Ada.Containers, Ada.Text_IO et al) are tasking, exception
handling and memory management (i.e. new and Unchecked_Deallocation).

On most targets, GNAT implements tasking with POSIX threads, which
require both a libc and a kernel supporting POSIX threads. For
exception handling, GNAT uses a combination of object code inserted
directly into your program and library calls implemented in the GNAT
run-time.  Here, a kernel is not necessary but if there is a standard
ABI for the target platform, GNAT should use it so that exceptions
work across language boundaries (GNAT fails to obey the ARM ABI, for
that matter).  For memory management, GNAT inserts calls to malloc()
and free() in your executable code, this obviously relies on a working
libc and a kernel too.

It is possible to implement tasking, exception handling and memory
management without a kernel or a libc, replacing all with a so-called
"Board Support Package (BSP)"[1] inside the GNAT run-time library.
I'm not sure which targets GNAT supports this way but I think this
question must be answered case by case and not in a general way.

[1] Note the term "Board Support Package": it supports a "Board" which
has one or more CPUs, possibly a Memory Management Unit, possibly
various buses to various storage controllers, and network interfaces,
etc.  The Board Support Package notably contains the bootstrapping
code that initializes the processor registers to create a stack and
heap before your main procedure can start.

HTH

-- 
Ludovic Brenta.
The enablers re-imagine our organic yield enhancement.

Re: understanding runtime support

[Patrick]

Hi Shark8, Hi Ludovic

Thank you both for your answers. I understand the situation now. I am going to stick to some sort of OS.

Have a great day-Pat

Re: understanding runtime support

[Shark8]

On Monday, May 14, 2012 6:31:27 AM UTC-5, Patrick wrote:
> Hi Shark8, Hi Ludovic
> 
> Thank you both for your answers. I understand the situation now. I am going to stick to some sort of OS.
> 
> Have a great day-Pat

That _might_ be the worst option available.
For one thing, it ties you to that specific OS; another is that the the Ada runtime _can_ take care of a lot of things in a higher-level manner (e.g. tasking) than relying on the OS & libraries (like how C++ uses Boost to do parallelism)... as you can see that option might require compiling the runtime itself for that target (with attendant fiddling to suit the architecture).

A third, and more hybrid approach would be to define the operations/functionality you need in a package and put all your low-level stuff into the body thereof. This however presents [or tends to] more of the weaknesses of both methods than the strengths of either.

Re: understanding runtime support

[Patrick]

Hi Shark8

Okay now I am seriously mixed up.

While I haven't read them all, I now own 18 Ada books and have spent nearly everyday studying for 5 months and now have hit a very hard wall.

Ada is an embedded language right? I have been working on a desktop project for my Son in Ada that would have been easier in Python. I did this because I wanted to do a nice job with it and I wanted to prepare myself for a for-profit-embedded project to be completed later on.

Now it seems I am supposed to roll my own runtime or other low level solution, now that I want to do something embedded I am confronted by an unexpected problem.

I am feeling very discouraged after investing so much time(and that others invested their time in me)

Is full, multi-tasking, Ada only used for embedded design by companies like Boeing that can port Ada to new devices all by themselves? What do small time people like me do?

I am seriously confused now and feel trapped. I do not have the skills to write my own runtime or even part of a runtime. -Patrick

Re: understanding runtime support

[mjsilva]

On Monday, May 14, 2012 1:04:56 PM UTC-7, Patrick wrote:
> Hi Shark8
> 
> Okay now I am seriously mixed up.
> 
> While I haven't read them all, I now own 18 Ada books and have spent nearly everyday studying for 5 months and now have hit a very hard wall.
> 
> Ada is an embedded language right? I have been working on a desktop project for my Son in Ada that would have been easier in Python. I did this because I wanted to do a nice job with it and I wanted to prepare myself for a for-profit-embedded project to be completed later on.
> 
> Now it seems I am supposed to roll my own runtime or other low level solution, now that I want to do something embedded I am confronted by an unexpected problem.
> 
> I am feeling very discouraged after investing so much time(and that others invested their time in me)
> 
> Is full, multi-tasking, Ada only used for embedded design by companies like Boeing that can port Ada to new devices all by themselves? What do small time people like me do?
> 
> I am seriously confused now and feel trapped. I do not have the skills to write my own runtime or even part of a runtime. -Patrick

I find this situation rather insane as well.  As you said, Ada is an embedded language.  OK, to be more precise, Ada is a language which had as a primary design goal the creation of embedded applications.  And yet it seems in practice to be quite impossible to use on embedded applications without a full-blown OS/RTOS underneath it.  

One _can_ do Ada tasking, at least, using a bare metal implementation - the GNAT Lego Mindstorms port does this, I believe.  Sadly, there does not seem to be a cookbook as to how to create such a bare metal port for other devices/families.  I find the situation be be rather astonishing.  As I pointed out in another thread, there are 4 billion ARM chips produced each year, and Ada is an excellent fit for every one of those 4 billion chips, but the Ada community doesn't seem to be interested in that market, or any of the numerous other 32-bit embedded parts available.  This strikes me as madness if one wants Ada to grow and prosper.

Re: understanding runtime support

[Shark8]

I'm going to address this in reverse-order.

>I am seriously confused now and feel trapped. I do not have the skills to write my own runtime or even part of a runtime.

This is understandable; and I think it is probably the big cause of the "I want to write an OS in Ada" sentiment that many express to 'wither and die' [or at least not come to fruition]. 

And it surely doesn't help that many [most?] OS types will pop out "why don't you use C/C++" or "just download the Linux code and..." (i.e. do everything the way "everyone else" does and/or become-a-script-kiddy.)

I'm one of those who would like to write an Ada OS.

> I am feeling very discouraged after investing so much time(and that others invested their time in me)

Don't be. The knowledge is good.

> Now it seems I am supposed to roll my own runtime or other low level solution, now that I want to do something embedded I am confronted by an unexpected problem.

I don't know; you're stepping into the area where I've always gotten hangups: operating on bare-bones hardware.

> Ada is an embedded language right? I have been working on a desktop project for my Son in Ada that would have been easier in Python. I did this because I wanted to do a nice job with it and I wanted to prepare myself for a for-profit-embedded project to be completed later on.

I see. I know that Ada was designed to be able to do embedded; and from what I've read on this forum does it well... though I don't know if they're using it w/o a runtime, with their "normal" runtime compiled for that target [by some magic?], or with a custom runtime.

> While I haven't read them all, I now own 18 Ada books and have spent nearly everyday studying for 5 months and now have hit a very hard wall.

I hear you. I hit that wall with respect to writing a toy OS, and never got around it. I don't think it's the language's fault, but rather the toolchain.

I had started it [the OS] with BP7, after finding a boot-loader which could run a .COM or .EXE file so long as it didn't use the DOS interrupts; I had gotten it so that it could display things on the screen, accept commands from the keyboard, and change video-modes.

When I tried rewriting it in Ada, I couldn't ever get it to compile to a straight-from-boot runnable exe; the problem was, of course, the [lack of a] runtime.

> Okay now I am seriously mixed up.

Me too. :(
Though I really wish I could be more helpful.

Re: understanding runtime support

[Patrick]

Thanks mjs, Thanks Shark8

At least I don't feel alone or that I am being unreasonable. 

I could use a RTOS if it was "THE OS". I could follow along with a variety of solutions, the thing is at this point I want to FOLLOW.

I repair spectrometers for a living. I can program but not like most of the people here who are very talented programmers. I don't want to be a pioneer.

It's worrisome that there isn't standard ways of using Ada in the Embedded space.

To touch on what Ludovic mentioned earlier.. I am using the term embedded as software controlling a purpose built device.

Fighter pilot's aren't falling out of the sky when Windows 95 crashes and I am assuming air traffic controllers are using purpose built Ada programs that don't also allow them to watch p*rn at the same time.

Just an opinion... but it seems like a better description for Ada would be an application language for embedded designs. This would imply that it was not alone on the device.

 

Re: understanding runtime support

[Randy Brukardt]

<mjsilva@scriptoriumdesigns.com> wrote in message 
news:10099625.0.1337029342748.JavaMail.geo-discussion-forums@yneh4...
...
>I find this situation rather insane as well.  As you said, Ada is an 
>embedded language.
> OK, to be more precise, Ada is a language which had as a primary design 
> goal the
> creation of embedded applications.  And yet it seems in practice to be 
> quite impossible
> to use on embedded applications without a full-blown OS/RTOS underneath 
> it.

That's certainly not true. But a true bare machine version of any 
programming language is expensive and has to built more-or-less from scratch 
for that machine. Much of the work is not usable on a different bare 
machine.

Thus this usually takes a *lot* of effort, and thus it usually takes $$$$.

At least with GNAT, you can get the needed source and subsistute hours of 
sweat for the $$$$. But this is not likely to be an easy task.

> Sadly, there does not seem to be a cookbook as to how to create such a 
> bare metal port for other devices/families.

Nothing "sad" about it; it's unavoidable. There is no "cookbook" to creating 
bare machine versions; they have to be tailored to the device and board 
capabilities. There would be no programming languages supporting a board if 
the board manufacturer didn't spend $$$ tailoring some language to support 
it. Not surprisingly, they tend to pick something simple (like C) to 
support, and usually make it even harder to support Ada on those targets 
(because people want compatibility with the C compiler for the board).

>  I find the situation be be rather astonishing.  As I pointed out in 
> another thread, there are
> 4 billion ARM chips produced each year, and Ada is an excellent fit for 
> every one of those
> 4 billion chips, but the Ada community doesn't seem to be interested in 
> that market, or any
> of the numerous other 32-bit embedded parts available.  This strikes me as 
> madness if one
> wants Ada to grow and prosper.

One needs customers in order to make the large investments needed in this 
sort of technology. RRS, at least, has never had anyone express any real 
interest in ARM targets, so we've never even thought about such machines. 
After all, there are a lot other chips out there that also could be 
programmed in Ada (Z80, 8051, etc.) and there never was any interest in 
doing those, either.

Things rarely happen for free, you know.

                                                    Randy.

Re: understanding runtime support

[Ludovic Brenta]

Patrick,

As I said before, "embedded" means many different things.  The
cheapest and easiest solution is Debian for ARM, it comes with
everything you need, precompiled and ready to go.  Don't be sad that
it contains a Linux kernel and a glibc written in C.  As for
controlling a purpose-built device, it is quite possible that this
purpose-built device can run Debian ARM.  After all, the Raspberry Pi
comes very close to what you need and it runs Debian ARM.  Also, a
purpose-built device might not be the most appropriate solution,
maybe (just maybe) an app running on a smartphone might be better.

If you insist on programming the bare metal in Ada but are a one-man
company with no prior experience, then yes you are being unreasonable.
As Randy pointed out, this is a *very* time-consuming endeavor even
if you start from the GNAT sources.  But it is doable and it has been
done before (I remember writing the firmware for avionics devices in
Ada, programming to the bare metal.  The Ada run-time did not support
tasking or memory deallocation, and could not propagate exceptions
beyond the frame that raised them.  We "just" lived with these
constraints).

I encourage anyone with enough time and expertise to donate some and
send me the patches necessary to support GNAT as a cross-compiler
with Debian as the host and whatever strikes your fancy as the target.
(While I'm at it, I feel I can pre-announce the availability of GNAT
on Debian armhf, thanks to the hard work of Tero Koskinen.  Stay
tuned for the official announcement.)

-- 
Ludovic Brenta.

Re: understanding runtime support

[Dmitry A. Kazakov]

On Mon, 14 May 2012 15:52:31 -0700 (PDT), Shark8 wrote:

> I'm one of those who would like to write an Ada OS.

There were attempts. But I would not try before some important changes made
in the language:

1. Uncooperative types model support (to ensure protection against calling
private operations on objects obtained through unchecked conversions or
other tricks)

2. Multiple dispatch (almost all OS interfaces are natively MD)

Yet another *NIX written in Ada would unlikely gain much interest.

BTW, future embedded OSes will be massively parallel and networking. Setups
we are working with, already have dozens of interconnected �-controllers,
some of them multi-core. The logical step will be to have all them running
one OS.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: understanding runtime support

[Jacob Sparre Andersen]

mjsilva@scriptoriumdesigns.com writes:
> On Monday, May 14, 2012 1:04:56 PM UTC-7, Patrick wrote:

>> Now it seems I am supposed to roll my own runtime or other low level
>> solution, [...]

This still depends on both your target system and on which parts of Ada
you want to use in your system.

If you are willing to use LEGO Mindstorms NXT as your target system,
there is a ready-to-use GNAT version supporting the Ravenscar profile.

If you want to use Arduino as your target system, there is a
ready-to-compile GNAT version (AVR-Ada), which doesn't support the
Ravenscar profile yet, but is likely to get there.

If you want to use a Gumstix Overo or a Raspberry Pi running Debian, it
(Debian) comes with a complete GNAT compiler.

So it is not like there aren't any options.  You just have to think
about what you want to do and what it requires.  Then you can take a
look at the options and see which one fits your problem (best).

>> Is full, multi-tasking, Ada only used for embedded design by
>> companies like Boeing that can port Ada to new devices all by
>> themselves? What do small time people like me do?

Use the available options or build the necessary additions to the
available options.

If nobody else gets to it first, I will take a look at how the
GNAT-for-Mindstorms kernel is implemented, and see if I can port it to
the Arduino (AVR).

> I find this situation rather insane as well.  As you said, Ada is an
> embedded language.  OK, to be more precise, Ada is a language which
> had as a primary design goal the creation of embedded applications.
> And yet it seems in practice to be quite impossible to use on embedded
> applications without a full-blown OS/RTOS underneath it.

I would say that GNAT-for-Mindstorms is a very good demonstration that
you don't need a "full-blown OS/RTOS" underneath Ada.

> One _can_ do Ada tasking, at least, using a bare metal implementation
> - the GNAT Lego Mindstorms port does this, I believe.

Yes.

Another option (not tested by me) is ARM-Ada:

   http://sourceforge.net/projects/arm-ada/

> Sadly, there does not seem to be a cookbook as to how to create such a
> bare metal port for other devices/families.

Apparently not. - Maybe it is time to write one?

Greetings,

Jacob
-- 
"Science is like sex: sometimes something useful comes out,
 but that is not the reason we are doing it"
                                          -- Richard Feynman

Re: understanding runtime support

[Lucretia]

On Monday, May 14, 2012 9:24:46 AM UTC+1, Ludovic Brenta wrote:

> or not use them at all (i.e. "pragma No_Run_Time").

This has not been a valid pragma withing GNAT for years now. Do a search of this group, you will find a reference to this pragma (me asking about it) and Robert Dewar explaining it's defunct. Ada has pragma Restrictions now, these are used to get the runtime down to nothing.

Luke.

Re: understanding runtime support

[Lucretia]

On Monday, May 14, 2012 10:02:22 PM UTC+1, mjs...@scriptoriumdesigns.com wrote:
> On Monday, May 14, 2012 1:04:56 PM UTC-7, Patrick wrote:
> > Hi Shark8
> > 
> > Okay now I am seriously mixed up.
> > 
> > While I haven't read them all, I now own 18 Ada books and have spent nearly everyday studying for 5 months and now have hit a very hard wall.
> > 
> > Ada is an embedded language right? I have been working on a desktop project for my Son in Ada that would have been easier in Python. I did this because I wanted to do a nice job with it and I wanted to prepare myself for a for-profit-embedded project to be completed later on.
> > 
> > Now it seems I am supposed to roll my own runtime or other low level solution, now that I want to do something embedded I am confronted by an unexpected problem.
> > 
> > I am feeling very discouraged after investing so much time(and that others invested their time in me)
> > 
> > Is full, multi-tasking, Ada only used for embedded design by companies like Boeing that can port Ada to new devices all by themselves? What do small time people like me do?
> > 
> > I am seriously confused now and feel trapped. I do not have the skills to write my own runtime or even part of a runtime. -Patrick
> 
> I find this situation rather insane as well.  As you said, Ada is an embedded language.  OK, to be more precise, Ada is a language which had as a primary design goal the creation of embedded applications.  And yet it seems in practice to be quite impossible to use on embedded applications without a full-blown OS/RTOS underneath it.  
> 
> One _can_ do Ada tasking, at least, using a bare metal implementation - the GNAT Lego Mindstorms port does this, I believe.  Sadly, there does not seem to be a cookbook as to how to create such a bare metal port for other devices/families.  I find the situation be be rather astonishing.  As I pointed out in another thread, there are 4 billion ARM chips produced each year, and Ada is an excellent fit for every one of those 4 billion chips, but the Ada community doesn't seem to be interested in that market, or any of the numerous other 32-bit embedded parts available.  This strikes me as madness if one wants Ada to grow and prosper.

I do keep posting in this group that I have an interest in this area and have been messing about with GNAT to produce a bare metal runtime using standard GNAT packages - check out https://github.com/Lucretia/tamp for an example which builds and runs - doesn't do anything, except execute - on an STM discovery board.

Luke.

Re: understanding runtime support

[Lucretia]

On Tuesday, May 15, 2012 8:26:37 AM UTC+1, Ludovic Brenta wrote:

> I encourage anyone with enough time and expertise to donate some and

If you grab my patch from tamp, it will build for arm-elf for 4.6.x compilers. I tried to apply the patch to 4.7.x and it totally failed, looks like the compiler's gone back in time and is messed up again. GCC's well flaky in this regard.

Luke.

Re: understanding runtime support

[Lucretia]

On Friday, May 11, 2012 4:49:07 AM UTC+1, Patrick wrote:

> What is the situation with Ada? I was hoping to target various M68K related architectures, ARM and AVR.

As linked to a number of times, my tamp repo on github (above) has some code that will build for an arm board and can be run on it, doesn't do anything though :D

With Ada, you can pass a number of compilation units to the compiler and it will build them, some of these units can be what is the equivalent of a "main." What GNAT does with this is as follows, gnatbind is called to generate a new file b~<your entry procedure name>.adb, this file contains procedures for calling the elaboration code (to set up arrays and other data), then calls your entry point and on exit calls an exit procedure.

An example is best, so given the following entry point:

procedure test is
   a : string(1 .. 5) := "hello";
begin
   null;
end test;

and compiled with:

$ gnatmake -c test.adb 
gcc-4.6 -c test.adb
$ gnatmake -b test.adb 
gnatbind -x test.ali

you are left with the following b~test.ad[sb]:

pragma Ada_95;
with System;
package ada_main is
   pragma Warnings (Off);

   gnat_argc : Integer;
   gnat_argv : System.Address;
   gnat_envp : System.Address;

   pragma Import (C, gnat_argc);
   pragma Import (C, gnat_argv);
   pragma Import (C, gnat_envp);

   gnat_exit_status : Integer;
   pragma Import (C, gnat_exit_status);

   GNAT_Version : constant String :=
                    "GNAT Version: 4.6" & ASCII.NUL;
   pragma Export (C, GNAT_Version, "__gnat_version");

   Ada_Main_Program_Name : constant String := "_ada_test" & ASCII.NUL;
   pragma Export (C, Ada_Main_Program_Name, "__gnat_ada_main_program_name");

   procedure adafinal;
   pragma Export (C, adafinal, "adafinal");

   procedure adainit;
   pragma Export (C, adainit, "adainit");

   procedure Break_Start;
   pragma Import (C, Break_Start, "__gnat_break_start");

   function main
     (argc : Integer;
      argv : System.Address;
      envp : System.Address)
      return Integer;
   pragma Export (C, main, "main");

   type Version_32 is mod 2 ** 32;
   u00001 : constant Version_32 := 16#2951576a#;
   pragma Export (C, u00001, "testB");
   u00002 : constant Version_32 := 16#ba46b2cd#;
   pragma Export (C, u00002, "system__standard_libraryB");
   u00003 : constant Version_32 := 16#1e2e640d#;
   pragma Export (C, u00003, "system__standard_libraryS");
   u00004 : constant Version_32 := 16#23e1f70b#;
   pragma Export (C, u00004, "systemS");
   u00005 : constant Version_32 := 16#0936cab5#;
   pragma Export (C, u00005, "system__memoryB");
   u00006 : constant Version_32 := 16#e96a4b1e#;
   pragma Export (C, u00006, "system__memoryS");
   u00007 : constant Version_32 := 16#3ffc8e18#;
   pragma Export (C, u00007, "adaS");
   u00008 : constant Version_32 := 16#9229643d#;
   pragma Export (C, u00008, "ada__exceptionsB");
   u00009 : constant Version_32 := 16#e3df9d67#;
   pragma Export (C, u00009, "ada__exceptionsS");
   u00010 : constant Version_32 := 16#95643e9a#;
   pragma Export (C, u00010, "ada__exceptions__last_chance_handlerB");
   u00011 : constant Version_32 := 16#03cf4fc2#;
   pragma Export (C, u00011, "ada__exceptions__last_chance_handlerS");
   u00012 : constant Version_32 := 16#30ec78bc#;
   pragma Export (C, u00012, "system__soft_linksB");
   u00013 : constant Version_32 := 16#e2ebe502#;
   pragma Export (C, u00013, "system__soft_linksS");
   u00014 : constant Version_32 := 16#0d2b82ae#;
   pragma Export (C, u00014, "system__parametersB");
   u00015 : constant Version_32 := 16#bfbc74f1#;
   pragma Export (C, u00015, "system__parametersS");
   u00016 : constant Version_32 := 16#72905399#;
   pragma Export (C, u00016, "system__secondary_stackB");
   u00017 : constant Version_32 := 16#378fd0a5#;
   pragma Export (C, u00017, "system__secondary_stackS");
   u00018 : constant Version_32 := 16#ace32e1e#;
   pragma Export (C, u00018, "system__storage_elementsB");
   u00019 : constant Version_32 := 16#d92c8a93#;
   pragma Export (C, u00019, "system__storage_elementsS");
   u00020 : constant Version_32 := 16#4f750b3b#;
   pragma Export (C, u00020, "system__stack_checkingB");
   u00021 : constant Version_32 := 16#80434b27#;
   pragma Export (C, u00021, "system__stack_checkingS");
   u00022 : constant Version_32 := 16#a7343537#;
   pragma Export (C, u00022, "system__exception_tableB");
   u00023 : constant Version_32 := 16#8120f83b#;
   pragma Export (C, u00023, "system__exception_tableS");
   u00024 : constant Version_32 := 16#ff3fa16b#;
   pragma Export (C, u00024, "system__htableB");
   u00025 : constant Version_32 := 16#cc3e5bd4#;
   pragma Export (C, u00025, "system__htableS");
   u00026 : constant Version_32 := 16#8b7dad61#;
   pragma Export (C, u00026, "system__string_hashB");
   u00027 : constant Version_32 := 16#057d2f9f#;
   pragma Export (C, u00027, "system__string_hashS");
   u00028 : constant Version_32 := 16#6a8a6a74#;
   pragma Export (C, u00028, "system__exceptionsB");
   u00029 : constant Version_32 := 16#86f01d0a#;
   pragma Export (C, u00029, "system__exceptionsS");
   u00030 : constant Version_32 := 16#b012ff50#;
   pragma Export (C, u00030, "system__img_intB");
   u00031 : constant Version_32 := 16#213a17c9#;
   pragma Export (C, u00031, "system__img_intS");
   u00032 : constant Version_32 := 16#dc8e33ed#;
   pragma Export (C, u00032, "system__tracebackB");
   u00033 : constant Version_32 := 16#4266237e#;
   pragma Export (C, u00033, "system__tracebackS");
   u00034 : constant Version_32 := 16#4900ab7d#;
   pragma Export (C, u00034, "system__unsigned_typesS");
   u00035 : constant Version_32 := 16#907d882f#;
   pragma Export (C, u00035, "system__wch_conB");
   u00036 : constant Version_32 := 16#9c0ad936#;
   pragma Export (C, u00036, "system__wch_conS");
   u00037 : constant Version_32 := 16#22fed88a#;
   pragma Export (C, u00037, "system__wch_stwB");
   u00038 : constant Version_32 := 16#b11bf537#;
   pragma Export (C, u00038, "system__wch_stwS");
   u00039 : constant Version_32 := 16#5d4d477e#;
   pragma Export (C, u00039, "system__wch_cnvB");
   u00040 : constant Version_32 := 16#82f45fe0#;
   pragma Export (C, u00040, "system__wch_cnvS");
   u00041 : constant Version_32 := 16#f77d8799#;
   pragma Export (C, u00041, "interfacesS");
   u00042 : constant Version_32 := 16#75729fba#;
   pragma Export (C, u00042, "system__wch_jisB");
   u00043 : constant Version_32 := 16#d686c4f4#;
   pragma Export (C, u00043, "system__wch_jisS");
   u00044 : constant Version_32 := 16#ada34a87#;
   pragma Export (C, u00044, "system__traceback_entriesB");
   u00045 : constant Version_32 := 16#71c0194a#;
   pragma Export (C, u00045, "system__traceback_entriesS");
   u00046 : constant Version_32 := 16#13cbc5a8#;
   pragma Export (C, u00046, "system__crtlS");

   --  BEGIN ELABORATION ORDER
   --  ada%s
   --  interfaces%s
   --  system%s
   --  system.htable%s
   --  system.img_int%s
   --  system.img_int%b
   --  system.parameters%s
   --  system.parameters%b
   --  system.crtl%s
   --  system.standard_library%s
   --  system.exceptions%s
   --  system.exceptions%b
   --  system.storage_elements%s
   --  system.storage_elements%b
   --  system.stack_checking%s
   --  system.stack_checking%b
   --  system.string_hash%s
   --  system.string_hash%b
   --  system.htable%b
   --  system.traceback_entries%s
   --  system.traceback_entries%b
   --  ada.exceptions%s
   --  system.soft_links%s
   --  system.unsigned_types%s
   --  system.wch_con%s
   --  system.wch_con%b
   --  system.wch_cnv%s
   --  system.wch_jis%s
   --  system.wch_jis%b
   --  system.wch_cnv%b
   --  system.wch_stw%s
   --  system.wch_stw%b
   --  ada.exceptions.last_chance_handler%s
   --  ada.exceptions.last_chance_handler%b
   --  system.exception_table%s
   --  system.exception_table%b
   --  system.memory%s
   --  system.memory%b
   --  system.standard_library%b
   --  system.secondary_stack%s
   --  system.soft_links%b
   --  system.secondary_stack%b
   --  system.traceback%s
   --  ada.exceptions%b
   --  system.traceback%b
   --  test%b
   --  END ELABORATION ORDER

end ada_main;

pragma Ada_95;
pragma Source_File_Name (ada_main, Spec_File_Name => "b~test.ads");
pragma Source_File_Name (ada_main, Body_File_Name => "b~test.adb");

package body ada_main is
   pragma Warnings (Off);

   procedure Do_Finalize;
   pragma Import (C, Do_Finalize, "system__standard_library__adafinal");

   Local_Priority_Specific_Dispatching : constant String := "";
   Local_Interrupt_States : constant String := "";

   procedure adainit is
      E13 : Boolean; pragma Import (Ada, E13, "system__soft_links_E");
      E23 : Boolean; pragma Import (Ada, E23, "system__exception_table_E");
      E17 : Boolean; pragma Import (Ada, E17, "system__secondary_stack_E");

      Main_Priority : Integer;
      pragma Import (C, Main_Priority, "__gl_main_priority");
      Time_Slice_Value : Integer;
      pragma Import (C, Time_Slice_Value, "__gl_time_slice_val");
      WC_Encoding : Character;
      pragma Import (C, WC_Encoding, "__gl_wc_encoding");
      Locking_Policy : Character;
      pragma Import (C, Locking_Policy, "__gl_locking_policy");
      Queuing_Policy : Character;
      pragma Import (C, Queuing_Policy, "__gl_queuing_policy");
      Task_Dispatching_Policy : Character;
      pragma Import (C, Task_Dispatching_Policy, "__gl_task_dispatching_policy");
      Priority_Specific_Dispatching : System.Address;
      pragma Import (C, Priority_Specific_Dispatching, "__gl_priority_specific_dispatching");
      Num_Specific_Dispatching : Integer;
      pragma Import (C, Num_Specific_Dispatching, "__gl_num_specific_dispatching");
      Main_CPU : Integer;
      pragma Import (C, Main_CPU, "__gl_main_cpu");
      Interrupt_States : System.Address;
      pragma Import (C, Interrupt_States, "__gl_interrupt_states");
      Num_Interrupt_States : Integer;
      pragma Import (C, Num_Interrupt_States, "__gl_num_interrupt_states");
      Unreserve_All_Interrupts : Integer;
      pragma Import (C, Unreserve_All_Interrupts, "__gl_unreserve_all_interrupts");
      Zero_Cost_Exceptions : Integer;
      pragma Import (C, Zero_Cost_Exceptions, "__gl_zero_cost_exceptions");
      Detect_Blocking : Integer;
      pragma Import (C, Detect_Blocking, "__gl_detect_blocking");
      Default_Stack_Size : Integer;
      pragma Import (C, Default_Stack_Size, "__gl_default_stack_size");
      Leap_Seconds_Support : Integer;
      pragma Import (C, Leap_Seconds_Support, "__gl_leap_seconds_support");

      procedure Install_Handler;
      pragma Import (C, Install_Handler, "__gnat_install_handler");

      Handler_Installed : Integer;
      pragma Import (C, Handler_Installed, "__gnat_handler_installed");
   begin
      Main_Priority := -1;
      Time_Slice_Value := -1;
      WC_Encoding := 'b';
      Locking_Policy := ' ';
      Queuing_Policy := ' ';
      Task_Dispatching_Policy := ' ';
      Priority_Specific_Dispatching :=
        Local_Priority_Specific_Dispatching'Address;
      Num_Specific_Dispatching := 0;
      Main_CPU := -1;
      Interrupt_States := Local_Interrupt_States'Address;
      Num_Interrupt_States := 0;
      Unreserve_All_Interrupts := 0;
      Zero_Cost_Exceptions := 1;
      Detect_Blocking := 0;
      Default_Stack_Size := -1;
      Leap_Seconds_Support := 0;

      if Handler_Installed = 0 then
         Install_Handler;
      end if;

      System.Exception_Table'Elab_Body;
      E23 := True;
      System.Soft_Links'Elab_Body;
      E13 := True;
      System.Secondary_Stack'Elab_Body;
      E17 := True;
   end adainit;

   procedure adafinal is
   begin
      Do_Finalize;
   end adafinal;

   function main
     (argc : Integer;
      argv : System.Address;
      envp : System.Address)
      return Integer
   is
      procedure initialize (Addr : System.Address);
      pragma Import (C, initialize, "__gnat_initialize");

      procedure finalize;
      pragma Import (C, finalize, "__gnat_finalize");

      procedure Ada_Main_Program;
      pragma Import (Ada, Ada_Main_Program, "_ada_test");

      SEH : aliased array (1 .. 2) of Integer;

      Ensure_Reference : aliased System.Address := Ada_Main_Program_Name'Address;
      pragma Volatile (Ensure_Reference);

   begin
      gnat_argc := argc;
      gnat_argv := argv;
      gnat_envp := envp;

      Initialize (SEH'Address);
      adainit;
      Break_Start;
      Ada_Main_Program;
      Do_Finalize;
      Finalize;
      return (gnat_exit_status);
   end;

--  BEGIN Object file/option list
   --   ./test.o
   --   -L./
   --   -L/usr/lib/gcc/x86_64-linux-gnu/4.6/adalib/
   --   -shared
   --   -lgnat-4.6
--  END Object file/option list   

end ada_main;

Lots of stuff in there, but you get the idea. See the "main" procedure? That call's adainit, then the actual procedure Ada_Main_Program_Name - test.

So, for bare hardware you need to mess around with the gnatbind step like this so that it doesn't generate some stuff, my b~blink.adb main is:

   procedure main is

      procedure Ada_Main_Program;
      pragma Import (Ada, Ada_Main_Program, "_ada_blink");

      Ensure_Reference : aliased System.Address := Ada_Main_Program_Name'Address;
      pragma Volatile (Ensure_Reference);

   begin
      adainit;
      Break_Start;
      Ada_Main_Program;
   end;

I just use the default discovery startup code which calls main from some assembly after setting up the hardware.

Luke.

Re: understanding runtime support

[Lucretia]

Having spoken to you on IRC and email about this, I know what you are trying to do. Here are your options:

1) Use an existing OS and build GNAT to target that for your hardware.
2) Use bare metal GNAT - which isn't easy.

As for 1, you have a number of options:

* RTEMS
* MarteOS
* Linux (built for embedded target) + UClibc + GNAT

Each will require some work to target your hardware, as they will require drivers written to access the hardware - you would have to do this yourself anyway for bare metal programming.

Linux has been built for m68k machines, GNAT builds on Linux and would be trivial to add m68k for Linux, even though I remember having GNAT on an Amiga for both Linux and AmigaOS years ago.

If you went bare metal compiler, you would need to define what you needed in the runtime. Do you really need tasking? Do you really need full exception handling? If not, you can just have local exceptions which will call last_chance_handler anytime something goes wrong, in that procedure, you can do whatever you like, drop into remote gdb, dump the regs over serial, etc.

Luke.

Re: understanding runtime support

[mjsilva]

On Monday, May 14, 2012 11:48:08 PM UTC-7, Randy Brukardt wrote:
> <mjsilva@sc...com> wrote in message 
> news:10099625.0.1337029342748.JavaMail.geo-discussion-forums@yneh4...
> > Sadly, there does not seem to be a cookbook as to how to create such a 
> > bare metal port for other devices/families.
> 
> Nothing "sad" about it; it's unavoidable. There is no "cookbook" to creating 
> bare machine versions; they have to be tailored to the device and board 
> capabilities. 

Again, I look at the numbers of Ada-suitable microcontrollers being shipped (tens of billions), and there's no clear way to get Ada on most of them.  That seems extremely short-sighted for the growth of Ada into markets it could become a strong player in.  

I look back on the MIL-STD-1750A and think if Ada was put on that (and I remember the claims about what a small runtime was required), how hard could it be to put it on modern devices of equal or greater capacity?

So what's involved in e.g. Ada with Ravenscar tasking, no files, no propagated exceptions?  I would expect something like N Ada stub subprograms that need to be customized for the hardware, along with some data objects.  These subprograms would be hooked up to a hardware timer and whatever other hardware subsystems necessary.  

Only a very few dedicated souls will read through existing source to figure out a way to port that source, but if a cookbook existed, similar to the doc for an RTOS that tells what each stub subprogram must be coded to provide, and defines each required data object, I suspect Ada would suddenly start appearing on a lot more varied hardware, and start getting noticed by a lot more people.  And that would be a Very Good Thing IMO.

Re: understanding runtime support

[Mike Silva]

On Tuesday, May 15, 2012 7:55:55 AM UTC-7, Lucretia wrote:
> If you went bare metal compiler, you would need to define what you needed in the runtime. Do you really need tasking? Do you really need full exception handling? If not, you can just have local exceptions which will call last_chance_handler anytime something goes wrong, in that procedure, you can do whatever you like, drop into remote gdb, dump the regs over serial, etc.
> 
> Luke.
IMO having simple tasking (Ravenscar) and suitable timing (delay, delay until) would be enough for a great many embedded chores.  Everything else could build on that core.

I'm guessing that this is pretty much what the Lego Mindstorms port has, but I haven't looked.

Re: understanding runtime support

[Lucretia]

> Only a very few dedicated souls will read through existing source to figure out a way to port that source, but if a cookbook existed, similar to the doc for an RTOS that tells what each stub subprogram must be coded to provide, and defines each required data object, I suspect Ada would suddenly start appearing on a lot more varied hardware, and start getting noticed by a lot more people.  And that would be a Very Good Thing IMO.

I agree.

So, you start with system.ads, You start by defining it's number types, storage types and memory types. Look at the private section of the file, it has some parameters you set telling you that the docs are in targparm.ads - which they are. If you don't need anything else, that's it. If you need more runtime, you have to look further into the source.

If you need to return unconstrained types, like String, then you can create your own secondary stack package, look at s-secsta.ad[sb] and use that or modify it or create your own. You will need to look at the binder at this point as the binder can change the size of the secondary stack.

Luke.

Re: understanding runtime support

[Lucretia]

On Tuesday, May 15, 2012 4:32:43 PM UTC+1, Mike Silva wrote:

> > 
> > Luke.
> IMO having simple tasking (Ravenscar) and suitable timing (delay, delay until) would be enough for a great many embedded chores.  Everything else could build on that core.

Probably, but I have no idea what would go into that. I only use the FSF GNAT for licence reasons, I don't want to look at the GPL'd code too closely in case I ever duplicate it and cause further legal problems for myself. *Just in case I ever do anything commercial. To get my ZFP runtime, I looked at the GNAT pro docs - available on interweb - to see what packages were provided and just copied those over from the FSF source. I suppose it would be possible to look at the ravenscar docs to see what packages are needed, but I'm betting the tasking packages are custom versions that are cut down.
 
> I'm guessing that this is pretty much what the Lego Mindstorms port has, but I haven't looked.

I know that is Ravenscar.

Luke.

Re: understanding runtime support

[Lucretia]

On Tuesday, May 15, 2012 4:22:30 PM UTC+1, mjs...@scriptoriumdesigns.com wrote:

> Only a very few dedicated souls will read through existing source to figure out a way to port that source, but if a cookbook existed, similar to the doc for an RTOS that tells what each stub subprogram must be coded to provide, and defines each required data object, I suspect Ada would suddenly start appearing on a lot more varied hardware, and start getting noticed by a lot more people.  And that would be a Very Good Thing IMO.

I actually think having this document would be a good idea. I'm willing to put together the info for bare board that I've worked out into a doc to include.

Luke.

Re: understanding runtime support

[Jeffrey Carter]

> On Monday, May 14, 2012 1:04:56 PM UTC-7, Patrick wrote:
>
> Is full, multi-tasking, Ada only used for embedded design by
> companies like Boeing that can port Ada to new devices all by
> themselves? What do small time people like me do?

I'm someone who has written embedded S/W for "companies like Boeing". I've never 
had the "pleasure" of working on bare metal; when working for such companies, we 
always used an RTOS such as VxWorks or Lynx.

I don't see why you wouldn't want to do as "companies like Boeing" do and use 
RTEMS or MaRTE, or even Debian.

-- 
Jeff Carter
"My mind is a raging torrent, flooded with rivulets of
thought, cascading into a waterfall of creative alternatives."
Blazing Saddles
89

Re: understanding runtime support

[mjsilva]

On Tuesday, May 15, 2012 9:05:51 AM UTC-7, Lucretia wrote:
> On Tuesday, May 15, 2012 4:22:30 PM UTC+1, mjs...@scriptoriumdesigns.com wrote:
> 
> > Only a very few dedicated souls will read through existing source to figure out a way to port that source, but if a cookbook existed, similar to the doc for an RTOS that tells what each stub subprogram must be coded to provide, and defines each required data object, I suspect Ada would suddenly start appearing on a lot more varied hardware, and start getting noticed by a lot more people.  And that would be a Very Good Thing IMO.
> 
> I actually think having this document would be a good idea. I'm willing to put together the info for bare board that I've worked out into a doc to include.
> 
> Luke.

You said you're working on an STM32 Discovery board?  Which one?  I've worked with the STM32VLDiscovery, and the M4 Discovery is intriguing as well.

Re: understanding runtime support

[Brian Drummond]

On Tue, 15 May 2012 09:47:44 +0200, Jacob Sparre Andersen wrote:

> mjsilva@scriptoriumdesigns.com writes:
>> On Monday, May 14, 2012 1:04:56 PM UTC-7, Patrick wrote:
> 
>>> Now it seems I am supposed to roll my own runtime or other low level
>>> solution, [...]

Good discussion, and you are not alone in finding this frustrating.
I have also started learning how to build gcc with Ada support for 
embedded targets. There are other interested parties, for platforms 
including the Nintendo DS, and Android.

> If you want to use Arduino as your target system, there is a
> ready-to-compile GNAT version (AVR-Ada), which doesn't support the
> Ravenscar profile yet, but is likely to get there.

>> Sadly, there does not seem to be a cookbook as to how to create such a
>> bare metal port for other devices/families.
> 
> Apparently not. - Maybe it is time to write one?

Or port one.

http://wiki.osdev.org/Bare_Bones

This shows it's quite a complicated process even in C, where support for 
different targets is more pervasive despite the relative merits of the 
languages.

Translating this tutorial to Ada looks (a) feasible to me, and (b) a good 
way to discover the answers to some of the questions in this thread.

It shows how the C "main" is linked to a minimal C rts (written partly in 
assembler, specific to x86 but very small) and accesses basic services 
through that rts.

Part of the problem is that Ada expects more from a rts than C does. One 
approach is to expect less (for example get simple examples to build and 
do something with "pragma no-run-time"). Then use that as a basis for 
creating a minimal runtime for a new platform. The AVR-Ada rts would be a 
useful starting point, as would the (Gnat 3.15 era) run time 
documentation which was discussed here recently.

- Brian

Re: understanding runtime support

[Patrick]

Hi Jerry

That's just it. I want to do as boeing does but this fact was not in the books I have! thank you for your input. This solves many problems, although creates a new one in writing code tied to an OS and creates more distance from the machine(which can also be good)

Re: understanding runtime support

[Patrick]

Hi Brian

Thanks for the great link. I will read this in detail and post back if I can think of anything useful to say

Re: understanding runtime support

[Lucretia]

On Tuesday, May 15, 2012 5:29:44 PM UTC+1, mjs...@scriptoriumdesigns.com wrote:
> On Tuesday, May 15, 2012 9:05:51 AM UTC-7, Lucretia wrote:
> > On Tuesday, May 15, 2012 4:22:30 PM UTC+1, mjs...@scriptoriumdesigns.com wrote:
> > 
> > > Only a very few dedicated souls will read through existing source to figure out a way to port that source, but if a cookbook existed, similar to the doc for an RTOS that tells what each stub subprogram must be coded to provide, and defines each required data object, I suspect Ada would suddenly start appearing on a lot more varied hardware, and start getting noticed by a lot more people.  And that would be a Very Good Thing IMO.
> > 
> > I actually think having this document would be a good idea. I'm willing to put together the info for bare board that I've worked out into a doc to include.
> > 
> > Luke.
> 
> You said you're working on an STM32 Discovery board?  Which one?  I've worked with the STM32VLDiscovery, and the M4 Discovery is intriguing as well.

I actually haven't touched it for ages, but the blink app does build and runs on STMF4DISCOVERY board.

Luke.

Re: understanding runtime support

[tmoran]

> If you insist on programming the bare metal in Ada ...
> ...
> The Ada run-time did not support tasking or memory deallocation, and could
> not propagate exceptions beyond the frame that raised them.
  RR Software had a full Ada 83 that ran on DOS.  I don't recall DOS as
being all that far from bare metal - it was basically I/O.  And I'd be
curious, Randy, what Windows OS features were needed for, say, Ada 95.

Re: understanding runtime support

[Tero Koskinen]

On Tue, 15 May 2012 01:48:08 -0500
"Randy Brukardt" <randy@rrsoftware.com> wrote:
> One needs customers in order to make the large investments needed in this 
> sort of technology. RRS, at least, has never had anyone express any real 
> interest in ARM targets, so we've never even thought about such machines. 

Well, since I could be considered as RRS customer, you now know one
who is interested in running Ada on ARM.

Last year, I queried three Ada vendors (although not RR Software) and
asked whether they had some sort of support for ARM. Two of them
didn't have and third one was willing to do it for $$$$$ euros, so in
the end, I purchased ARM board (Gumstix Overo) capable of running
Debian armhf, and ported FSF GNAT there myself.

From vendors, I originally asked Ada compiler for a smaller ARM
microcontroller without MMU or any kind of OS (=bareboard version), but
like Raspberry Pi has shown, more powerful ARM systems can be pretty
cheap and small also.

> 
> Things rarely happen for free, you know.

FSF GNAT for Debian armhf is available for free (if you can accept
GMGPL license).

The .deb packages are now located at
http://iki.fi/tero.koskinen/debian/armhf/deb-packages/ , but
I hope that they end up to official Debian repositories at some point.

Have fun. :)

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

PS. Of course, since I have now GNAT for ARM, I don't expect to
have Janus/Ada for ARM.

Re: understanding runtime support

[Randy Brukardt]

<tmoran@acm.org> wrote in message news:jp0kbf$gvo$1@speranza.aioe.org...
>> If you insist on programming the bare metal in Ada ...
>> ...
>> The Ada run-time did not support tasking or memory deallocation, and 
>> could
>> not propagate exceptions beyond the frame that raised them.
>  RR Software had a full Ada 83 that ran on DOS.  I don't recall DOS as
> being all that far from bare metal - it was basically I/O.  And I'd be
> curious, Randy, what Windows OS features were needed for, say, Ada 95.

We use the Windows heap for memory management, rather than our own design 
that we used on MS-DOS. Otherwise, the compiler is basically the same (we 
don't use threads, for instance, so our tasking could easily run on bare 
metal; similarly, we don't use Windows exceptions, mainly because I couldn't 
find any documentation in 1998 as to how they are handled in code). So the 
Windows services used are mostly memory management and I/O.

                                  Randy.

Re: understanding runtime support

[Simon Wright]

Tero Koskinen <tero.koskinen@iki.fi> writes:

> FSF GNAT for Debian armhf is available for free (if you can accept
> GMGPL license).

This is great. Do you have a strong reason for GMGPL rather than GPL V3
+ Runtime Library Exception? (FSF FNAT now uses this).

Re: understanding runtime support

[Tero Koskinen]

On Thu, 17 May 2012 07:39:19 +0100
Simon Wright <simon@pushface.org> wrote:

> Tero Koskinen <tero.koskinen@iki.fi> writes:
> 
> > FSF GNAT for Debian armhf is available for free (if you can accept
> > GMGPL license).
> 
> This is great. Do you have a strong reason for GMGPL rather than GPL V3
> + Runtime Library Exception? (FSF FNAT now uses this).

I think the actual license of my Debian armhf gcc-4.6 packages are
same what Debian uses. I didn't make any (my own) modifications to the
source code. I just applied selected set of patches (from Debian gcc
package) in each phase when I did the port.

So the license should be GPLv3 + runtime library exception.

-- 
Tero Koskinen - http://iki.fi/tero.koskinen/

Re: understanding runtime support

[John B. Matthews]

In article <m2vcjv8g6g.fsf@nidhoggr.home>,
 Simon Wright <simon@pushface.org> wrote:

> Tero Koskinen <tero.koskinen@iki.fi> writes:
> 
> > FSF GNAT for Debian armhf is available for free (if you can accept
> > GMGPL license).
> 
> This is great. Do you have a strong reason for GMGPL rather than GPL 
> V3 + Runtime Library Exception? (FSF FNAT now uses this).

For reference:

<http://en.wikipedia.org/wiki/GNAT_Modified_General_Public_License>

<http://www.gnu.org/licenses/gcc-exception-faq.html>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>