Xictools doesn't compile on M1

[appwagner]

After getting a nice new M1 mac this Christmas it was time to install my favorite pieces of software which includes the Xictools circuit simulator toolkit. I'm installing on a Mac so the first step was to install the gtk bundle from macports. This step worked fine out of the box, /usr/local/gtk2-bundle-X11/bin is filled with POSIX scritpt executables and arm64 binaries that all seem to work, hurray! Now for the issues, when you run make all in the xictools project the following things happen,

1. Weird shell script #! issue: The build is configured you see a lot of: ../../../vl/version:1:2: error: invalid preprocessing directive
   #! /bin/sh
   ^
   errors followed by numerous cascading errors. Somehow gcc is seeing a shell script command and attempting to parse it. Not sure how this crept up or in which file(s) its occurring.

2. To arm or not to arm: The arch for darwin is hard coded as x86_64 in the config.in which is no longer a good assumption. In fact unless you changed your system arch to x86_64 when you made the gtk bundle you will be linking x86_64 against arm64 which won't work. I had to manually set the arch to arm64 to clear this set of errors. The config.in file should be updated to ask a Darwin user if they want to compile for x86 or arm.

3. Related to 2, code that relies on intel SSE intrinsics won't work: In FastHenry we get a lot of /Library/Developer/CommandLineTools/usr/lib/clang/13.0.0/include/mmintrin.h:50:12: error: invalid conversion between vector type '__m64' (vector of 1 'long long' value) and integer type 'int' of different size
   return (__m64)__builtin_ia32_vec_init_v2si(__i, 0);
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   errors. Since FastHenry is a standalone program (which I don't need actually) it could be compiled as x86_64 and then run via Rosetta. Not sure how baked in the SSE intrinsics are to FastHenry and if they can switched over to a metal implementation for mac.

[appwagner]

Still working on the weird preprocessing error, I'm not sure what apple changed to cause this. On the bright side there is an easy fix to 3. The SSE intrinsics can be converted transparently to neon instrinsics which are supported on by apple on arm, https://discussions.apple.com/thread/252073619 . The implementation looks like:

#ifdef x86_64
#include <immintrin.h>
#else
#include "sse2neon.h"
#endif

[wrcad]

Hi Andrew, I purchased a new MacBook Air so will be able to develop and maintain support for M1. It may take a while to get it all cleaned up, any tips or help you (or other users) can provide would be most welcome. Regards, Steve

…

On Dec 30, 2021, at 7:55 PM, Andrew Wagner ***@***.***> wrote: Still working on the weird preprocessing error, I'm not sure what apple changed to cause this. On the bright side there is an easy fix to 3. The SSE intrinsics can be converted transparently to neon instrinsics which are supported on by apple on arm, https://discussions.apple.com/thread/252073619 <https://discussions.apple.com/thread/252073619> . The implementation looks like: #ifdef x86_64 #include <immintrin.h> #else #include "sse2neon.h" #endif — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEZ4PVGNXBAFLRLUS6DCZ7LUTUSUBANCNFSM5LAR6S7Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.

[appwagner]

Thanks Steve. I've done some digging and to deal with the issue of porting SSE instructions https://github.com/DLTcollab/sse2neon is a great resource. Unfortunately the current version doesn't support _m256 type (AVX) registers, and this is since Neon (and M1) only supports 128 bit registers. Theres something called SVE that arm is rolling out as a Neon upgrade but apple silicon doesn't support that (at least I don't think so). The simd_mac code that causes trouble will need to have a "down graded" _m128d or Neon equivalent implementation. Its a pretty simple function so it might just be better to use suitable flag to compile either the AVX version you already have or a Neon version. I'm still working on the preprocessing error, if you try to build WRSpice on your M1 air you'll see what I mean.

[wrcad]

Andrew, the “preprocessing error” is that deep in the include tree for c++ support there is “#include <version>” that should load a file named “version” in the system include files. Unfortunately, it instead loads the “version” file at the top of the tools code, which is s shell script that simply prints out the release number. I changed the name of all of these files to “release.sh” to get around this. Regards, Steve

…

On Jan 1, 2022, at 4:09 PM, Andrew Wagner ***@***.***> wrote: Thanks Steve. I've done some digging and to deal with the issue of porting SSE instructions https://github.com/DLTcollab/sse2neon <https://github.com/DLTcollab/sse2neon> is a great resource. Unfortunately the current version doesn't support _m256 type (AVX) registers but that doesn't seem to be an inherent limitation in neon. We could fork their project and add the support we need following their templates. Alternatively we could re-write a version of the SSE code with Neon and have flags handle which version of the code gets compiled. A project like sse2neon eliminates the need to re-write the implementation. I'm still working on the preprocessing error, if you try to build WRSpice on your M1 air you'll see what I mean. — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEZ4PVCP2WJH7YIRGUHB3Q3UT6JVDANCNFSM5LAR6S7Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.

[appwagner]

Thanks Steve, I found the system file in XCode but couldn't for the life of me figure out where the shell script error was. Maybe change release.sh to wr_release.sh or something that apple (or anyone else) would never use a as name. Just a thought since apple likes to change stuff like system include names/conventions from time to time.

[wrcad]

Andrew, I’m able to build all of the tools on M1/Monterey, but beware of subtle things that may need fixing. I had to add some things to the gtk2-bundle-x11, So you will need to add them to yours. See the present xt_base/packages/util/MPbuild file and sudo port install the ones that you don’t already have. I turned off AVX in FastHenry when not using x86_64, I’ll port this to arm64 later. Regards, Steve

…

On Jan 2, 2022, at 2:19 PM, Andrew Wagner ***@***.***> wrote: Thanks Steve, I found the system file in XCode but couldn't for the life of me figure out where the shell script error was. Maybe change release.sh to wr_release.sh or something that apple (or anyone else) would never use a as name. Just a thought since apple likes to change stuff like system include names/conventions from time to time. — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEZ4PVEHEH3AIJSEV2VXLSLUUDFPLANCNFSM5LAR6S7Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.

[appwagner]

Thanks Steve,

Can you push your changes as a commit to github or email me a copy of the MPbuild, Makefile template and other changes needed to build if its too experimental?

[wrcad]

Andrew, The repo (level branch) on GitHub should be up to date. The MPbuild file resides in xictools/xt_base/packages/util/MPbuild. Regards, Steve

…

On Jan 5, 2022, at 6:38 PM, Andrew Wagner ***@***.***> wrote: Thanks Steve, Can you push your changes as a commit to github or email me a copy of the MPbuild, Makefile template and other changes needed to build if its too experimental? — Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEZ4PVAOKLODJGZA5ROTX2LUUT6DJANCNFSM5LAR6S7Q>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.

[appwagner]

Thanks Steve,

I found it. The branch name is devel, so for other M1 users out there they need to "git checkout devel" to get the M1 compatible branch. I compiled it (with the additional sudo ports) and installed the packages without error, and xic seems to run. I would say we can tentatively close this issue.

[wrcad]

Yes, the latest code is always in devel. I merge devel into master when there is a new xic or wrspice package released. This has been infrequent recently, due to my day job. Regards, Steve

…

Sent from my iPhone

On Jan 8, 2022, at 2:30 PM, Andrew Wagner ***@***.***> wrote:  Thanks Steve, I found it. The branch name is devel, so for other M1 users out there they need to "git checkout devel" to get the M1 compatible branch. I compiled it (with the additional sudo ports) and installed the packages without error, and xic seems to run. I would say we can tentatively close this issue. — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.