Re: CVS commit: src/sys/arch/x86/x86

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote:
> 
> The C11 standard could indeed use consistent wording. In one place
> "correctly aligned" in other alignment "restrictions" and
> "requirements". None of these terms is marked as a keyword or term and I
> read them in the context of the document as the same phenomenon (I
> haven't found a different interpretation of this in the wild).

Right, but, architecturally, x86 doesn't have these "restrictions" or
"requirements".  Not for correctness, not with the overwhelming majority
of integer instructions.  Only (sometimes) for performance.

Which makes relying on the standard's language about unaligned access
incorrect.  There's no undefined behavior here because there can't be;
strict alignment is not a feature of the target architecture.

That means that a compiler which emits broken code if it encounters such
a pointer is the broken thing -- *not the source code* -- and whanging
around x86 MD code in our tree to accomodate such a compiler would be
broken too.

I understand we have some code that's on the borderline between being MI
and MD, or that's "MD but for several different architectures".  ACPICA
is an obvious example.  And that such code may legitimately be compiled for
targets where unaligned access is not architecturally valid, and compilers
are free to do odd things with code that tries to do it.  But the right
thing to do, I think, is to acknowledge that such code is MI; not to, by
misguided policy, insist that _all_ "MD" code should be written as if it
were MI.

Because if you head down that road, we're going to be forced to
write a bunch more stuff in assembler that we'd figured out over the decades
how to write in a performant and readable way in C; and I don't think anyone
benefits from having more asm in our kernel.

Thor