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.189.209 with SMTP id gk17mr1245544wic.7.1364344208592; Tue, 26 Mar 2013 17:30:08 -0700 (PDT) MIME-Version: 1.0 Path: p18ni19764wiv.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!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!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!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 13:18:57 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> Injection-Date: Wed, 20 Mar 2013 13:18:57 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="3a7522c45acd2a6c162b080668fa4020"; logging-data="4902"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18fhuxmOGSzfXirW9X5dDgo+CpzOGAIOE8=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:lfgCL086MXghv+HhovwGzMZ/q8c= Date: 2013-03-20T13:18:57+00:00 List-Id: On 2013-03-20, Brian Drummond wrote: > On Wed, 20 Mar 2013 00:54:38 +0000, Simon Clubley wrote: >> 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 are welcome. >> 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? > 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. > 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. > Oh, I _so_ agree. :-) I'm not yet building my own satellites :-), but even when you want to start putting your code in things which fly through the air any responsible person is looking for a higher standard of reliability than for something which flashes pretty lights on a workbench. >>> 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. > A example of a bare metal environment would be AVR libc or AVR-Ada been used in code running directly on a AVR (ie: without a OS underneath). A example of something which is _NOT_ a bare metal environment in my eyes would be running something on top of RTEMS or on top of another RTOS kernel. IOW, running code under a OS is not bare metal, but running code directly on the target device, in place of where the OS would otherwise be, is bare metal. >> 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. > It's nice that these various efforts are going on and I thank the people who are doing them. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world