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.86.34 with SMTP id m2mr1242636wiz.5.1364344139312; Tue, 26 Mar 2013 17:28:59 -0700 (PDT) MIME-Version: 1.0 Path: p18ni19756wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.86.MISMATCH!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsgate.cuhk.edu.hk!goblin1!goblin.stu.neva.ru!eternal-september.org!feeder.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: Wed, 20 Mar 2013 00:54:38 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> Injection-Date: Wed, 20 Mar 2013 00:54:38 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="3a7522c45acd2a6c162b080668fa4020"; logging-data="32129"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/N2f+KsVW+PuLOkO8V2KEHKa9T/fVUPp4=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:dPAEEIIxbtVq/dkYrJp+A+c8yBU= Date: 2013-03-20T00:54:38+00:00 List-Id: On 2013-03-19, Brian Drummond wrote: > On Tue, 19 Mar 2013 12:51:12 +0000, Simon Clubley wrote: >> I would like to offer one take on this which has not been mentioned yet >> and that is the issue of reliability of the resulting system as a whole. >> >> 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 ? > > There's a germ of truth in this in that many more man-hours have already > been spent polishing up C library functions and (in some environments) RTS > - re-using that where it exists can save time and avoid traps. > > 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've written several BSPs for RTEMS and got Ada code running just fine on those same BSPs, so I clearly have similar types of skills to those which I would also consider necessary to port a compiler toolchain. What I don't have is the knowledge to modify GNAT. With RTEMS, all the documentation which you need to bring it up on a new platform is freely available. You need the skills to understand what the documentation is telling you, but the documentation itself, along with a clean RTEMS source code base, is sufficiently complete for anyone sufficiently skilled to write a BSP and to even bring up RTEMS on a totally new architecture if needed. 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. You also have no confidence that the model you have built is sufficiently complete to result in a robust port. > 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. 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. One of the bare metal environments I am interested in are the very low end ARMs, so I have checked in on Luke's work from time to time and I have noticed the problems he has had getting things working even with his modest goals and how things can break so easily between compiler versions. 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. 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. I came to this prepared to spend effort getting GNAT to run in a new bare metal environment, but in the end I walked away because the project was too big and I didn't have any confidence that the end result would be robust. C may not be a great choice (and I already know this BTW, as I would not otherwise have been looking at porting GNAT), but at least it works on all the environments out there. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world