jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17896
Joined: Sat Jul 30, 2011 7:41 pm

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:15 pm

Heater wrote:jamesh,
Getting rid of problems early, as with type checking like this, save a lot of time testing, debugging, retesting later on.
I have always favoured a strongly typed language for exactly that reason and it has always been "common wisdom". Pascal was always a good example and Ada perhaps king of the compile time checkers. C was always a bit lax, especially early compilers that seemed to be able to make code out of any random source text. C++ is a lot better.

But recently I have started to think it makes little sense. Is that common wisdom true?

Firstly, as I said, if you are serious about your program's correctness you are going to have reviews of everything and multiple levels of testing, unit tests, integration tests etc etc. Ergo, all that compile time checking is not saving you from a huge pile of verification work anyway.

Secondly, in the extreme I can write code in a really lax dynamically typed language, like JavaScript say. Given that C++ compilers are so slow (No idea about Ada today) I can have have my JS script out of the editor, run and tested by my unit tests before the C++ compiler has even finished compiling or arrived at it's first error message!

Thirdly, all that type checking and such does not of course save you from all the other logical errors you can make in your code. Which brings us back to testing...
Testing doesn't find everything (but you still need to do it), so by ensuring you are getting as much as possible 'tested' at compile time, you will improve the final time to market. Less bugs to fix later on when bugs take longer to fix anyway.

I recently spent some time porting some Videocore code to run under linux. Even simply moving to a different compiler (gcc) showed up quite a few programming issues (the latest GCC really does dig out some interesting faults), and then running under valgrind shows up various memory leaks and threading issues! So even without writing any test code, and just using standard tools, I found a load of issues. And testing on top of that should show up a load more. Now, automating the valgrind run on each checkin means we keep that part of the codebase clean (relatively).
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:18 pm

Obviously the first compilers could not have been written in Ada anyway as there would be no compiler for it
Yes and no. That is what is known as bootstraping a self hosting compiler. You write the compiler in its own language supporting just enough to compile it self, then you hand compile it and use that hand compiled version to compile the original source, then extend the compiler until the full language is supported.

This has been an issue for self hosting compilers from the begining of compilers, and bootstraping a self hosting compiler for a new HLL is a well known procedure. It is akin to bootstraping a self hosting assembler on a completely new processor type.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:19 pm

Lucretia wrote:
DavidS wrote:In the volume "The Ada Reference"
You mean the Ada LRM?
NO
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:23 pm

joan wrote:
Lucretia wrote: Where does it state this? I've never seen it and I know there were Ada compilers written in C++ BITD.

Luke.
If memory serves the First Ada compilers were not only written in C/C++ but their output was also C/C++ source code (for compilation by the native C/C++ compiler).
I do not know about the compilers before the requirements of the language were written as I was not yet born. ( I was born in 1978). Though every Ada compiler that I had used back when I actualy played with Ada folowed this rule.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Lucretia
Posts: 43
Joined: Sun Aug 28, 2011 10:49 pm
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:26 pm

DavidS wrote:
Obviously the first compilers could not have been written in Ada anyway as there would be no compiler for it
Yes and no. That is what is known as bootstraping a self hosting compiler. You write the compiler in its own language supporting just enough to compile it self, then you hand compile it and use that hand compiled version to compile the original source, then extend the compiler until the full language is supported.

This has been an issue for self hosting compilers from the begining of compilers, and bootstraping a self hosting compiler for a new HLL is a well known procedure. It is akin to bootstraping a self hosting assembler on a completely new processor type.
I know.

Lucretia
Posts: 43
Joined: Sun Aug 28, 2011 10:49 pm
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:28 pm

DavidS wrote:
joan wrote:
Lucretia wrote: Where does it state this? I've never seen it and I know there were Ada compilers written in C++ BITD.

Luke.
If memory serves the First Ada compilers were not only written in C/C++ but their output was also C/C++ source code (for compilation by the native C/C++ compiler).
I do not know about the compilers before the requirements of the language were written as I was not yet born. ( I was born in 1978). Though every Ada compiler that I had used back when I actualy played with Ada folowed this rule.
There is no such rule. If there were it would be in the LRM or the Rationale, it's not. And as I stated above it could never be a rule, which you have already conceded by mentioning bootstrapping above. I think you've read something wrong, otherwise, scan it and post it because I think others would like to see this document.

Luke.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:53 pm

Ok I am done feuling your discontent on this one. If I had the ISBN I would gladly provide it so you could look it up.

Though you can take a look at any of the old Ada compilers for DOS or Atari ST, from the mid 1980s and see that they are written in 100% Ada. And in many cases the same exact source for multiple platforms (with obvious modifications for the back end).
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

User avatar
DavidS
Posts: 3009
Joined: Thu Dec 15, 2011 6:39 am
Location: USA
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:55 pm

And as to the concept of scanning, I would gladdly do so, will you provide a USB Scanner that works well with RISC OS?

This is DavidS signing clear.
ARM BASIC: For the love of Simplicity, Fast Interpreted BASIC, and Assembly Language.
Always KISS Keep It Simple Silly.

Lucretia
Posts: 43
Joined: Sun Aug 28, 2011 10:49 pm
Contact: Website

Re: Compiling ADA for ARM

Wed Nov 20, 2013 5:58 pm

DavidS wrote:Ok I am done feuling your discontent on this one. If I had the ISBN I would gladly provide it so you could look it up.

Though you can take a look at any of the old Ada compilers for DOS or Atari ST, from the mid 1980s and see that they are written in 100% Ada. And in many cases the same exact source for multiple platforms (with obvious modifications for the back end).
I'm not saying that these Ada compiler's weren't written in Ada, I'm disputing the fact that there is anything written anywhere that states that they have to be.

Luke.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17896
Joined: Sat Jul 30, 2011 7:41 pm

Re: Compiling ADA for ARM

Wed Nov 20, 2013 9:21 pm

DavidS wrote:And as to the concept of scanning, I would gladdly do so, will you provide a USB Scanner that works well with RISC OS?

This is DavidS signing clear.
No, you have to provide a OS that supports a USB scanner.

I'll get my coat.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

AdaDev
Posts: 1
Joined: Thu Nov 21, 2013 7:58 pm

Re: Compiling ADA for ARM

Thu Nov 21, 2013 8:17 pm

An interesting read! I found this also looking for Ada on ARM information, looking for something different/interesting to do on the Pi that doesn't involve Linux.

My day job is stereotypical Ada use in defence safety critical software, in the UK.

Thanks for the link to the osdev info, I have also been looking at TAMP this week during my lunch breaks.

Lucretia
Posts: 43
Joined: Sun Aug 28, 2011 10:49 pm
Contact: Website

Re: Compiling ADA for ARM

Fri Nov 22, 2013 7:31 am

AdaDev wrote:An interesting read! I found this also looking for Ada on ARM information, looking for something different/interesting to do on the Pi that doesn't involve Linux.

My day job is stereotypical Ada use in defence safety critical software, in the UK.

Thanks for the link to the osdev info, I have also been looking at TAMP this week during my lunch breaks.
No problems. Yeah, my aim is among other things, to write an OS in Ada. Trying to get GNAT to do what I want was the first thing I did with the TAMP repository. The bare bones stuff is actually based on a hello world kernel I wrote on the PC using multiboot about 9 years ago, just updated it for the wiki. Also, it was written to get more out there about the language. :mrgreen:

Luke.

Heater
Posts: 7753
Joined: Tue Jul 17, 2012 3:02 pm

Re: Compiling ADA for ARM

Sat Nov 23, 2013 3:27 pm

Lucretia,

No, I would not say Ada is crap. I was only commenting on how it's attractions were not enough to sustain or grow it's use when the mandate was dropped. Why that was I cannot say, perhaps it was just the lack of free and or open source compilers.

My observation of the use of Ada in the avionics industry is that large projects can still get into a dangerous mess even with all the type safety and static analysis of the Ada language.

Jamesh,
Testing doesn't find everything (but you still need to do it), so by ensuring you are getting as much as possible 'tested' at compile time, you will improve the final time to market. Less bugs to fix later on when bugs take longer to fix anyway.
I'm not yet prepared to say we should throw out static type checking and static analysis. But my thesis goes like this:

We have belts and we have braces. The belts are the strict, statically typed languages with static analysis at compile time. The braces are the testing, unit tests, integration tests and so on.

Given that you want to be sure your program works you will employ a lot of testing, you will have run-time coverage analysis, branch analysis and so on. You will exercise your variables at the limits of their ranges and so on. Projects like this will have ten times, or more, lines of test harness code than
the product itself.

