| 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
|---|
| 2 | <html>
|
|---|
| 3 | <!-- Copyright (C) 2022 Richard Stallman and Free Software Foundation, Inc.
|
|---|
| 4 |
|
|---|
| 5 | (The work of Trevis Rothwell and Nelson Beebe has been assigned or
|
|---|
| 6 | licensed to the FSF.)
|
|---|
| 7 |
|
|---|
| 8 | Permission is granted to copy, distribute and/or modify this document
|
|---|
| 9 | under the terms of the GNU Free Documentation License, Version 1.3 or
|
|---|
| 10 | any later version published by the Free Software Foundation; with the
|
|---|
| 11 | Invariant Sections being "GNU General Public License," with the
|
|---|
| 12 | Front-Cover Texts being "A GNU Manual," and with the Back-Cover
|
|---|
| 13 | Texts as in (a) below. A copy of the license is included in the
|
|---|
| 14 | section entitled "GNU Free Documentation License."
|
|---|
| 15 |
|
|---|
| 16 | (a) The FSF's Back-Cover Text is: "You have the freedom to copy and
|
|---|
| 17 | modify this GNU manual. Buying copies from the FSF supports it in
|
|---|
| 18 | developing GNU and promoting software freedom." -->
|
|---|
| 19 | <!-- Created by GNU Texinfo 6.7, http://www.gnu.org/software/texinfo/ -->
|
|---|
| 20 | <head>
|
|---|
| 21 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
|---|
| 22 | <title>Bit Field Packing (GNU C Language Manual)</title>
|
|---|
| 23 |
|
|---|
| 24 | <meta name="description" content="Bit Field Packing (GNU C Language Manual)">
|
|---|
| 25 | <meta name="keywords" content="Bit Field Packing (GNU C Language Manual)">
|
|---|
| 26 | <meta name="resource-type" content="document">
|
|---|
| 27 | <meta name="distribution" content="global">
|
|---|
| 28 | <meta name="Generator" content="makeinfo">
|
|---|
| 29 | <link href="index.html" rel="start" title="Top">
|
|---|
| 30 | <link href="Symbol-Index.html" rel="index" title="Symbol Index">
|
|---|
| 31 | <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
|---|
| 32 | <link href="Structures.html" rel="up" title="Structures">
|
|---|
| 33 | <link href="const-Fields.html" rel="next" title="const Fields">
|
|---|
| 34 | <link href="Bit-Fields.html" rel="prev" title="Bit Fields">
|
|---|
| 35 | <style type="text/css">
|
|---|
| 36 | <!--
|
|---|
| 37 | a.summary-letter {text-decoration: none}
|
|---|
| 38 | blockquote.indentedblock {margin-right: 0em}
|
|---|
| 39 | div.display {margin-left: 3.2em}
|
|---|
| 40 | div.example {margin-left: 3.2em}
|
|---|
| 41 | div.lisp {margin-left: 3.2em}
|
|---|
| 42 | kbd {font-style: oblique}
|
|---|
| 43 | pre.display {font-family: inherit}
|
|---|
| 44 | pre.format {font-family: inherit}
|
|---|
| 45 | pre.menu-comment {font-family: serif}
|
|---|
| 46 | pre.menu-preformatted {font-family: serif}
|
|---|
| 47 | span.nolinebreak {white-space: nowrap}
|
|---|
| 48 | span.roman {font-family: initial; font-weight: normal}
|
|---|
| 49 | span.sansserif {font-family: sans-serif; font-weight: normal}
|
|---|
| 50 | ul.no-bullet {list-style: none}
|
|---|
| 51 | -->
|
|---|
| 52 | </style>
|
|---|
| 53 |
|
|---|
| 54 |
|
|---|
| 55 | </head>
|
|---|
| 56 |
|
|---|
| 57 | <body lang="en">
|
|---|
| 58 | <span id="Bit-Field-Packing"></span><div class="header">
|
|---|
| 59 | <p>
|
|---|
| 60 | Next: <a href="const-Fields.html" accesskey="n" rel="next">const Fields</a>, Previous: <a href="Bit-Fields.html" accesskey="p" rel="prev">Bit Fields</a>, Up: <a href="Structures.html" accesskey="u" rel="up">Structures</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Symbol-Index.html" title="Index" rel="index">Index</a>]</p>
|
|---|
| 61 | </div>
|
|---|
| 62 | <hr>
|
|---|
| 63 | <span id="Bit-Field-Packing-1"></span><h3 class="section">15.7 Bit Field Packing</h3>
|
|---|
| 64 |
|
|---|
| 65 | <p>Programs to communicate with low-level hardware interfaces need to
|
|---|
| 66 | define bit fields laid out to match the hardware data. This section
|
|---|
| 67 | explains how to do that.
|
|---|
| 68 | </p>
|
|---|
| 69 | <p>Consecutive bit fields are packed together, but each bit field must
|
|---|
| 70 | fit within a single object of its specified type. In this example,
|
|---|
| 71 | </p>
|
|---|
| 72 | <div class="example">
|
|---|
| 73 | <pre class="example">unsigned short a : 3, b : 3, c : 3, d : 3, e : 3;
|
|---|
| 74 | </pre></div>
|
|---|
| 75 |
|
|---|
| 76 | <p>all five fields fit consecutively into one two-byte <code>short</code>.
|
|---|
| 77 | They need 15 bits, and one <code>short</code> provides 16. By contrast,
|
|---|
| 78 | </p>
|
|---|
| 79 | <div class="example">
|
|---|
| 80 | <pre class="example">unsigned char a : 3, b : 3, c : 3, d : 3, e : 3;
|
|---|
| 81 | </pre></div>
|
|---|
| 82 |
|
|---|
| 83 | <p>needs three bytes. It fits <code>a</code> and <code>b</code> into one
|
|---|
| 84 | <code>char</code>, but <code>c</code> won’t fit in that <code>char</code> (they would
|
|---|
| 85 | add up to 9 bits). So <code>c</code> and <code>d</code> go into a second
|
|---|
| 86 | <code>char</code>, leaving a gap of two bits between <code>b</code> and <code>c</code>.
|
|---|
| 87 | Then <code>e</code> needs a third <code>char</code>. By contrast,
|
|---|
| 88 | </p>
|
|---|
| 89 | <div class="example">
|
|---|
| 90 | <pre class="example">unsigned char a : 3, b : 3;
|
|---|
| 91 | unsigned int c : 3;
|
|---|
| 92 | unsigned char d : 3, e : 3;
|
|---|
| 93 | </pre></div>
|
|---|
| 94 |
|
|---|
| 95 | <p>needs only two bytes: the type <code>unsigned int</code>
|
|---|
| 96 | allows <code>c</code> to straddle bytes that are in the same word.
|
|---|
| 97 | </p>
|
|---|
| 98 | <p>You can leave a gap of a specified number of bits by defining a
|
|---|
| 99 | nameless bit field. This looks like <code><var>type</var> : <var>nbits</var>;</code>.
|
|---|
| 100 | It is allocated space in the structure just as a named bit field would
|
|---|
| 101 | be allocated.
|
|---|
| 102 | </p>
|
|---|
| 103 | <p>You can force the following bit field to advance to the following
|
|---|
| 104 | aligned memory object with <code><var>type</var> : 0;</code>.
|
|---|
| 105 | </p>
|
|---|
| 106 | <p>Both of these constructs can syntactically share <var>type</var> with
|
|---|
| 107 | ordinary bit fields. This example illustrates both:
|
|---|
| 108 | </p>
|
|---|
| 109 | <div class="example">
|
|---|
| 110 | <pre class="example">unsigned int a : 5, : 3, b : 5, : 0, c : 5, : 3, d : 5;
|
|---|
| 111 | </pre></div>
|
|---|
| 112 |
|
|---|
| 113 | <p>It puts <code>a</code> and <code>b</code> into one <code>int</code>, with a 3-bit gap
|
|---|
| 114 | between them. Then <code>: 0</code> advances to the next <code>int</code>,
|
|---|
| 115 | so <code>c</code> and <code>d</code> fit into that one.
|
|---|
| 116 | </p>
|
|---|
| 117 | <p>These rules for packing bit fields apply to most target platforms,
|
|---|
| 118 | including all the usual real computers. A few embedded controllers
|
|---|
| 119 | have special layout rules.
|
|---|
| 120 | </p>
|
|---|
| 121 | <hr>
|
|---|
| 122 | <div class="header">
|
|---|
| 123 | <p>
|
|---|
| 124 | Next: <a href="const-Fields.html" accesskey="n" rel="next">const Fields</a>, Previous: <a href="Bit-Fields.html" accesskey="p" rel="prev">Bit Fields</a>, Up: <a href="Structures.html" accesskey="u" rel="up">Structures</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Symbol-Index.html" title="Index" rel="index">Index</a>]</p>
|
|---|
| 125 | </div>
|
|---|
| 126 |
|
|---|
| 127 |
|
|---|
| 128 |
|
|---|
| 129 | </body>
|
|---|
| 130 | </html>
|
|---|
