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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Simon Clubley Newsgroups: comp.lang.ada Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! Date: Sun, 22 Jun 2014 19:50:42 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <1402308235.2520.153.camel@pascal.home.net> <85ioo9yukk.fsf@stephe-leake.org> <255b51cd-b23f-4413-805a-9fea3c70d8b2@googlegroups.com> <5ebe316d-cd84-40fb-a983-9f953f205fef@googlegroups.com> <2100734262424129975.133931laguest-archeia.com@nntp.aioe.org> Injection-Date: Sun, 22 Jun 2014 19:50:42 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="e458ff8b81bc0c159989eb0e36c6e372"; logging-data="31594"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19Mzoe8wdF5QGcRZx/b2N7yaATYtP+WL30=" User-Agent: slrn/0.9.8.1 (VMS/Multinet) Cancel-Lock: sha1:to6b5LQYBLYuoCNZmmVPn9tpij4= Xref: news.eternal-september.org comp.lang.ada:20524 Date: 2014-06-22T19:50:42+00:00 List-Id: On 2014-06-18, Randy Brukardt wrote: > "Simon Clubley" wrote in > message news:lnsqus$d4j$1@dont-email.me... >> On 2014-06-17, Randy Brukardt wrote: >>> >>> It's impractical to have any such cross-compilers. Every such compiler >>> (run-time, really) has to be tailored to the specific board in question. >>> We >>> treated each embedded compiler as something that would require extensive >>> support, and I still think we lost money on each. >>> >> >> You are thinking of this as a monolithic commercial product. Things are >> much more modular in the open source world. > > Not at all. Janus/Ada is structured almost as you describe below: > [Apologies for the delay in responding to your message; I forgot to respond to it.] I stand corrected. :-) >> Taking the ARM bare metal (C language) world as an example: >> >> 1) At the bottom layer you have the compiler itself. This just generates >> code for a set of ARM architecture variants such as Cortex-M3 and >> Cortex-A8 as well as older ARM architecture variants such as the ARMv5 >> variants. It has absolutely no knowledge of any specific MCU or any >> board which that MCU might be placed on. Things like memory layouts >> are handled in linker scripts. > > Yup. But no one can do anything useful with such a thing. It's trivial to > take a version of Janus/Ada and use it as a cross-compiler for some board. > But without a runtime, hardware support, and the like, only the most > dedicated people could use it for anything. > To me, I mentally split the problem into two categories: The support for Ada language functionality and the support for peripherals on the specific board. I regard only the first part as really a part of the actual compiler, but it is a required part. However, my feeling is that the Ada RTL support, once implemented, is pretty generic within a MCU architecture and is not really board specific. You may need some configuration and interface options for things like I/O operations, with calls to user supplied I/O packages. These packages would only concern themselves with the lowest level, interfacing to the hardware itself and not provide any generic Ada RTL support. In these user supplied packages, I'm thinking about things like an Ada version of, say, putchar() which would just output the passed character to some hardware device without concerning itself about anything other than that. >> 2) At the next layer up you have code to support a specific MCU. As >> well as MCU specific startup code, this includes things like interrupt >> handling which is MCU specific in the ARM world. This code generally >> comes from the manufacturer of the MCU and is usually free. > > But it's probably not in a form that could be used for Ada. Certainly not > unless you're planning to require having an C compiler around as well (not > really good marketing for Ada). > There is some C code at the very lowest level of GNAT. >> I don't know about Luke, but when I talk about Ada cross compilers, >> I'm only really thinking about the first part (the compiler itself) >> although you will probably need to add in Ada specific initialisation >> code into the MCU startup code. Provided the calls into the Ada RTL >> are cleanly documented then that's not a problem for me. > > You'd be very much in the minority. Remember, for the sorts of people you > are talking about, the compiler is going to have to work pretty much out of > the box, as the normal person isn't going to have the Ada knowledge needed > to write a runtime for a particular board. > I don't really see the support for the peripherals as part of the compiler as such. For example, the various MCU and board manufacturers may provide their own bare metal support package for a board and all you need to do is download it from their website and build it with your own C compiler; it's not expected to be a part of gcc. I wonder if a halfway house could be like the situation with RTEMS. RTEMS is written in C and so are the BSPs. However, you can run your Ada code on top of RTEMS. IOW, create a Ada binding to the manufacturer's code and just use Ada for your own code. While it would really be nice to have Ada code top to bottom, this is really no different than, say, Linux when you are running Ada code on a C base. I suppose it also depends on the type of hobbyist. There are some who are as you describe and just want the complete package. There are also people like me who just need a compiler with some core language functionality and can then get to work reading the datasheets if the code does not exist or is not suitable. Simon. -- Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP Microsoft: Bringing you 1980s technology to a 21st century world