Comments (8)
I agree, let's get it done. It's on my to-do list for tomorrow.
from base64.
I think that the cmake stuff has had enough bake time now and it might be wise to get that release out the door before we start doctoring with the runtime detection.
from base64.
I just checked off the last two remaining issues from the list. As far as I'm concerned, it's time for a release.
With my unfamiliarity with CMake, I'm unsure of exactly how solid the CMake stuff is now. We recently had some pull requests to push some minor issues that were found in production. Should we wait a week or two to see if something else shakes out?
I guess we could just release 0.5.0
, and release a 0.5.1
if any bugs are found.
from base64.
I think that the major things have been ironed out since we have been able to integrate it with three package managers and htot even cross compiled with the build system.
I guess we could just release
0.5.0
, and release a0.5.1
if any bugs are found.
Sounds reasonable
from base64.
Hi, I tried the CMakeLists.txt cross compiling for a i.MX6ULL which is a Armv7-A processor.
According to this document, "Armv7-A and AArch32 have the same general purpose Arm registers – 16 x 32-bit general purpose Arm registers (R0-R15)."
But at the same time, it seems to support NEON:
"Armv7-A and AArch32 have 32 x 64-bit NEON registers (D0-D31). These registers can also be viewed as 16x128-bit registers (Q0-Q15). Each of the Q0-Q15 registers maps to a pair of D registers, as shown in the following figure."
As you can see from the output below, somehow the CMakeLists.txt does not detect that I am cross compiling for ARM:
-- The following features have been enabled:
* CLI, enables the CLI executable for encoding and decoding
-- The following features have been disabled:
* OpenMP codec, spreads codec work accross multiple threads
* SSSE3, add SSSE 3 codepath
* SSE4.1, add SSE 4.1 codepath
* SSE4.2, add SSE 4.2 codepath
* AVX, add AVX codepath
* AVX2, add AVX2 codepath
* NEON32, add NEON32 codepath
* NEON64, add NEON64 codepath
If I read the documentation correctly, my target ARCH should be ARM32 but with NEON enabled, right?
from base64.
ah I think this line is the problem:
cmake_dependent_option(BASE64_WITH_NEON32 "add NEON32 codepath" OFF _TARGET_ARCH_arm OFF)
add_feature_info(NEON32 BASE64_WITH_NEON32 "add NEON32 codepath")
should probably be:
cmake_dependent_option(BASE64_WITH_NEON32 "add NEON32 codepath" ON _TARGET_ARCH_arm OFF)
add_feature_info(NEON32 BASE64_WITH_NEON32 "add NEON32 codepath")
from base64.
IIRC we decided to disable NEON32 support by default even if the compiler supports it, because it cannot be detected at runtime whether or not the CPU supports the NEON extensions. Therefore you need to explicitly enable NEON32 support via the GUI or with the CLI like so:
cmake -G [...] -DBASE64_WITH_NEON32=ON ..
HTH
(and please open a new issue or discussion next time)
from base64.
@aklomp I think we can conclude the stabilization phase now as there haven't been any new issues for a month now. So I don't think there is any point in delaying the release any further.
from base64.
Related Issues (20)
- Concurrent call interface “base64_decode” appear Segment error
- Library naming HOT 3
- AVX2: enc: add inline asm codepath
- Change license to BSD 3-clause
- CI: upgrade deprecated Ubuntu image
- AVX: enc: add inline asm codepath
- SSSE3: enc: add inline asm codepath HOT 1
- bug: out-of-bounds read when using inline assembly code path HOT 3
- bug: codec_choose_x86 does not check for OS AVX512 support HOT 3
- Decoding data containing <NUL> values HOT 6
- bin/base64: modernize the demo program
- Add a macro to calculate encoded size from raw size and vice versa
- Investigate `gf2p8affineqb` for the shuffle step
- enc: asm: add memory and flags as clobbers
- Integrate with google/oss-fuzz for continuous fuzz testing
- NEON64: enc: add inline asm codepath HOT 1
- cmake: generate only plain codecs
- clang build fails with inline ASM on NEON64 (Apple M1) HOT 7
- NEON64: enc: convert full encoding loop to inline assembly
- NEON64: enc: ASM build fails on gcc with dd7a2b5f31 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from base64.