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.106.161 with SMTP id gv1mr1248638wib.4.1364344105363; Tue, 26 Mar 2013 17:28:25 -0700 (PDT) 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!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: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie. Date: Tue, 19 Mar 2013 23:13:13 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> Mime-Version: 1.0 Injection-Date: Tue, 19 Mar 2013 23:13:13 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="da745e888d4a5182b5fda6212bbb0a63"; logging-data="24057"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18bLgFtp+EZv2ayOUR7GkqyXHcLFygeId4=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:k782ye3K7Thday8lEKbCVnZMk50= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2013-03-19T23:13:13+00:00 List-Id: On Tue, 19 Mar 2013 12:51:12 +0000, Simon Clubley wrote: > On 2013-03-19, Brian Drummond wrote: >> >> There was an email just today on gcc-help@gnu.org with part of the >> picture - in the thread entitled "Controlling ld and as with backend" >> on how to configure the start.s and end.s subroutines, using the >> "config/t- >>" files. >> >> My own view is that for a minimal Ada RTS, they should do as little as >> possible unlike the crt.o stuff and that the standard packages' >> initialisation parts should add whatever is necessary for their >> inclusion. >> >> But this is only a view; I am just beginning down this path (with the >> TI MSP430 processor, see msp430ada on sourceforge) where the C startup >> does a lot with e.g. the watchdog timer that is unnecessary if the Ada >> application decides to turn it off... >> >> So I am interested in other views and good documents, should you find >> any! >> >> > 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. So C comes into play NOT for bare metal programming, but to avoid it where you can re-use someone else's effort. Right? - Brian