Michael Weiser <mich...@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

> 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

> 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
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.


Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
nettle-bugs mailing list

Reply via email to