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!paganini.bofh.team!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: Thu, 27 Jun 2019 12:48:47 -0500 Organization: JSA Research & Innovation Message-ID: References: <228117e3-4382-4faf-807e-e562c41657c4@googlegroups.com> <8b10bd11-cc45-4842-8746-6b061bf1619d@googlegroups.com> Injection-Date: Thu, 27 Jun 2019 17:48:48 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="14803"; 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; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: reader01.eternal-september.org comp.lang.ada:56782 Date: 2019-06-27T12:48:47-05:00 List-Id: "Optikos" wrote in message news:8b10bd11-cc45-4842-8746-6b061bf1619d@googlegroups.com... On Wednesday, June 26, 2019 at 5:36:29 PM UTC-5, Randy Brukardt wrote: > "Optikos" wrote in message > news:228117e3-4382-4faf-807e-e562c41657c4@googlegroups.com... > ... >> >Randy, would putting Janus/Ada's front end on >> >0) LLVM backend >>> >be more difficult than any major target feature listed above alone >>> >(e.g.: >> >1) Janus/Ada as-is without LLVM plus ELF on x86; >> >> These are almost completely orthogonal: the existing code generator would >> work for Linux, and the (old) Unix JLink did ELF. The issue with Linux >> is >> updating the runtime to use Linux system calls (these are different than >> the >> ones from the old Unix). > >I can sympathize to some degree. But on the other hand, Janus/Ada's old >UNIX runtime would likely have been from the Spec 1170 era. Putting an >end to the Unix wars, Spec 1170 evolved into the Single Unix Specification >(SUS). The Linux Standard Base (LSB) pays immense homage to >SUSv3:POSIX2001 (but not SUSv4:2008through2018 yet) without being >perfectly compliant with SUSv3 in a minority of areas. The old Unix compilers didn't use any C interface to make system calls, they actually reproduced the binary calls (a call to a particular trap address with a numeric code in a register - Linux does not use this same scheme). If one was going to follow a scheme more like the one used for Windows with a Linux compiler, all of that would have to be replaced. (And the 15+ years of changes to the runtime would have to be created.) I don't think the actual routines called would be that different. >> OTOH, attaching LLVM is a totally different level of work, and I don't >> know >> enough about LLVM to say how easy or hard it would be. OTOH, we did >> something similar of Unisys, so we already have most of the ability >> available. > >Prior precedent is great news! The 4th cycle of learning (i.e., for LLVM's >ways) is >usually easier than the >1st (i.e., from scratch: Z80 for CP/M) and >2nd (i.e., relatively easy port of 8085 concepts on the Z80 to 8086 >concepts) and >3rd (i.e., major stressor on the design to withstand an entirely different >backend than >the 2 prior RR-Software backends). For the record, the Unisys one was the 7th different backend for Janus/Ada: 1st & 2nd (Z80 for CP/M, 8086 for MS-DOS) directly generated with no intermediate code (and only peephole optimizations); 3rd (8086 for MS-DOS) using an intermediate code and full optimizer; 4th (80386 [32-bit] for MS-DOS with extender and later Windows), based on the 3rd but different in some ways and adding concepts from the 5th; 5th (68020 for SunOS), built for a specific customer and never released (or quite finished); 6th (SPARK), also built for a specific cutomer and never really tested after funding disappeared; 7th (U2200 for Unisys) - 36-bit 1-complement numbers, using their back-end. Randy.