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=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,cc3c5a58c46ea9c4 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.24.132 with SMTP id u4mr1241413wif.6.1364344270170; Tue, 26 Mar 2013 17:31:10 -0700 (PDT) Path: p18ni19766wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!193.141.40.65.MISMATCH!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!border2.nntp.ams2.giganews.com!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!newsgate.cuhk.edu.hk!goblin2!goblin.stu.neva.ru!aioe.org!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie. Date: Wed, 20 Mar 2013 11:50:57 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> Mime-Version: 1.0 Injection-Date: Wed, 20 Mar 2013 11:50:57 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="da745e888d4a5182b5fda6212bbb0a63"; logging-data="11358"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18WS/d8E6cvBs+TyQo0BudfbGcdyX0KLNU=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:t6W7AVVastVucIacsOvzcrDbpxg= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2013-03-20T11:50:57+00:00 List-Id: On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote: > On 2013-03-19, Brian Drummond wrote: >> On Tue, 19 Mar 2013 12:51:12 +0000, Simon Clubley wrote: >>> One of the reasons to use Ada over, say C, is for the increased >>> reliability of the code. However, what if the ported Ada RTS actually >>> results in more unreliable code because of issues the person porting >>> the RTS did not fully understand or was simply was not aware of ? ... >> But I don't think you're arguing that - if you had to write some bare >> metal stuff of your own - C would be a better language for the job. On >> the contrary, where you have to start from scratch, Ada gives you much >> better tools. > Ada gives you better tools when those tools already support the target > environment. > > 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. I'd like to thank you for an excellent summary of a lot of issues. > You can quickly build a high degree of confidence with a new RTEMS BSP > that once it appears to be working, it _really_ is working. > > This does not appear to be the case with GNAT. > > All the information you need to bring up GNAT on a new platform (when > it's written down at all) appears to be scattered in various bits of > source code, newsgroup/mailing list postings and various other direct or > indirect hints in various sources. It's a major exercise to even pull > together all the information you need to build a model of how GNAT works > and how it is structured internally. This is definitely true. > 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? It is also worth bearing in mind that the confidence level required for an experimenter wanting to escape Arduino, and a university CubeSat or medical appliance are different. >> So C comes into play NOT for bare metal programming, but to avoid it >> where you can re-use someone else's effort. Right? > No. In my case it really is for new bare metal programming of my own. > > The bit you are missing is that the C environment already exists on the > target environment, but even a minimal Ada does not. There's a BIT of a mismatch here : if there is a C (or Ada) environment for a platform, it isn't really bare metal programming; unless I misunderstand what you mean by the environment. > Given my favourable > feelings towards Ada, I actually would not mind modifying GNAT to > support a new platform if it was a reasonably sized project and if I > believed the final results would be robust. I would consider it to be a > fun project. This is what I am attempting for the MSP430. So far it really *is* bare metal. It's just a compiler, with essentially no modifications. Minimal RTS "stolen" from AVR-Ada with minimal porting ( the same MSP430 "builtin" functions as its C equivalent), and Ada packages listing every port, register and bit for every CPU variant, auto-generated from the equivalent C headers. As such, it (along with AVR-Ada and the Polish ARM port) doesn't yet support tasking, or protected objects. Which means for example that interrupt handlers are implemented via "pragma Machine_Attribute" rather than as protected objects. Ditto exceptions as Luke found. So far it's been plain sailing but this isn't "real Ada" yet, and the next step looks more difficult. > Luke's work is a good source of information, but GNAT really needs a > porting guide along the lines of the various RTEMS porting manuals. Absolutely. I have documented the steps I followed and it's a bit gory. It's not helped (IMO) by the fact that all the (FSF Gnat) sources for compiler and RTS are lumped together; even separating GNARL and GNULL into their own directories with their own build process and documentation would help. Fortunately a couple of the disconnected efforts out there (such as ORK) have separate target RTS sources, which will help. > Or to put this another way, if you want new people to start using Ada in > their bare metal embedded environments (which as Randy points out in > another response is a area where Ada shines), then it has got to be > easier to get GNAT running on those environments. Agreed. But it won't be unless a few of us wade through the current mess - or some massive funding magically appears to make it happen. I'm not waiting for the latter! - Brian