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: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!buffer1.nntp.dca1.giganews.com!border1.nntp.dca3.giganews.com!backlog3.nntp.dca3.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!reality.xs3.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada platforms and pricing, was: Re: a new language, designed for safety ! Date: Sun, 22 Jun 2014 18:38:50 -0500 Organization: Jacob Sparre Andersen Research & Innovation 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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: loke.gir.dk 1403480330 12995 69.95.181.76 (22 Jun 2014 23:38:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Sun, 22 Jun 2014 23:38:50 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Original-Bytes: 6679 Xref: number.nntp.dca.giganews.com comp.lang.ada:187178 Date: 2014-06-22T18:38:50-05:00 List-Id: "Simon Clubley" wrote in message news:lo7c2h$ura$1@dont-email.me... > 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. >>>> ... >>> 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. That's not my experience. Remember that "basic Ada support" includes things like timers (Ada.Real_Time, delay statements), some method of handling exceptions (which generally means supporting hardware traps), and usually tasking (which means some method of context switching). All of these require interrupt support on bare boards, and that never seems to be quite the same from board to board. There's certainly a shared part, but the configurations are different for each board. And you have to be pretty familar with the boards in order to do those; your average tinkerer isn't likely to be able to do that. > 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. Fair enough. I found back in the day that you had to be able to connect that with Text_IO for useful output (for instance, the crash messages from the Janus/Ada runtime). But that's clearly a secondary need. I wasn't thinking about full I/O support, for instance, since it usually doesn't make sense in that environment. >>> 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. Sure, but it's compiled; you don't need a C compiler in order to be able to use GNAT. If you require people to use C code in their setup, they'll need to get the C compiler working first. At that point, most people will wonder why they're spending time to get Ada working rather than working on their project (the fun part, hopefully). ... > 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'm not talking about "peripherals"; I'm talking about timers and trap handlers (for overflow, divide-by-zero, etc.) and the like. These things are required for a useful subset of Ada. (No clock and no exceptions means you're no longer really doing Ada, just Ada syntax.) I/O is optional, but not these other things. Randy.