Michael Weiser michael@weiser.dinsnail.net writes:
Right. When this still didn't fix it, I compared little- and big-endian behaviour and found that a.) vldm and vstm switch doublewords for no reason I can see or find documentation about and b.)
By "doublewords", you mean 64-bit words, right?
It might make sense to view it as big-endian or little-endian load of 128-bit values, and a 128-bit (16-byte) byte swap will then also swap the low and high 64-bit halves.
vext extracts from the top of the vector, not bottom. Taking both into account, I now have chacha and salsa20 passing tests.
If it's hard to find docs, I take it as a sign big-endian arm is a bit obscure... Could you add a short note to arm/README with your findings? (It's quite some time since I did neon assembly, so I don't recall off the top of my head any details on what the various instructions, in particular vextr, do).
PASS: cxx ./sexp-conv-test: line 17: ../tools/sexp-conv: No such file or directory cmp: EOF on test1.out which is empty FAIL: sexp-conv SKIP: pkcs1-conv ./nettle-pbkdf2-test: line 18: ../tools/nettle-pbkdf2: No such file or directory cmp: EOF on test1.out which is empty FAIL: nettle-pbkdf2 PASS: symbols PASS: dlopen ==================== 2 of 93 tests failed ====================
They've been failing all along. Can they be ignored?
They're not that relevant to your changes, but I'd like to understand why they fail. What's the contents of the tools dir in your buld tree? You haven't done something like switched from building in the source tree build to a separate build tree, without a proper cleaning (make distclean) in the source tree?
Weeell, depends on what you consider easier: I haven't found any binary distribution that supports armeb. Yocto and buildroot seem to support it but still require compiling the whole thing.
Hmm. Sounds more than a bit inconvenient.
Apple does do arm and someone could potentially want to build a fat nettle that supports x86_64 and arm or rather arm and arm64.
My concern is not breaking any setup which currently works, e.g, a non assebly "universal" build involving architectures with different endianness.
Does nettle currently support being compiled fat with assembly at all?
I don't think so. I'd expect one would have to build for one arch at a time, and have some postprocessing scripts to produce apple-fat libraries.
But then I want to have a nice error message so as to not leave the user with an aborted build and no apparent reason. :) Is this portable?
According to http://pubs.opengroup.org/onlinepubs/9699919799/utilities/m4.html, errprint and m4exit are standard m4. (If they're also supported in practice is a different question, it's desirable to at least work with both GNU and BSD m4). If __file__ and __line__ are unportable, you could omit that. Since the error message reports a pretty global config problem, precise location isn't that important.
The patch got quite large now. Should I better make a series out of it?
As you prefer, I think it is workable as is. It might help to split out the configure-related changes.
Regards, /Niels