In this scenario we can see that the "belts" become less important. Static analysis may well be redundant.

So, just perhaps, a "sloppy" language like Python or JavaScript is actually quite acceptable. It may even have benefits if the unit tests are so easy to run as you work. You can even have the tests run on the fly as you edit. Static analysis is totally replaced by dynamic analysis and testing.


I do agree that getting your code up under different compilers can show up all kinds of weirdness in your code.

Valgrind is great, but slow and does not catch many things. You certainly have to have tests to run under Valgrind in order to get the most out of it.

You might like to have a look at the Clang compiler and it's run time analysis tools. And don't forget gcov.

User avatar
joan
Posts: 12746
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Compiling ADA for ARM

Sat Nov 23, 2013 3:42 pm

Heater wrote:Lucretia,

No, I would not say Ada is crap.
...
I disagree. Ada is pretty much so.

Was that the problem with its adoption though?

In my experience it was poor users who didn't understand the appropriate constructs to solve software problems. I need to decouple I/O - throw in a task. I need to do this in series - throw in a task. I need to process an interrupt - throw in a task.

Python reminds me of Ada.

Heater
Posts: 7753
Joined: Tue Jul 17, 2012 3:02 pm

Re: Compiling ADA for ARM

Sat Nov 23, 2013 4:22 pm

A little story...

Five years ago, or so, I was making a serious effort to learn Ada, or relearn as I had not used it since the late 1980's or so and I wanted to play with GNAT.

I was happily following a tutorial published on line by some American university compsci lecturer. Problems came with, objects, inheritance and all that. What do they call it in Ada land, "tagged types."

At some point, this lecturer had some ugly hack in his example code to get it to work. Otherwise it was not making the correct method call. This hack was complete with a comment like "we have to do this here because Ada is absurd !"

I thought this was a bit odd, and after studying the thing for a while learned how to do that tagged type thing properly. Ada was not "absurd" but the lecturer obviously had the same difficulty understanding it as I did.

I emailed him and gave a snippet of code showing how to correct his tutorial. His reply was to the effect that demand for Ada teaching had dropped to zero and they had dropped their Ada courses but he would look at the tutorial example and fix it.

At that point a gave up with Ada.

I noticed a few years later that the tutorial in question had not be fixed.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17896
Joined: Sat Jul 30, 2011 7:41 pm

Re: Compiling ADA for ARM

Sat Nov 23, 2013 5:17 pm

Heater wrote:Lucretia,

No, I would not say Ada is crap. I was only commenting on how it's attractions were not enough to sustain or grow it's use when the mandate was dropped. Why that was I cannot say, perhaps it was just the lack of free and or open source compilers.

My observation of the use of Ada in the avionics industry is that large projects can still get into a dangerous mess even with all the type safety and static analysis of the Ada language.

Jamesh,
Testing doesn't find everything (but you still need to do it), so by ensuring you are getting as much as possible 'tested' at compile time, you will improve the final time to market. Less bugs to fix later on when bugs take longer to fix anyway.
I'm not yet prepared to say we should throw out static type checking and static analysis. But my thesis goes like this:

We have belts and we have braces. The belts are the strict, statically typed languages with static analysis at compile time. The braces are the testing, unit tests, integration tests and so on.

Given that you want to be sure your program works you will employ a lot of testing, you will have run-time coverage analysis, branch analysis and so on. You will exercise your variables at the limits of their ranges and so on. Projects like this will have ten times, or more, lines of test harness code than
the product itself.

In this scenario we can see that the "belts" become less important. Static analysis may well be redundant.

So, just perhaps, a "sloppy" language like Python or JavaScript is actually quite acceptable. It may even have benefits if the unit tests are so easy to run as you work. You can even have the tests run on the fly as you edit. Static analysis is totally replaced by dynamic analysis and testing.


I do agree that getting your code up under different compilers can show up all kinds of weirdness in your code.

Valgrind is great, but slow and does not catch many things. You certainly have to have tests to run under Valgrind in order to get the most out of it.

You might like to have a look at the Clang compiler and it's run time analysis tools. And don't forget gcov.
Nope. As I said above, you can test the living daylights out of something, with 10 times as much test code as production code. You may still miss something (and when was the last project you worked on that did that much testing). So static testing of stuff at compile time is always going to be necessary and will always find bugs.

As for Valgrind - we found it to be particular effective at finding issues - especially the helgrind thread checker. Obviously it doesn't find everything, but it certainly found a lot of issues when I ported stuff to linux. But then. GCC found a load of issues at compile time as well....e.g. lots of redundant code that testing would not have found....may not cause bugs but it caused inefficiencies.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

Heater
Posts: 7753
Joined: Tue Jul 17, 2012 3:02 pm

Re: Compiling ADA for ARM

Sun Nov 24, 2013 1:19 pm

jamesh,
Nope....static testing of stuff at compile time is always going to be necessary and will always find bugs.
Get yourself a stiff drink and sit down. I have something to say that you might find very disturbing.

Static type checking and other static analysis by a compiler is not able to find any bugs.

In case you think I'm crazy let me try and prove that statement:

Theorem: Given that a programmer P is given functional requirements R from which he generates program source code S and compiler C that generates an executable program E from S, then it is impossible for C to confirm the correctness of E with respect to R.

Proof:

1) Programmer P transforms requirements R into source text S so we have:

S = P(R)

2) Compiler C transforms S in the executable E so we have:

E = C(S)

3) There is no information about R in S,

4) Ergo C cannot check that S is in any way a correct implementation of R.

Example:

R = "The program shall take two integer inputs, add them together and output the resulting integer sum"

S = P(R) = "x := readInt(); y := readInt(); sum := x - y; writeInt(sum);

E = C(S) = ...some binary gunk...

Clearly there is a bug here that no amount of static analysis can find. In short the compiler does not know the intent of the requirements or the programmer. Asked to write a spread sheet the programmer could write a flight simulator. The compiler and static analysis may happily tell you there is no problem with it!

I go on to claim that "Code review and testing are the only way to find bugs."

So where does the myth contained in your statement come from?

I think it is an illusion. An illusion caused by the fact that the programmer is reviewing his code constantly as he writes it and he will be doing some minimal testing at least to check the thing runs at all and does the right thing for a bunch of expected inputs.

The vast ocean of potential bugs is often not tested for so the few that are picked up by compiler warnings make it look as if the compiler is doing valuable
work in all that type checking and analysis.

Valgrind, for example, is useful but it does require that you run the code for it to be able to find any issues. You should be exercising your code against many test cases when using Valgrind as you have to exercise all the branches where a memory leak might be created.
(and when was the last project you worked on that did that much testing)
Glad you asked, that would be pretty much every project I worked on from the early 1980's to the late 1990's. One of the highlights of which was working with the team at GEC-Marconi Avionics that developed the hardware and software for the Boeing 777 Primary Flight Computers.

SKyd3R
Posts: 11
Joined: Thu Nov 14, 2013 9:30 am

Re: Compiling Ada for ARM

Mon Nov 25, 2013 4:28 pm

Wow, what a debate we have here, I will post the solution I found in case someone else is looking for it.
I found an arm-eabi compiler that seems to work. It's supposed to be used for the LEGO Mindstorm, but will do the job.

Here it is the link:
http://www.dit.upm.es/~str/proyectos/mi ... index.html
Lucretia, I think I'll follow your job closely, it seems to be very helpfull!!


Thanks to everybody for the possible solutions (and the interesting debate, carry on).

Lucretia wrote:Oh and it's Ada (a girl's name), not ADA (an acronym).
Sorry about that, I made the proper modifications. The first programmer ever deserves recognition.
Last edited by SKyd3R on Mon Nov 25, 2013 4:53 pm, edited 2 times in total.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17896
Joined: Sat Jul 30, 2011 7:41 pm

Re: Compiling ADA for ARM

Mon Nov 25, 2013 4:31 pm

Heater wrote:jamesh,
(and when was the last project you worked on that did that much testing)
Glad you asked, that would be pretty much every project I worked on from the early 1980's to the late 1990's. One of the highlights of which was working with the team at GEC-Marconi Avionics that developed the hardware and software for the Boeing 777 Primary Flight Computers.
Ah, that explains a great deal.

EDIT : To add.Boeing 777, 2MLOC, here's a statement from a review. "Honeywell approached the request by conducting an extensive study into the benefits of Ada versus the C programming language. When the results were in, Honeywell agreed with the decision to use Ada: the study concluded that Ada's built-in safety features would translate into less time, expense, and concern devoted to debugging the software."

