Nicola Musatti wrote:
> Scott Meyers wrote:
> > I just stumbled on 9.6's references to "allocation units," a term that
> > does not seem to be defined in the C++ standard or used in the C
> > standard.  For C++03, 9.6/1 says, in part:

> > > Bit-fields are packed into some addressable allocation
> > > unit. [Note: bit-fields straddle allocation units on some
> > > machines and not on others.]

> > It's not clear what being packed "into" an allocation unit means if
> > allocation unit boundaries may be straddled by a single bitfield.

> > 9.6/2 then says, in part:

> > > As a special case, an unnamed bit-field with a width of
> > > zero specifies alignment of the next bit-field at an
> > > allocation unit boundary.

> > So presumably given

> >    unsigned a : 1,
> >               : 0,
> >             b : 1;

> > b begins at a new "allocation unit." But I still don't have any
> > intuition for what an allocation unit is.  Can somebody explain this to me?

> I would guess that the term "allocation unit" indicates the underlying
> hardware's smallest addressable extent of memory, i.e. what used to be
> commonly referred to as "bytes", before the term was hijacked by the C
> and C++ standard to refer to an addressable portion of memory large
> enough to hold one character (and by the general public to refer to an
> octet).

The term wasn't so much hijacked; it's more a question of the
C/C++ standards committee saying that if your bytes aren't at
least 8 bits, you can't implement C or C++.  (Of course, the
original "bytes" were 6 bit, and the PDP-10 traditionally used 7
bit bytes, although the length was programmable.  The PDP-10
traditional case is interesting, in that some of the bits in a
word were not part of any byte---also forbidden by the C/C++
standards.)

The definition of byte has always been a bit vague---the
smallest addressable extent of memory on a VAX (and I think on a
PDP-10 as well) is 1 bit.  I don't think that's ever been called
a byte, however.

As for "allocation unit", I rather think it's more of a
Humpty-Dumpty word: it means whatever the implementor wants it
to mean.  At any rate, the compilers I use tend to make it
either 32 or 64 bits, although all of the machines I use can
address 8 bit entities.

> The two do not necessarily coincide as is exemplified by the Unisys
> architecture James Kanze often refers to which, if I'm not mistaken,
> has a 36 bit word that is divided in 6 bit "allocation units", but
> supports 9 bit characters.

The issue there is a bit different: the machine has word
addressing, and the allocation units are 36 bits.  You need
extra bits to extract a 9 bit byte from the word.  (I'm not sure
about the actual hardware, but the native protocols on the
machine used 7 bit bytes.  Before the days of C, of course.  Or
the Internet.)

--
James Kanze (Gabi Software)            email: james.kanze@gmail.com
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

I just stumbled on 9.6's references to "allocation units," a term that
does not seem to be defined in the C++ standard or used in the C
standard.  For C++03, 9.6/1 says, in part:

> Bit-fields are packed into some addressable allocation unit. [Note: bit-fields straddle allocation units on some machines and not on others.]

It's not clear what being packed "into" an allocation unit means if
allocation unit boundaries may be straddled by a single bitfield.

9.6/2 then says, in part:

> As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary.

So presumably given

   unsigned a : 1,
              : 0,
            b : 1;

b begins at a new "allocation unit." But I still don't have any
intuition for what an allocation unit is.  Can somebody explain this to me?

Thanks,

Scott



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Scott Meyers wrote:
> I just stumbled on 9.6's references to "allocation units," a term that
> does not seem to be defined in the C++ standard or used in the C
> standard.  For C++03, 9.6/1 says, in part:
>
> > Bit-fields are packed into some addressable allocation unit. [Note: bit-fields straddle allocation units on some machines and not on others.]
>
> It's not clear what being packed "into" an allocation unit means if
> allocation unit boundaries may be straddled by a single bitfield.
>
> 9.6/2 then says, in part:
>
> > As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary.
>
> So presumably given
>
>    unsigned a : 1,
>               : 0,
>             b : 1;
>
> b begins at a new "allocation unit." But I still don't have any
> intuition for what an allocation unit is.  Can somebody explain this to me?

I would guess that the term "allocation unit" indicates the underlying
hardware's smallest addressable extent of memory, i.e. what used to be
commonly referred to as "bytes", before the term was hijacked by the C
and C++ standard to refer to an addressable portion of memory large
enough to hold one character (and by the general public to refer to an
octet).

The two do not necessarily coincide as is exemplified by the Unisys
architecture James Kanze often refers to which, if I'm not mistaken,
has a 36 bit word that is divided in 6 bit "allocation units", but
supports 9 bit characters.

Cheers,
Nicola Musatti

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Mon, 30 Oct 2006 17:44:34 GMT, usenet@aristeia.com (Scott Meyers)
wrote in comp.std.c++:

> I just stumbled on 9.6's references to "allocation units," a term that
> does not seem to be defined in the C++ standard or used in the C
> standard.  For C++03, 9.6/1 says, in part:
>
> > Bit-fields are packed into some addressable allocation unit. [Note: bit-fields straddle allocation units on some machines and not on others.]
>
> It's not clear what being packed "into" an allocation unit means if
> allocation unit boundaries may be straddled by a single bitfield.
>
> 9.6/2 then says, in part:
>
> > As a special case, an unnamed bit-field with a width of zero specifies alignment of the next bit-field at an allocation unit boundary.
>
> So presumably given
>
>    unsigned a : 1,
>               : 0,
>             b : 1;
>
> b begins at a new "allocation unit." But I still don't have any
> intuition for what an allocation unit is.  Can somebody explain this to me?
>
> Thanks,
>
> Scott

Perhaps the wording of the C standard is a little clearer, here are
the first two sentences of 6.7.2.1 para 10:

"An implementation may allocate any addressable storage unit large
enough to hold a bit-field. If enough space remains, a bit-field that
immediately follows another bit-field in a structure shall be packed
into adjacent bits of the same unit. If insufficient space remains,
whether a bit-field that does not fit is put into the next unit or
overlaps adjacent units is implementation-defined."

Does the term "storage unit" sound better than "allocation unit"?

Basically, the implementation must make a choice of data type in which
to store a bit-field.  It may make that choice after it sees all of
the bit-field definitions.

It might decide to use an unsigned char for bit-fields containing less
than 8 total bits on a CHAR_BIT 8 platform.  But it might switch to
unsigned int, say 32 bits for example, for any bit-fields with more
than 8 bits.  In that example above, the bit-field member with width 0
would cause the bit-field to occupy an additional byte of memory.

Or it might always use 32 bit unsigned integers for storing
bit-fields.  In which case your sample code above will add another 32
bits, 4 bytes, to the total size of the bit field.

It is completely up to the compiler.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]