Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: comp.arch Subject: Re: unaligned load/store Date: Thu, 26 Dec 2024 13:38:04 -0500 Organization: A noiseless patient Spider Lines: 27 Message-ID: References: <9534a1cd1364f2127a1951cc85002f29@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Thu, 26 Dec 2024 19:38:08 +0100 (CET) Injection-Info: dont-email.me; posting-host="27a4432ad389d20129f54945a5a43d71"; logging-data="3265322"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18wHyfhnXityEMUJZsPvvKR/dL7ORERdXY=" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:pdHOZkN5JzIP2VEZ/ZfWCgSSB/s= sha1:U4YTU60uzMDarXQeS+0H+K9E1gQ= Bytes: 2567 >> Aligned data is always best, Misaligned data comes at very low cost. >> SW overhead = 0 > Thinking about this for a bit... for a clean-sheet architecture > like My66000, could there actually be an advantage to do > struct layout like the VAX did, with everything aligned on byte > boundaries? I highly doubt it. Making unaligned accesses work efficiently is great, but that's no reason to abuse them: - Going back to Mitch's description, in case B.1 the misalignment is truly "free", but for B.2, B.3, and B.4 the misalignment does come at a cost, not necessarily visible in terms of cycles but at least in terms of cache bandwidth, which can have an impact on overall speed and energy use. Of course, properly aligning your data will also come with costs, but "packed structs" don't come totally free. - AFAIK most efforts to support concurrency take it for granted that atomic accesses are supported only when properly aligned. I expect it's at least as easy (and more portable) to reorder fields by order of (expected) size to avoid excessive padding in aligned data, than it is to add manual padding/alignment to avoid the cost of misalignment in "packed structs". Stefan