Hello,
пн, 2 мар. 2020 г. в 21:44, Niels Möller nisse@lysator.liu.se:
I've been offline, skiiing, for a week, and I haven't yet caught up we email. http://www.lysator.liu.se/~nisse/misc/s%C3%A5nfj%C3%A4llet.jpg
Michael Weiser michael.weiser@gmx.de writes:
Hi Niels,
On Sat, Feb 22, 2020 at 07:58:10AM +0100, Niels Möller wrote:
Lookingup NSLU2 on wikipedia, it seems it features a "Intel XScale cpu" featuring an "ARMv5TE ISA without the floating point instructions." I take it this can be run in BE mode?
The Intel XScale and IXP4xx are BE by default, IIRC. For them it's even a bit of a hike to run them LE since all their companion controllers and firmware blobs are BE as well.
Ok, so than ARM BE may be more relevant for these older chips than for newer ones, which are almost always run in LE mode?
It has become mostly irrelevant after authors of SlugOS have invented a way to run LE binaries on NSLU2. Working in embedded hardware area I haven't seen an armeb project for ages.
- Eliminate use of rev in the armbe code.
... I've been looking at the revs and they now strike me as taking the easy way out anyway. They work around the implicit LE order in which some remaining bytes from a buffer are saved byte-wise. This should be doable without the revs by making the store work in BE fashion in BE mode. I plan to look into this but would certainly appreciate any help Dmitry and Андрей might be able to give here since it's not as if I've been doing nothing but arm asm the last couple of years - rather the opposite.
I've only had a quick look at the patch later in the thread, but I agree that if we have a loop to store a byte at a time anyway, it should be straight forward to "just" reverse the shifting direction depending on byte order.
- Somehow arrange in configure so that the memxor files in particular aren't used when targetting armv5be. If you want to test the effects before hacking configure.ac, I think it should be as easy as removing the memxor*.asm symlinks after running configure.
Nah, we can do better than that. :)
But relatedly, it looks like arm/v6/sha1-compress.asm and arm/v6/sha256-compress.asm need ARMv6 only on little-endian hosts. So it might be worthwhile to try to use these files on armv5be? I don't see an obvious great way to set it up though.
One way might be to add a arm/be/sha1-compress.asm file which simply includes the v6 file, and then add arm/be to the asm_path where appropriate.
I will take a look on fixing the code for armv5. Replacing rev with bit fiddling should be easy.