Skip to content

ARM64 build: it would be good at least to be buildable #80

@klirichek

Description

@klirichek

Hi!

I've tried to just build on Raspberry PI 4b, on Ubuntu 20.04

$ uname -a
Linux ubuntu 5.4.0-1032-raspi #35-Ubuntu SMP PREEMPT Fri Mar 19 20:52:40 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux
$ gcc --version
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat /proc/cpuinfo
processor	: 0
BogoMIPS	: 108.00
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd08
CPU revision	: 3
...

Hardware	: BCM2835
Revision	: c03112
Serial		: 100000007c08a3a6
Model		: Raspberry Pi 4 Model B Rev 1.2

with simple make build && cd build && cmake .. then make

That tiny naive try immediately failed with absence of 'immintrin.h'

I've tried a little digg and replaced line from 'common.h' about immitrin.h to

//#include <immintrin.h>
#  if defined(__ARM_NEON)
#    include <arm_neon.h>
#  elif defined(__WINDOWS__) || defined(__WINRT__)
/* Visual Studio doesn't define __ARM_ARCH, but _M_ARM (if set, always 7), and _M_ARM64 (if set, always 1). */
#    if defined(_M_ARM)
#      include <armintr.h>
#      include <arm_neon.h>
#      define __ARM_NEON 1 /* Set __ARM_NEON so that it can be used elsewhere, at compile time */
#    endif
#    if defined (_M_ARM64)
#      include <arm64intr.h>
#      include <arm64_neon.h>
#      define __ARM_NEON 1 /* Set __ARM_NEON so that it can be used elsewhere, at compile time */
#    endif
#  endif

it also fails with huge bunch of errors about non-declared '_mm_storeu_si128', '_mm_loadu_si128', '__m128i', and many others.

So, there are some obvious questions from it:

  1. Is it possible to build on that platform? (AFAIK that is not only RPi, but new Mac on M1 also might be targeted, that is more serious!)
  2. If it is possible - is any instructions available?
  3. If it is not possible with hardware intrinsic - is any legacy way possible - let it works not so fast at all, as a pure 'stub', but at least would be buildable, so that consumers of the lib can also be usable?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions