Re: components_4_64 python Test_Class Build Fails

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2022-10-21 21:56, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> 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