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!feeder.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: Janus/Ada 3.2.1 Released! Date: Mon, 15 Jul 2019 15:18:42 -0500 Organization: JSA Research & Innovation Message-ID: References: <228117e3-4382-4faf-807e-e562c41657c4@googlegroups.com> <8b10bd11-cc45-4842-8746-6b061bf1619d@googlegroups.com> Injection-Date: Mon, 15 Jul 2019 20:18:43 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="10888"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 X-RFC2646: Format=Flowed; Original Xref: reader01.eternal-september.org comp.lang.ada:56876 Date: 2019-07-15T15:18:42-05:00 List-Id: "Shark8" wrote in message news:db462b34-69f3-4641-9e6b-016e9f48bd54@googlegroups.com... > On Thursday, June 27, 2019 at 11:48:49 AM UTC-6, Randy Brukardt wrote: >> 5th (68020 for SunOS), built for a specific customer and never released >> (or >> quite finished); > Hm, interesting. > How much would be required to do a 68020 vxWorks [5.2]? > Or would bare-metal on the 68020 be easier? Hard to know. That project was abandoned around 1990, so it was Ada 83. I'd guess that the backend would not need a lot of changes (the basic design hasn't changed much). Probably the target-specific stuff wouldn't need a lot of changes, either (but there were a lot of options added for the U2200 project, and those would have to be redone). The Ada parts of the runtime would probably not need much updating, either. However, tasking was never finished for that compiler, and new tasking like protected objects would have to be created. Similarly, finalization and exception information are newer than that compiler. And target I/O would have to created (for whatever sort of target). There's enough unknowns that it would be hard to estimate. Of course, if there was actually a customer for it, one could spend some time poring over old code to see how much would need to be changed (not worth it for random cla chat). >> 6th (SPARK), also built for a specific cutomer and never really tested >> after >> funding disappeared; > How much would be required to bring this up to SPARK 2014? SPARC, the processor, not SPARK the whatever it is :-). Sorry about any confusion. > Also, regarding DSA, would it be possible to use Janus/Ada to split a > program across, say: > (1) a Motorola 68k (running vxWorks, or bare-metal), > (2) a Sun Ultra 45 (UltraSPARC IIIi, running SunOS), > (3) several x86-64 (Intel and/or AMd, running Windows) > Or is that beyond the capabilities of the tooling? (And if so, how much > would you estimate this DSA tooling to cost?) We never did any DSA tooling (or support). I tried to keep the design so that it would be possible if demand for it appeared, but it never did. The few cases where one needed that sort of support were easier to manage with cooperating programs using TCP/IP streams (rather than building lots of complex compiler support). I'm sure it's possible, but I don't have a clear idea of how much effort it would take. (Besides,anything always takes twice as much effort as expected, even something simple like balancing one's credit card amounts.) Randy.