From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.8 required=3.0 tests=BAYES_00,PLING_QUERY autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Adapting an Ada compiler to generate 8051 code (Again?! ;-) Date: Thu, 1 Apr 2021 18:34:07 -0500 Organization: JSA Research & Innovation Message-ID: References: <41bc7a62-9c70-466d-b316-5fc74a3ee845n@googlegroups.com> Injection-Date: Thu, 1 Apr 2021 23:34:08 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="22575"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader02.eternal-september.org comp.lang.ada:61722 List-Id: "Niklas Holsti" wrote in message news:icm5tmF7ak3U1@mid.individual.net... > On 2021-04-01 2:14, Randy Brukardt wrote: >> "Niklas Holsti" wrote in message >> news:icgdhjF3j1eU1@mid.individual.net... >> ... >>> I have often wished that there would be Ada compilers for more >>> microcontrollers, but I understand why there aren't. An Ada-to-C >>> compiler >>> seems the most promising route. >> >> Send $$$. ;-) This was a project that was ideally suited for the >> Janus/Ada compiler suite, but we never were able to find a customer >> for it. The problem is always that the first customer has to pay a >> substantial part of the development; later customers don't have to >> pay that freight. (Back in the "waiver" days we considered doing it >> for the "fun" of making DoD-types have to find better excuses to >> avoid Ada than a compiler not existing for it, but the likely ROI >> wasn't there to convince the angel investors to go along with the >> idea.) > > Yes, things like that were among the reasons I had in mind for the lack of > such Ada compilers. Plus the fact that the pain of writing a small C > program is much less than the pain of writing a large C program. > > If you think that targeting Janus/Ada to small microcontrollers is > practical, I have two questions for you: > > Can you describe, in general, the Janus/Ada internal program > representation that, say, an 8051-back-end would get as input? It's called "JCode" (named long before Java existed, at least publically), and it is based on the ideas of p-code, tailored for what we needed for 8086 and similar processor output. There are other inputs (mostly in the form of a partial JRL, which carries the unit dependencies and the like), but most of those are related to the binder. Decent code generation for it is quite easy, since it is a rather low-level form. It's relatively easy to write a passable code generator and then incrementally improve it with pattern matching. One could probably build much fancier schemes on top of it; we thought about that periodically, but experiments showed that the differences wouldn't be worth the work. (Robert Dewar famously said that "most optimizations are disappointing", definitely a true fact from my experience.) > Would you be open to external/community participation in creating new back > ends for Janus/Ada, either under NDA or working from a public definition > of the internal representation, and either work-for-free or work for some > share of future sales? Yes, certainly. Contact me directly at the usual e-mail. Randy.