Re: bswap is slow on SPARC
nia <[email protected]> Mon, 24 Nov 2025 21:08:31 +0000
| Newsgroups | gmane.os.netbsd.ports.sparc64,gmane.os.netbsd.ports.sparc |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Nov 24, 2025 at 07:55:37PM +0000, Sad Clouds wrote: > On Mon, 24 Nov 2025 13:30:50 +0000 > nia <[email protected]> wrote: > > > When encryption algorithms expect to be able to encode little-endian > > integers in a tight loop, that adds up to being *slow*. Especially > > when NetBSD encrypts swap by default now. > > I wonder, why store data in a little-endian byte order on a big-endian > architecture? Is it that common to access the same swap partition > across multiple architectures? Hey, Taylor can probably answer this better than I can. The primitives are designed under the assumption that little-endian accesses are fast on big endian machines, but big-endian accesses aren't fast on little endian machines. Since the academic papers describe them in this way, their security verifications do too. We're not big enough in the cryptography world to be designing custom algorithms for big-endian machines. This isn't some grand conspiracy against big endian, most of these primitives were designed with UltraSPARC and PowerPC in mind. They probably just didn't expect the compiler to generate such bad code. The applications for fast byte-swaps extend way beyond this too. Most multimedia file formats aren't big-endian.