Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie.

[Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP>]

On 2013-03-26, Brian Drummond <brian@shapes.demon.co.uk> wrote:
> On Wed, 20 Mar 2013 13:18:57 +0000, Simon Clubley wrote:
>
>> On 2013-03-20, Brian Drummond <brian@shapes.demon.co.uk> wrote:
>>> On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote:
>
>>>> Reading the comments, I think my problem here isn't really with Ada,
>>>> but with GNAT; hence it's really a toolchain problem and not a
>>>> language problem.
> [...]
>>>> You also have no confidence that the model you have built is
>>>> sufficiently complete to result in a robust port.
>>>
>>> What in your view would be required to give you that confidence?
>>>
>>>
>> Coherent and structured porting documentation.
>> 
>> Something designed for documenting the porting process will cover the
>> overall architecture in a way which allows you to build a consistent
>> model and is also going to cover the major "gotcha" issues. Even if the
>> initial versions did not cover all the major issues, the later versions
>> would as a result of the inevitable peer review type process which would
>> occur.
>
> I admit I am surprised to hear documentation ahead of test. But that 
> makes it all the more worth hearing.
>

Both are required, but good documentation is way more important because it
answers the question "_why_ do we do this ?" but testing can only test what
has been written _after_ you understand what needs writing in the first
place.

For example, when discussing Ada exception support, a porting document
should discuss at a conceptual level what is required to implement exception
support in GNAT hence allowing you to build a model of how a exception
raised during the execution of user code flows through the various levels
of the compiler generated code and the RTS and into the low-level bits you
need to supply.

It should then go on to take a specific example from the current code base,
and show how the various bits of the current code base fit into that model.

The information you would obtain in that way would allow you to build a
much more robust and complete model than you would get trying to work it
out a bit at a time by looking at the code base only.

(And yes, I know the thesis already touches on some of this, although as
pointed out already the thesis is about a decade old and is written with
more of a academic than a practical focus. I am just using exception
support as a example.)

For me, it's all about building a model of operation. Looking at a code
base in isolation (as currently exists with GNAT) allows you to determine
_how_ various specific bits of code work, but it doesn't tell you _why_
they work in that way or easily tell how they fit into the greater whole.
This makes it very difficult to build a model of operation, covering GNAT
as a whole, by looking at the code base in isolation.

IOW, building a solid model of what is going on in the code base is the
root stage from which all later stages, including testing, are derived from.

> OK, here goes...
>
> http://sourceforge.net/projects/msp430ada/files/doc/MSP430-Ada.pdf/
> download
>
> how am I doing so far?
>
> Frank criticism welcome. 
>
> And I don't expect many people to actually follow the process at this 
> stage : it's a record of how I got to the current stage (that the 
> dedicated can follow). I am painfully aware that toolchains need to be 
> available in easier forms. 
>

Actually, I would expect to find duplicating the process of building this
specific compiler from what you have written in this document to be rather
easy. You have covered various issues in detail and provided lots of
references to source kits, including exact version numbers.

However, your document is more about how to build a specific port, although
people could look at the steps you have taken to get to this stage and
try duplicating them on their own architecture in a mechanical/by rote
fashion. What it does not discuss is _why_ the changes are needed or how
those changes fit into the overall GNAT/GCC architecture.

A by rote approach can get you quite a bit of the way (assuming a similar
architecture) but at some point, for example, when you start adding in
exception support to your new architecture, you need to have a model of
what is actually going on in GNAT and gcc.

Some specific notes from reading your document:

Have you hit any other volatile issues ? In C, I define the object itself,
rather than the data type, as volatile. This includes the case when the
data type is a struct (used when modelling a register set for a specific
peripheral).

Your gnatmake command may appear to be complicated, but it's the kind of
thing which could easily be turned into a pattern rule in a makefile so
it would not be high on the list of things I would worry about too much.

A processor and peripheral support library is not really a GNAT specific
problem (although it is required for GNAT); you have most of the same issues
when you need to provide this support in C, whether you are writing all the
headers/code/linker scripts yourself or are porting something like Newlib.

I've been through all this myself in C. Apart from what's needed to write
a RTEMS BSP, when it came to running bare metal code in C on ARMs, I also
wrote everything (startup code, headers, linker scripts, interrupt support
code, I/O library, etc) myself.

In other words, you don't really need a large amount of GNAT specific
knowledge to implement much of the processor and peripheral library
support, although you do need to know how you are going to implement, say,
interrupts and what GNAT and RTS specific support you might need for that.

Interrupts are a good example of how a porting document can only provide
limited guidance in some areas. In your MSP430 example, you appear to
associate the interrupt vector with the routine at link time (I don't
know the MSP430; I am just going by your example), yet on a 32-bit
traditional ARM (ie: ARM7TDMI/ARM9) running bare metal code, I load the
interrupt handler's address into a interrupt dispatch table at runtime
and I need to supply interrupt support code to handle the interrupt.

BTW, the complexity of that support code is also directly impacted by
if you want to do things like priority nesting (my ARM bare metal interrupt
support code does this).

> And having spent 9 hours yesterday building AVR-Ada 1.2.1 from its "one 
> click" script I know that getting toolchains into that stage is not 
> trivial. 
>

:-)

Oh, I _so_ agree. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world