From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Received: by 2002:aed:3fac:: with SMTP id s41mr32336699qth.86.1593719799207; Thu, 02 Jul 2020 12:56:39 -0700 (PDT) X-Received: by 2002:a05:6820:172:: with SMTP id k18mr20651700ood.69.1593719798940; Thu, 02 Jul 2020 12:56:38 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.uzoreto.com!tr1.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 2 Jul 2020 12:56:38 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.233.35; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.233.35 References: <4d9fa282-830d-42f7-a3bf-ba127cb2ad06o@googlegroups.com> <8332f305-299f-45d7-9f9d-2cad924b24d8o@googlegroups.com> <9d941aca-2eb6-4f35-a346-c290c4666bdfo@googlegroups.com> <76def2a5-667c-4009-b3b9-f0cf1c13a51bo@googlegroups.com> <3b5b2360-684c-4149-8662-98b53319cf94o@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6130b6aa-71b8-411c-8ff6-86ff255cf6aao@googlegroups.com> Subject: Re: Ada on Apple's new procesors From: Optikos Injection-Date: Thu, 02 Jul 2020 19:56:39 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader01.eternal-september.org comp.lang.ada:59317 List-Id: On Thursday, July 2, 2020 at 4:54:29 AM UTC-5, Simon Wright wrote: > Simon Wright writes: > > > "The LLVM code representation is designed to be used in three > > different forms: as an in-memory compiler IR, as an on-disk bitcode > > representation (suitable for fast loading by a Just-In-Time compiler), > > and as a human readable assembly language representation", which to me > > precisely matches "data in any format that is used as a compiler > > intermediate representation, or used for producing a compiler > > intermediate representation". > > On thinking about this further, can't help wondering whether this is > deliberate. By whom? For what purpose?