ARM support

[der-imp]

I currently try to compile infoware on aarch64. But on all tried distribution the is missing. (debain for arm, raspberry OS) In this source the header is referenced. Is there a possibility to add support for aarch64?

[ThePhD]

I think at that point we'd have to drop down strictly to some assembly to query this information...

[nabijaczleweli]

Sure, you'll need to:

• ifdef away most of cpuid[_non]_windows.cpp on __x86_64/__x86_64__/__i386/__i386__ – possibly supplying a different set of functions relevant to ARM
• same for iware::cpu::vendor_id() in vendor_id.cpp and iware::cpu::supported_instruction_sets() in instruction_set.cpp and provide a new implementation
• rename iware::cpu::architecture_t::arm{=>64} and return that instead of ::arm in architecture_windows.cpp, then add a different ::arm
• NEON/&c. detection would be a bonus

[ThePhD]

ARM manual says we need to poke at some funny registers to get some of this information:

I guess at some point poking directly into Registers was going to have to be necessary. Some inline assembly can probably work, unless we're on MSVC, in which case they've banned inline assembly. But I can't imagine VC++ works on anything outside of a Windows-like environment.

[eleszet]

Hello together,

I came across the same problem when I build on my Raspberry. Are there plans to fix this any soon?

Didn't find a suitable solution myself yet.

BR

[nabijaczleweli]

The suitable solution is but two posts up: https://github.com/ThePhD/infoware/issues/49#issuecomment-850851005. You have relevant hardware: write a port; IIRC there's nothing Very Surprising that will bite you in the arse in this. Or give me (access to) an aarch64 computer. I hear Ampere has a good offering. Or a fiver for a cable to unfuck a Pi 0W I have (disclaimers apply: it's a 0W, so BCM2835, so armhf). Ports to any hardware, exotic or otherwise, don't happen because you want them to, but because you spend an hour or three with said hardware. There are no "plans" to "fix" anything: there's nothing to fix, save mayhap for your RHEL licensee attitude.

[eleszet]

Thanks for your reply. You are right, I am not deep in this topic. I just wanted to check if there are any plans to fix this - if not I will dig into it and find a way to solve it for my particular situation.

[tkchia]

Hello @ThePhD, hello @nabijaczleweli,

I am not sure the proposed solution will work — as far as I know, the MIDR_EL1 register and all the other ..._EL1 registers are only accessible from Exception Level 1 (EL1) or above, which means they cannot be read from userland code. I guess this is quite unlike the cpuid instruction on the x86.

Thank you!