Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

[Oleg Endo <oleg dot endo at t-online dot de>]

On Tue, 2016-07-26 at 10:37 -0400, Warren D Smith wrote:

> Also, I know on some machines to access a byte you have to get a word
> (larger than 8 bits)
> from memory, do shifts and masks.  So clearly you already do that
> inside gcc.
> It therefore is trivial for you to do uint4_t also, because it would
> be that exact same code you already have, just change some numbers.

You should try to do that yourself once.  Get the GCC source code and
just "change some numbers here and there" and see how far it goes...
Build instructions can be found here: https://gcc.gnu.org/install/

What you are suggesting looks like a generic way of "doing bitfields",
essentially making every integer a bitfield and things like int8_t,
int16_t turn into exceptions that happen to align with what the
hardware implements?

So instead of ..

struct bleh
{
  int a : 6;
  int b : 3;
};

.. we get ...

struct bleh
{
  int6_t a;
  int3_t b;
};

and then sizeof (bleh) = ???

Surely, the compiler can be taught that kind of stuff, it's just a
question of effort.

Alternatively, you can implement an N-bit drop-in integer type in C++11
yourself with container specializations of std::array and std::vector
to get tightly packed e.g. int7_t (still with some padding bits).  This
will allow you to evaluate the usefulness and effectiveness of your
proposed extensions in some real-world applications as a start.

Cheers,
Oleg