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,FREEMAIL_FROM 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.224.185.201 with SMTP id cp9mr3563015qab.6.1363789067317; Wed, 20 Mar 2013 07:17:47 -0700 (PDT) X-Received: by 10.49.82.134 with SMTP id i6mr110579qey.20.1363789067265; Wed, 20 Mar 2013 07:17:47 -0700 (PDT) Path: k8ni4137qas.0!nntp.google.com!dd2no3704545qab.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 20 Mar 2013 07:17:47 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=5.69.185.0; posting-account=L2-UcQkAAAAfd_BqbeNHs3XeM0jTXloS NNTP-Posting-Host: 5.69.185.0 References: <21ad4ef7-0e4a-40ba-ac3f-fe21018c7bd9@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <42842167-2492-4211-8c57-3d94b042902e@googlegroups.com> Subject: Re: Runtime startup code for the GNAT Runtime...and a bit of humble pie. From: Lucretia Injection-Date: Wed, 20 Mar 2013 14:17:47 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-03-20T07:17:47-07:00 List-Id: On Wednesday, 20 March 2013 00:54:38 UTC, 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. I agree. > 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. I never did get far with RTEMS, tbh. > 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. Good documentation really is the key here. > 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. It can also fail in other places too, most notably the testsuite, plus there is no testsuite for bare metal, you'd have to know which tests to apply to your stripped down compiler. > 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. Right. There is the Javier Miranda *thesis* - that word is important. Basically, this thesis outlines how the GNAT RTS works, but it's out of date and it's not a "how to" style guide, it's a "how it was" guide. The fact that it's a thesis as well means it's aimed at academia, not real life. Another point to make is that AdaCore hired him and there is no update to the doc. > 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 Only if there is an OS, it's usually a C based OS and therefore requires the C startup before the Ada startup, hence the various crt*.o files that get linked in along with the GNAT binder output. > 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. Yup. > 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. Aw fanks! :D Yeah, getting GNAT going on bare metal is a bitch and I followed another thesis as a guide to do it - Spanish, I think. But I realised that the #ifdef ARM's I put into the C code in the RTS can be replaced with #ifdef _STDC_HOSTED_ and should work for any elf- target. > 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. Yup, absolutely, especially with the rise in embedded work that's happening and Ada isn't getting the promotion it deserves in that area. > 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. I do wonder that if I did manage to get my kernel written with GNAT using bare metal that I've been working on (on and off) for a while now, would it be correct? I would say, possibly, but can we guarantee it? Probably not. > 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. Yes, it's not got anything to go wrong really, the only runtime is the startup code to clear bss and jump to main and the bits of the C lib you need, that's it. A lot less than Ada. A conclusion re GNAT that I've come to is that AdaCore don't really want people dicking about with their compiler: 1) the compiler wasn't really designed for building as a cross compiler the way I've been trying to get it to, and 2) any "help" you get from them consists usually of 1 or 2 cryptic lines which don't really help at all anyway. Luke.