From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on ip-172-31-65-14.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 Path: eternal-september.org!reader01.eternal-september.org!aioe.org!lYnhq7byp2KtY/MFJZaCTw.user.46.165.242.91.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: components_4_64 python Test_Class Build Fails Date: Fri, 21 Oct 2022 22:14:17 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <2038635c-fdb0-4ca4-9dd8-6d7f9cfa6dd1n@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: gioia.aioe.org; logging-data="38218"; posting-host="lYnhq7byp2KtY/MFJZaCTw.user.gioia.aioe.org"; mail-complaints-to="abuse@aioe.org"; User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.1 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:64539 List-Id: On 2022-10-21 21:56, Simon Wright wrote: > "Dmitry A. Kazakov" writes: > >> BTW, what are you "posh guys" (:-)) are going to do with M1/2? Is >> there GNAT? >> >> Is there any noticeable differences to X86_64 on the Ada level? >> Endianness must be same, correct? Alignment/padding inside C >> structures when interfacing to Ada? > > The Macs with Apple silicon (I don't think there's a difference between > M1 & M2 at our level) support, for an unknown number of future OS > iterations, a feature called Rosetta (2) which effectively does > just-in-time translation of x86_64 binaries to aarch64. This is the same > scheme they had for the Power -> Intel transition. I see, the DEC Alpha's idea. Nice. > x86_64 GCCs run just fine on Apple silicon, generating x86_64 binaries; > I just ran the Alire gnatprove on my M1 mac mini and it failed in the > same way as on x86_64 (libgmp not where it was expected). > > We have a native aarch64 compiler that generates aarch64 binaries, no > noticable difference* (maybe if you got out a stopwatch ...). The only > trouble is that aarch64 binaries can't use x86_64 shared libraries; the > assembler, linker and libraries that Apple provides are > dual-architecture, and some external providers provide the same or offer > the choice at download time. OK, this is same as under Windows. You cannot link against 32-bit DLLs, you can load them as data only. > * a couple of ACATS tests designed to check Storage_Error failed on M1 - > I don't remember how. Well, the stack frames must be different on aarch64 and X86_64. I never used aarch64, only armhf. The later is quite a mess. Nothing concrete, just a feeling that the thing promptly crumples under stress load and generates Storage_Error just for the sake of saying something on system trap. Stack backtrace is a permanent fight etc. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de