Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c++
Subject: Re: Performance of unaligned memory-accesses
Date: Sat, 10 Aug 2019 17:53:30 -0700
Organization: None to speak of
Lines: 57
Message-ID: <ln1rxs8qut.fsf@kst-u.example.com>
References: <qihcsq$nmc$3@news.albasani.net> <qij248$q5t$1@news.albasani.net> <qij6qd$gr3$1@dont-email.me> <qij7im$94r$1@news.albasani.net> <qija1p$vl7$1@dont-email.me> <qijadu$i2$1@news.albasani.net> <qijjqs$fsl$1@dont-email.me> <qijk9k$77t$1@news.albasani.net> <qijt10$3b1$1@dont-email.me> <qijte7$d22$1@news.albasani.net> <ok0rkele4e9stnfpedvi8ip6n1qek5s767@4ax.com> <qik1o7$2iq$1@news.albasani.net> <qik213$m7$1@news.albasani.net> <iwg3F.642677$Ho1.369267@fx40.am4> <qik9tj$cps$1@news.albasani.net> <2tm3F.2462684$ng1.1031546@fx36.am4> <qimnde$ki1$1@dont-email.me> <qimnlg$8q8$1@news.albasani.net> <qind4k$kp8$1@dont-email.me> <gr90j0Fu65U2@mid.individual.net> <qinn70$514$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="cb4b2dc0baf4fefc9628bc1b5f7f50df"; logging-data="27227"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+OJcv/fGdvz4ubbYLK6k/N"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:gdnblCAzN3qRGM+B2V1p+GHvEAI= sha1:OJs7NHkVrzrA0V/DGwqMxEZ0XY4=
Xref: csiph.com comp.lang.c++:67548

David Brown <david.brown@hesbynett.no> writes:
> On 11/08/2019 00:59, Ian Collins wrote:
>> On 11/08/2019 09:32, David Brown wrote:
[...]
>>> You've given no evidence to suggest that any OS emulates unaligned
>>> access.  It might well be that some OS's do, for compatibility with
>>> binaries for related processors - but your "proof by repeated assertion"
>>> is getting tedious.
>>>
>>> No compiler would /ever/ rely on trapping and emulation for handling
>>> unaligned accesses to packed objects - that would be absurdly 
>>> inefficient.
>> 
>> Solaris SPARC?
>> 
>> https://blogs.oracle.com/d/on-misaligned-memory-accesses
>
> You are missing a critical detail.  I said that no compiler would ever 
> rely on trapping and emulation for handling unaligned accesses to 
> /packed/ objects.  We are not talking about accessing data via a pointer 
> here - then it makes sense on a processor like the SPARC to assume 
> accesses are aligned, and handle anything else by crashing or slow 
> emulation.  We are talking about structs with some sort of "packed" 
> feature.  The compiler knows these are unaligned, and would use smaller 
> accesses.  It won't let the program crash - that would be pointless in 
> the face of a packed struct.  It won't rely on seriously slow trap 
> handling when it knows without doubt that the data is misaligned - it 
> will use appropriate smaller accesses.

Have you examined the code generated by a SPARC compiler for an
unaligned access to a member of a packed structure?  (I'm assuming
that the compiler supports packed structures.)

I don't have access to a SPARC system.  Perhaps someone who does could
compile this program and compare the code to access obj.x to the code to
access obj.z.  The "__attribute__((packed))" syntax works for gcc;
replace it as needed for whatever compiler you're using.

#include <iostream>
#include <cstddef>
int main() {
    struct foo {
        int x;
        char y;
        int z;
    } __attribute__((packed));
    foo obj = { 10, '?', 20 };
    int x_value = obj.x;
    int z_value = obj.z;
    std::cout << x_value << " at " << offsetof(struct foo, x) << "\n";
    std::cout << z_value << " at " << offsetof(struct foo, z) << "\n";
}

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */