«

On Wed, 30 Jan 2013 14:44:44 -0600, Robert Wessel
<> wrote:

>On Wed, 30 Jan 2013 10:12:07 -0800, Keith Thompson <kst->
>wrote:
>
>>Robert Miles <> writes:

>Non-char, non-void pointers don't need to be able to address any byte
>in the data space, just each possible instance of whatever object
>they're pointing at. Which is why we've seen some word addressed
>machines with void/char pointers that are larger than other types of
>data pointers.
>
>Although one would assume that a 4-bit CPU is not going to have any
>significant alignment requirements.

even if the C languge say other
i think pointer is one unsigned number of fixed size
all that goes different from above produce errors or wrong programming
behaviours or difficult code to understand

what about use this notation:

p32u32 *a;
"a" is a pointer of 32 bit size, [one unsigned of 32 bit] that point
to one unsigned of 32 bits

p16u32 *a;
"a" is a pointer of 16 bit size, [one unsigned of 16 bit] that point
to one unsigned of 32 bits

p8i16 *a;
"a" is a pointer of 8 bit size, [one unsigned of 8 bit] that point
to one unsigned of 16 bits

p8i8 *a;
"a" is a pointer of 8 bit size, [one unsigned of 8 bit] that point
to one unsigned char

On Thu, 31 Jan 2013 10:04:42 +0100, Rosario1903
<> wrote:


>what about use this notation:
>
>p32u32 *a;
>"a" is a pointer of 32 bit size, [one unsigned of 32 bit] that point
>to one unsigned of 32 bits
>
>p16u32 *a;
>"a" is a pointer of 16 bit size, [one unsigned of 16 bit] that point
>to one unsigned of 32 bits
>
>p8i16 *a;
>"a" is a pointer of 8 bit size, [one unsigned of 8 bit] that point
>to one unsigned of 16 bits
^^^^^^^^^^^^^^^^^^^^^^^^

to one signed 16 bit

>p8i8 *a;
>"a" is a pointer of 8 bit size, [one unsigned of 8 bit] that point
>to one unsigned char
^^^^^^^^^^^^^^^

to one signed char

James Kuyper <> writes:

>> [snip]
>
> [5.2.4.1p1] does not even imply that there's even a single
> additional program that the implementation can translate and
> execute. The only guarantee it provides is for the "one
> program". As written, it's a completely useless requirement.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

An opinion shared by very few other people.

glen herrmannsfeldt <> writes:

>> [snip]
>
> C requires char to be at least 8 bits, but it can be more. All
> other types have to be multiples (including 1) of the size of
> char.
>
> That seems to prohibit a four bit type, which would be especially
> useful on a four bit processor.

There's no reason a conforming implementation couldn't provide its
own four-bit data types, including arrays of such data types. The
rule that all non-bitfield types must be multiples of 'char' in
width applies only to Standard-defined types, not to types provided
as part of extensions.

Tim Rentsch <> writes:

> glen herrmannsfeldt <> writes:
>
>>> [snip]
>>
>> C requires char to be at least 8 bits, but it can be more. All
>> other types have to be multiples (including 1) of the size of
>> char.
>>
>> That seems to prohibit a four bit type, which would be especially
>> useful on a four bit processor.
>
> There's no reason a conforming implementation couldn't provide its
> own four-bit data types, including arrays of such data types. The
> rule that all non-bitfield types must be multiples of 'char' in
> width applies only to Standard-defined types, not to types provided
> as part of extensions.

Do you mean 6.2.6.1 p2? I.e. this:

Except for bit-fields, objects are composed of contiguous sequences of
one or more bytes, the number, order, and encoding of which are either
explicitly specified or implementation-defined.

If so, how can a 4-bit object be exempt; or would the implementation
somehow avoid making these things objects?

--
Ben.

Tim Rentsch <> wrote:
> glen herrmannsfeldt <> writes:

>>> [snip]

>> C requires char to be at least 8 bits, but it can be more. All
>> other types have to be multiples (including 1) of the size of
>> char.

>> That seems to prohibit a four bit type, which would be especially
>> useful on a four bit processor.

> There's no reason a conforming implementation couldn't provide its
> own four-bit data types, including arrays of such data types. The
> rule that all non-bitfield types must be multiples of 'char' in
> width applies only to Standard-defined types, not to types provided
> as part of extensions.

OK, I agree. It does have the complication that

nybble *x;
x=malloc(100*sizeof(*x));

won't allocate 100 nybbles, unless sizeof works differently.
That again, maybe one would use only static allocation.

-- glen

Ben Bacarisse <> writes:

