Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147944
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Bit field usage |
| Date | 2019-11-11 20:31 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <qqccum$lt5$1@dont-email.me> (permalink) |
| References | (10 earlier) <slrnqs901k.s72.ccollins476ad@pseudoephedrine.nightmare-heaven.no-ip.biz> <qq34rd$v8u$1@dont-email.me> <slrnqsbcdc.s72.ccollins476ad@pseudoephedrine.nightmare-heaven.no-ip.biz> <qq9251$aej$1@dont-email.me> <slrnqsj6dd.ih3.ccollins476ad@pseudoephedrine.nightmare-heaven.no-ip.biz> |
On 11/11/2019 18:26, Christopher Collins wrote:
> On 2019-11-10, David Brown <david.brown@hesbynett.no> wrote:
>> On 08/11/2019 19:19, Christopher Collins wrote:
>>> You can't always arrange for aligned data. Take a networking stack for
>>> example. You need functions to parse and strip headers from the front
>>> of a buffer. Unless each header is sized according to the alignment
>>> requirements of the processor, the buffer won't remain aligned
>>> throughout this process.
>>>
>>> The reverse process, prepending headers to outgoing data, has the same
>>> characteristics.
>>
>> I said that unaligned accesses were not a benefit in this case, not that
>> they are never useful.
>
> This is what you said:
>
> There are rarely any advantages in having non-aligned data, and you
> usually have to go out of your way to create it in the first place
> (often invoking undefined behaviour) - while there are good hardware
> efficiency reasons for wanting alignment.
>
> To me, this sounds like you object to using unaligned data except in
> very special circumstances. I disagree, but perhaps I am misreading
> your argument.
No, that is a reasonable summary of what I said. There /are/ times when
unaligned accesses are the best solution (noting that "best" depends on
the requirements, and can be very subjective) - but I don't think it
happens often. And even then, I think it is better to let the compiler
deal with it rather than manually accessing data at non-aligned
addresses. It's fine if the compiler turns a memcpy() of 4 bytes into a
single word read - much less fine if the programmer casts a char* or
void* pointer to an int* in order to access the non-aligned data.
Similarly, /sometimes/ packed structs are a convenient solution - but
not often.
>
>>> I used to eschew packed structs as nonstandard and of little practical
>>> use. Then we tried using them in a Bluetooth stack implementation and
>>> the reduction in code size was dramatic (sorry, I don't have numbers).
>>> I believe there is simply no way to achieve the same reduction in code
>>> size without using packed structs (on architectures that support
>>> unaligned access).
>>>
>>
>> You are wrong - but only if you have a good enough compiler, use the
>> right options, and write your code in a way that the compiler recognises
>> and optimises. It is entirely possible for a compiler to optimise
>> memcpy or byte-by-byte access into unaligned word access if the target
>> supports it, and it certainly happens in some cases. But it won't
>> happen in all cases, and if efficiency matters you'll have to check the
>> generated output.
>
> Do you know of a compiler that does that? (Honest question). From the
> godbolt example I posted, it seems gcc with -Os does not. In theory,
> compilers could do all sorts of optimizations. That doesn't help
> someone meet a project's requirements.
From the example you posted, gcc /does/ do exactly that. You wrote
"memcpy(&out[1], &m->b, 4);", and the compiler generated "ldr r3, [r0,
#1]" "str r3, [r1, #1]".
When you already have the packed struct, it makes more sense to do a
single memcpy() rather than several individual memcpy's turned into
unaligned accesses. But the compiler is clearly optimising the memcpy's
into larger (potentially) unaligned accesses.
>
>> I don't see much use of packed structs. But that does not mean they are
>> not useful on occasion.
>
> In addition to reduced code size, packed structs also simplify code.
Your code was not really doing marshalling, despite the name of the
functions, since it was just a straight copy.
Usually when you are reading in the header for data coming in from
outside (on the network, or in a file), you are doing lots of work on it
anyway - checking for validity, in particular. And usually much of the
header will be used only at that point. You often don't need to store
it, and you don't need to access the fields.
But sure, on the occasions when packed structs really help, use them.
> Rather than needing to implement unmarshalling code for every header and
> command in a stack, you simply do this:
>
> struct foo_header *hdr = (struct foo_header *)buf;
>
> and you have a header ready to be processed.
>
Except that you don't - you have to be careful with casting pointer
types, or fall foul of aliasing rules. If you are doing a lot of this
kind of thing, you might like to add:
#pragma GCC optimize("-fno-strict-aliasing")
and then the cast is safe (on gcc or clang).
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 08:03 +0200
Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-24 10:15 -0600
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 18:55 +0200
Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-24 21:28 -0600
Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-24 17:22 +0000
Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-24 19:45 +0200
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 19:59 +0200
Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-24 20:02 +0200
Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-24 21:29 -0600
Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-25 07:51 +0200
Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-25 15:05 +0000
Re: Bit field usage Bart <bc@freeuk.com> - 2019-10-24 19:13 +0100
Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-24 20:54 +0200
Re: Bit field usage Bart <bc@freeuk.com> - 2019-10-24 20:12 +0100
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-24 23:03 +0200
Re: Bit field usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-10-24 22:50 +0100
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-25 09:18 +0200
Re: Bit field usage Reinhardt Behm <rbehm@hushmail.com> - 2019-10-25 15:46 +0800
Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 12:36 -0500
Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-25 15:04 +0000
Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 12:40 -0500
Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 21:12 +0200
Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-25 09:25 -0600
Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 12:52 -0500
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 19:56 +0200
Re: Bit field usage already5chosen@yahoo.com - 2019-10-24 12:03 -0700
Re: Bit field usage scott@slp53.sl.home (Scott Lurndal) - 2019-10-24 19:40 +0000
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-24 22:15 +0200
Re: Bit field usage already5chosen@yahoo.com - 2019-10-24 14:16 -0700
Re: Bit field usage Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-24 17:50 -0700
Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-25 09:36 -0600
Re: Bit field usage Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-10-27 04:54 -0700
Re: Bit field usage Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-10-27 10:05 -0600
Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 20:15 +0200
Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 20:16 +0200
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-26 20:37 +0200
Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-26 13:41 -0500
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-26 21:54 +0200
Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 03:46 -0700
Re: Bit field usage jacobnavia <jacob@jacob.remcomp.fr> - 2019-10-27 12:50 +0100
Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 06:37 -0700
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-27 13:00 +0100
Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 07:19 -0700
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-27 22:30 +0100
Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-07 12:36 -0800
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-08 08:18 +0100
Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-08 10:19 -0800
Re: Bit field usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-08 21:47 +0000
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-10 14:08 +0100
Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-11 09:26 -0800
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-11 20:31 +0100
Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-11 23:01 -0800
Re: Bit field usage Christopher Collins <ccollins476ad@gmail.com> - 2019-11-11 23:25 -0800
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-12 10:54 +0100
Re: Bit field usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-12 14:43 +0000
Re: Bit field usage James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 10:54 -0500
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-11-12 19:37 +0100
Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-27 08:36 -0500
Re: Bit field usage already5chosen@yahoo.com - 2019-10-27 06:49 -0700
Re: Bit field usage Bonita Montero <Bonita.Montero@gmail.com> - 2019-10-27 14:23 +0100
Re: Bit field usage Robert Wessel <robertwessel2@yahoo.com> - 2019-10-27 08:42 -0500
Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-26 21:06 +0200
Re: Bit field usage Bart <bc@freeuk.com> - 2019-10-26 20:41 +0100
Re: Bit field usage Philipp Klaus Krause <pkk@spth.de> - 2019-10-27 08:29 +0100
Re: Bit field usage David Brown <david.brown@hesbynett.no> - 2019-10-27 13:05 +0100
csiph-web