watchOS architecture arm64_32 is not modeled in settings.yml

[theodelrieu]

Hello,

Apparently the only archs supported by watchOS are armv7k, and arm64_32.
I looked at the correct libSystem.tbd file, which has this section:

archs: [ armv7k, arm64_32 ]

armv7k is already present in settings.yml, I wonder what should be done for arm64_32 though.

Should we keep armv8? And only fix the Apple Tools to_apple_arch function for watchOS hosts?

I'm using Conan 1.9.1 on macOS 10.14 (Mojave)

To help us debug your issue please explain:

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[theodelrieu]

I forgot to mention there are x86, and x86_64 for the WatchSimulator platform.

[theodelrieu]

Looking at the current settings.yml, I was wondering if the arch setting could be restrained on platforms where it makes sense?

Just like the subsetting os.version, or compiler.libcxx. It would be helpful for Darwin platforms, right now I have to check in my darwin-toolchain recipe that the architecture is valid.

[danimtb]

Hi @theodelrieu,

Having a look at the arm64_32 arch denomination I fail to find a comparison on why it was name like that instead of just armv8. Are both denomination supposed to be compatible?

Anyway, I think in the end the denomination arm64_32 would be less confusing and although it would only make sense for watchOS I think it makes sense as we are not restricting the compatibility between OS <-> arch

However, I understand the issue with the current settings.yml but that would tie the architecture to the OS. Do you have any proposal to improve this?

[theodelrieu]

Are both denomination supposed to be compatible?

I'm not quite sure, from what I've read it allows 32bit code to run on a 64 bit device, a bit like Windows does.

Do you have any proposal to improve this?

Not really, it would be a quite huge change and I did not think very much about it to be honest.
It might be "good enough" to let specific recipes handle that, since new architectures would need the Conan team to update the settings.yml everytime, which quickly becomes a pain.

[danimtb]

I agree with you about settings.yml.

Please provide me with more information about the naming of arm64_32 so we can consider it and update the tools affected (will probably require your help too)

[theodelrieu]

Looking at the ARM website, it seems that armv8 supports both 32/64 bit instruction sets.

Here is a Mono issue talking about this subject in detail.

In the future, Apple might add an arm64 arch to watchOS, so I would still suggest modeling this new arch to avoid breakage in a few years. I'd go with armv8_32 for Conan. What do you think?

[danimtb]

Is this really a "new" architecture or is this a kind of flag that generates some bytecode to make this compatible with other architecture?

I would like to read more about this. Is there any official documentation about this?

[theodelrieu]

I haven't found one yet, so I will not make assumptions :p

[SSE4]

this answers better: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html
therefore, armv8 is processor architecture, and AArch64 and AArch32 (aka ILP32, aka armv8_32) are instruction sets for this processor architecture.
in conan, we currently have armv8 architecture, which actually represents builds for AArch64 instruction set. it's also named just as arm64 in Apple tools.
and we have to add armv8_32 for AArch32 / ILP32, as we currently don't model it.