Unable to compile for ARM

[datasynergyuk]

The recent introduction of "Intel Intrinsics" into the codebase is great and a huge speed improvement. However, it prevents the code from being compiled for the Windows/ARM platform. Please can I suggest that the original (slow) code is left in place or alternative ARM implementation provided so that it can still be conditionally compiled for the ARM platform. This is increasingly popular in Windows space (14% and growing) and it would be a shame to prevent HexCtrl natively running on that platform:

https://www.counterpointresearch.com/insights/arm-based-pcs-to-nearly-double-market-share-by-2027/

For example:

https://www.codeproject.com/Articles/5301747/Porting-Intel-Intrinsics-to-Arm-Neon-Intrinsics

[jovibor]

Frankly saying I did never consider compiling MFC code for ARM, it sounds a bit weird, like... two different epochs. HexCtrl was never meant to be ARM compliant, neither was it ever stated. Although I don't see anything wrong with it. Usually the X64->ARM transition is done through seamless platform emulation, it's the case for both MacOS and Windows.

Supporting ARM/NEON natively at this moment is out of question for few reasons: The 14% of the market is not a considerable amount I believe, to spend a time and other resources for. Also, I don't have an ARM CPU nor I have a capacity for such a work atm. If someone is willing to take up this cup, I only welcome.

Personally I believe the best approach in such situations is to just compile for native X64 binary and run through the platform emulator. Of course things might change in the future, if ARM becomes really popular and widespread.

BTW, for Arm64EC platform toolset HexCtrl compiles without any errors.

[datasynergyuk]

I agree it sounds weird. MFC and ARM are from different times. However, ARM is growing and projected to be 27% of Windows market in 3 years time. Historically, HexCtrl would compile and run fine on native ARM. The recent change breaks with that and makes it Intel-only. I think this is a backwards step. It is logical to develop the non-platform dependent version first. This is what has happened in the past. My suggest is simply that this continues and that platform independent code remains available for the future use. This approach also means that the the performance gain from a more specialist approach can be easily measured. This doesn't mean the code needs to be tested on ARM, if it is generic C++ code and it compiles, it should run fine.

Thank you once again for a great control. The recent performance improvements are fantastic (if you have a supported processor).