Those 2MLOC written over 10 years I think. As a comparison, the sort of stuff I work on, is written in 6-12 months, at a higher lines per engineer per day, in a shorter timescale. Because it not safety critical, there is no need to go to the huge test expense seen on things like airliners. So given that the market I work in has a turnaround time an order of magnitude faster that aerospace, different mechanisms are necessary. You simply cannot test something to death, so you HAVE to take every opportunity to remove bugs at the first opportunity. That means decent compilers with decent checking with decent tools (like valgrind) AND as much testing as you can fit in, in the time available.

As with everything in life, there are different use cases that need different processes.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

MrAda
Posts: 7
Joined: Sun Dec 01, 2013 10:26 pm

Re: Compiling Ada for ARM

Sun Dec 01, 2013 10:44 pm

I would love to have Ada programs running on this device, using Qt! I have given up on GTK/GDK as V3 broke everything I had ever written.

Just don't know where to start, is there a compiler out there that can target an ARM processor?

Does anyone know any performance metrics on the R-Pi?

chris

Heater
Posts: 7753
Joined: Tue Jul 17, 2012 3:02 pm

Re: Compiling Ada for ARM

Sun Dec 01, 2013 11:46 pm

The is an Ada package for GNAT on Raspian. You could try :

Code: Select all

$ sudo apt-get install gnat
No idea about Qt bindings though.

MrAda
Posts: 7
Joined: Sun Dec 01, 2013 10:26 pm

Re: Compiling Ada for ARM

Sun Dec 01, 2013 11:49 pm

I have been working on a set of general bindings to C++. Qt is doable, just have to work out the slot/signal mechanisms or come up with my own.

User avatar
joan
Posts: 12746
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Compiling ADA for ARM

Mon Dec 02, 2013 12:12 am

jamesh wrote:
Heater wrote:jamesh,
(and when was the last project you worked on that did that much testing)
Glad you asked, that would be pretty much every project I worked on from the early 1980's to the late 1990's. One of the highlights of which was working with the team at GEC-Marconi Avionics that developed the hardware and software for the Boeing 777 Primary Flight Computers.
Ah, that explains a great deal.

EDIT : To add.Boeing 777, 2MLOC, here's a statement from a review. "Honeywell approached the request by conducting an extensive study into the benefits of Ada versus the C programming language. When the results were in, Honeywell agreed with the decision to use Ada: the study concluded that Ada's built-in safety features would translate into less time, expense, and concern devoted to debugging the software."

Those 2MLOC written over 10 years I think. As a comparison, the sort of stuff I work on, is written in 6-12 months, at a higher lines per engineer per day, in a shorter timescale. Because it not safety critical, there is no need to go to the huge test expense seen on things like airliners. So given that the market I work in has a turnaround time an order of magnitude faster that aerospace, different mechanisms are necessary. You simply cannot test something to death, so you HAVE to take every opportunity to remove bugs at the first opportunity. That means decent compilers with decent checking with decent tools (like valgrind) AND as much testing as you can fit in, in the time available.

As with everything in life, there are different use cases that need different processes.
I thought the 7J7 Primary Flight Computer had three separate software lanes implementing identical requirements. One in C, one in Ada, and one in assembler.

Heater
Posts: 7753
Joined: Tue Jul 17, 2012 3:02 pm

Re: Compiling Ada for ARM

Mon Dec 02, 2013 5:16 am

joan,
I thought the 7J7 Primary Flight Computer had three separate software lanes implementing identical requirements. One in C, one in Ada, and one in assembler.

No it did not.

I think that was the plan but expense rued it out. It was one Ada development run on all CPU's.

The 777 PFC's have 3 big black boxes each containing three different processor cards. Intel 486, Motorola 68000 (and something) and AMD 29K.

The thre internal processors check against each other before the box produces results. Which are then compared with the other two boxes.

tufty
Posts: 1454
Joined: Sun Sep 11, 2011 2:32 pm

Re: Compiling Ada for ARM

Mon Dec 02, 2013 8:59 am

Heater wrote:The thre internal processors check against each other before the box produces results. Which are then compared with the other two boxes.
Same code on each processor and box, no? I remember having a discussion with an Boeing guy at at IATA conference back in <mumbledy> who was (unofficially, obviously) worried about this (he may even have been worried about the "same spec" thing, thinking about it). Would have been in the 2-4 years following the A320 crash at Mulhouse-Habsheim, I guess.

Return to “Other languages”

Who is online

Users browsing this forum: No registered users and 7 guests