mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Cc: James Tirta Halim <tirtajames45@gmail.com>
Subject: Re: [musl] [PATCH] add memcmpeq: memcmp that returns length of first mismatch
Date: Thu, 29 Feb 2024 05:19:59 +0100	[thread overview]
Message-ID: <ZeAF7wsnG0ZZ1zL7@voyager> (raw)
In-Reply-To: <Pine.BSM.4.64L.2402282312460.1531@herc.mirbsd.org>

Am Wed, Feb 28, 2024 at 11:14:27PM +0000 schrieb Thorsten Glaser:
> Markus Wichmann dixit:
> >4. All the other musl C code avoids misaligned word access. I don't know
> >which architecture/ABI doesn't allow it, but it is nevertheless the
>
> Almost all of them. i386/amd64 penalise it heavily and it can cause
> trouble when crossing page sizes, cacheline sizes, etc. as well. On
> alpha, many ARM, SPARC, and others, it’s an instant SIGBUS/SIGSEGV.
>

For i386 and AMD64, musl already performs misaligned access at least in
the memset. I can't find a source for it right now, but I believe it was
tested to basically make no timing difference inside of a cache line, a
very minor difference across cache lines, and a bit of a spike across
pages. Of course, only one in 1024 word accesses crosses a page boundary
even if misaligned. The idea that misaligned memory access is slow on
x86 is a pervasive myth that people really need to get over.

Musl doesn't support either alpha or sparc. But according to [1], armv4
was actually worse than the description above: It would actually perform
some memory access, but at the address rounded down to a word boundary,
and then rotate the resulting value according to the low bits.

So that's a new thing to add to my list of horrors. Misaligned accesses
crashing I can at least deal with. Misaligned accesses returning the
wrong data is a thing that was not on my radar before. They fixed it in
armv7, though.

The reason I asked, BTW, was because I had always thought PowerPC to be
on the list of architectures that don't support misaligned access in the
baseline ISA, but actually, most PowerPC implementations do, and also
even the most general 32-bit PowerPC architecture description says that
an alignment interrupt may be triggered by an integer load/store
instruction only when crossing a page boundary. And otherwise there is
no issue.

Ciao,
Markus

[1] https://medium.com/@iLevex/the-curious-case-of-unaligned-access-on-arm-5dd0ebe24965

      parent reply	other threads:[~2024-02-29  4:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-27 14:07 James Tirta Halim
2024-02-27 14:49 ` Rich Felker
2024-02-27 14:51   ` Rich Felker
2024-02-28  4:40     ` Markus Wichmann
2024-02-28 23:14       ` Thorsten Glaser
2024-02-29  0:02         ` Pedro Falcato
2024-02-29  0:10           ` Thorsten Glaser
2024-02-29  0:57             ` Robert Clausecker
2024-02-29  1:13               ` Pedro Falcato
2024-02-29  4:19         ` Markus Wichmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZeAF7wsnG0ZZ1zL7@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    --cc=tirtajames45@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).