Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Xictools doesn't compile on M1 #11

Open
appwagner opened this issue Dec 31, 2021 · 10 comments
Open

Xictools doesn't compile on M1 #11

appwagner opened this issue Dec 31, 2021 · 10 comments

Comments

@appwagner
Copy link

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
Copy link
Author

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
Copy link
Owner

wrcad commented Jan 1, 2022 via email

@appwagner
Copy link
Author

appwagner commented Jan 2, 2022 •
edited

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
Copy link
Owner

wrcad commented Jan 2, 2022 via email

@appwagner
Copy link
Author

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
Copy link
Owner

wrcad commented Jan 4, 2022 via email

@appwagner
Copy link
Author

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
Copy link
Owner

wrcad commented Jan 8, 2022 via email

@appwagner
Copy link
Author

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
Copy link
Owner

wrcad commented Jan 8, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@appwagner @wrcad