Hi Mamone, Jeff,
sorry for the duplication, used the wrong sender address for the list again.
On Fri, Jan 22, 2021 at 07:07:46PM -0500, Jeffrey Walton wrote:
Do you think it makes sense to try and adjust the code to work with the BE layout natively and have a full 128bit reverse after ldr-like loads on LE instead (considering that 99,999% of aarch64 users will run LE)?
If you don't have a use-case we can suspend big-endian support of GCM optimization on aarch64 until we get a request, use case or maybe aarch64_be get more support in the future by main distributions.
I was actually referring to the performance hit for the overwhelming number of users of a possible "mostly natively BE with quite some overhead for converting back and forth on LE" approach compared to "mostly-LE with slight adjustments for BE" as it (seemingly) started out.
But today's session really cleared up for me that it isn't so much LE vs. BE but just vector element order. What endianness remains is just the given interface to the rest of the nettle code being defined as BE. With the last patch from my previous email all this seemed to fall into place nicely.
+1. At minimum, someone needs to produce an image to load on a commodity board. If there are no images for a common board then there's no demand in the market. There's no reason to jump through hoops, like qemu, to solve a problem that does not exist.
My use-case has always been "because I can" and I really appreciate everone's indulgence so far. So yes, by all means, focus on producing LE asm for arm/aarch64 and I either dig into that for BE support or just disable asm routines on my BE boards.
I also sometimes wonder who is actually producing all this nicely working armeb and aarch64_be support in Qemu and Linux kernel when there's apparently no users. I can understand that it's 90 or 95% very good programming where endianness handling for PowerPC or MIPS just also happens to work for BE arm. But the other 5% must come from somewhere. So there must be some demand by someone but it's certainly very obscure. ;)