> Tim Rentsch <> writes:
>
>> glen herrmannsfeldt <> writes:
>>
>>>> [snip]
>>>
>>> C requires char to be at least 8 bits, but it can be more. All
>>> other types have to be multiples (including 1) of the size of
>>> char.
>>>
>>> That seems to prohibit a four bit type, which would be especially
>>> useful on a four bit processor.
>>
>> There's no reason a conforming implementation couldn't provide its
>> own four-bit data types, including arrays of such data types. The
>> rule that all non-bitfield types must be multiples of 'char' in
>> width applies only to Standard-defined types, not to types provided
>> as part of extensions.
>
> Do you mean 6.2.6.1 p2? I.e. this:
>
> Except for bit-fields, objects are composed of contiguous sequences of
> one or more bytes, the number, order, and encoding of which are either
> explicitly specified or implementation-defined.
>
> If so, how can a 4-bit object be exempt; or would the implementation
> somehow avoid making these things objects?

Surely this is an easy question to answer. If a variable having
a hitherto unknown datatype is stored in a region of memory, what
difference does it make whether we call that region of memory an
"object" or a "nobject"? The "objectness" of a region of memory
has no meaning except insofar as it implies properties for some
semantic entities defined in part with reference to the term.
As long as those entities have the specified properties, there's
no way of knowing what terminology the implementors use when
talking among themselves about the implementation; it doesn't
matter whether they call everything an object, or distinguish
between "objects" and "nobjects", etc.

glen herrmannsfeldt <> writes:

> Tim Rentsch <> wrote:
>> glen herrmannsfeldt <> writes:
>
>>>> [snip]
>
>>> C requires char to be at least 8 bits, but it can be more. All
>>> other types have to be multiples (including 1) of the size of
>>> char.
>>>
>>> That seems to prohibit a four bit type, which would be especially
>>> useful on a four bit processor.
>
>> There's no reason a conforming implementation couldn't provide its
>> own four-bit data types, including arrays of such data types. The
>> rule that all non-bitfield types must be multiples of 'char' in
>> width applies only to Standard-defined types, not to types provided
>> as part of extensions.
>
> OK, I agree. It does have the complication that
>
> nybble *x;
> x=malloc(100*sizeof(*x));
>
> won't allocate 100 nybbles, unless sizeof works differently.
> [snip]

The sizeof operator can be defined in a way that satisfies all
the Standard's requirements but still allows this example to
allocate only 100 nibbles. Because of what the Standard says
about malloc(), it has to allocate an integer multiple of (at
least) 8-bit locations, aligned on a boundary of the same width,
but neither of those is a problem if we want 100 nibbles.

"Tim Rentsch" <> wrote in message
news:...
> glen herrmannsfeldt <> writes:


>>> There's no reason a conforming implementation couldn't provide its
>>> own four-bit data types, including arrays of such data types. The
>>> rule that all non-bitfield types must be multiples of 'char' in
>>> width applies only to Standard-defined types, not to types provided
>>> as part of extensions.
>>
>> OK, I agree. It does have the complication that
>>
>> nybble *x;
>> x=malloc(100*sizeof(*x));
>>
>> won't allocate 100 nybbles, unless sizeof works differently.
>> [snip]
>
> The sizeof operator can be defined in a way that satisfies all
> the Standard's requirements but still allows this example to
> allocate only 100 nibbles.

So what would be the value of sizeof(*x)? It can only really be 1 or 0.

0 won't work, and 1 is wrong.

Some work to the language is needed to either allow 4-bit bytes, or to allow
a bitfield as an independent type, which can be used in arrays, and as the
the target of a pointer. Even then, such types will still need separate
handling, as sizeof() will still return units of a byte.

--
Bartc

"BartC" <> writes:

> "Tim Rentsch" <> wrote in message
> news:...
>> glen herrmannsfeldt <> writes:
>
>>>> There's no reason a conforming implementation couldn't provide its
>>>> own four-bit data types, including arrays of such data types. The
>>>> rule that all non-bitfield types must be multiples of 'char' in
>>>> width applies only to Standard-defined types, not to types provided
>>>> as part of extensions.
>>>
>>> OK, I agree. It does have the complication that
>>>
>>> nybble *x;
>>> x=malloc(100*sizeof(*x));
>>>
>>> won't allocate 100 nybbles, unless sizeof works differently.
>>> [snip]
>>
>> The sizeof operator can be defined in a way that satisfies all
>> the Standard's requirements but still allows this example to
>> allocate only 100 nibbles.
>
> So what would be the value of sizeof(*x)? It can only really
> be 1 or 0. [snip elaboration]

Actually that isn't right. Using 'sizeof' on a non-standard
datatype may behave in unexpected ways. Here's a hint: sizeof
yields a result of type size_t; size_t is an (unsigned) integer
type; integer types larger than character types may have padding
bits. Can you fill in the rest?