Re: Size changes, round 1

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    Instinctively, I feel like this is headed in the wrong direction.  I
    would rather see us have only one notion of size (either number of
    bits or number of bytes) and use it consistently rather than having to
    drag around a scaling factor everywhere.

Recall that I did try to start a discussion on this topic.  I originally felt
as you did, but I became convinced, mostly by the brief discussion we did
get, that it was probably worth having the two different sizes.

    I understand that there are problems with using bits everywhere in
    that then, say, using a 32-bit word for sizes yields only sizes up to
    2^29.

Right.  This has been a problem in some real code, but I was also told that a
motivation for using byte sizes was 16 bit machines.

    I'd be inclined to use byte-sized types everywhere -- C, C++, and
    Java, at least, don't have bit-sized types.

As I understand it, Chill does, though.  Ada does too, but this gets totally
hidden in the front end.

    (Bitfields are not a separate type.  The type of the field is still
    `int', or whatever; it is the declaration for the bitfield that
    carries the width.)  

Right, but the FIELD_DECL has a size that isn't a multiple of bytes.  And
then you have the issue fo the bit position, which can't count bytes.

    (BTW, the cc1plus memory footprint is directly correlated to the size
    of DECLs -- they acount for about 24% of memory usage on some of the
    larger test-cases I've run.  Therefore, an extra word there is not
    insignificant -- I'd guess that's about a 0.5% memory bump.  Not a
    really big deal, but not totally invisible either.)

Unfortunately, I think one more field might be needed in round two for
bitfield positions: we need them in both bits and bytes: otherwise positions
in records containign variable-sized types (common in Ada) get computed in a
needlessly wide type.