From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie. Date: Tue, 26 Mar 2013 22:38:15 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> Injection-Date: Tue, 26 Mar 2013 22:38:15 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="3a7522c45acd2a6c162b080668fa4020"; logging-data="20820"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Pi6kJUSzcByJ36COmPPKhVhtv7BLDdHk=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:cb6ibS58euabRJIOfQ2wFGlzqcU= Xref: news.eternal-september.org comp.lang.ada:14733 Date: 2013-03-26T22:38:15+00:00 List-Id: On 2013-03-26, Brian Drummond wrote: > On Wed, 20 Mar 2013 13:18:57 +0000, Simon Clubley wrote: > >> On 2013-03-20, Brian Drummond 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