size of a pointer on 4-bit system

[Rosario1903]

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

 

[Rosario1903]

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

 

[Tim Rentsch]

[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.

 

[Tim Rentsch]

[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.

 

[Ben Bacarisse]

[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?

 

[glen herrmannsfeldt]

[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

 

[Tim Rentsch]

[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.

 

[Tim Rentsch]

[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.

 

[BartC]

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.

 

[Tim Rentsch]

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?

 

[Ben Bacarisse]

[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.

I thought you were making a more interesting point than that almost
anything is allowed. The standard permits almost any extension so you
could, for example, have a list type. Such things would not be objects
which is good in that it means they are not constrained by what the
standard says about objects (their representation, lifetime, derived
types, access rules and so on) but it means you have simply grafted on a
new sub language and everything about that new language and the rest of
standard C must now be specified.

The same is true for 4-bit types. They are not prohibited but they
don't fit, so you have to specify almost everything about them.

 

[Tim Rentsch]

[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.

I thought you were making a more interesting point than that
almost anything is allowed. The standard permits almost any
extension so you could, for example, have a list type. Such
things would not be objects which is good in that it means they
are not constrained by what the standard says about objects
(their representation, lifetime, derived types, access rules and
so on) but it means you have simply grafted on a new sub language
and everything about that new language and the rest of standard C
must now be specified.

Any extension that introduces new data types has to specify their
semantics. What makes 4-bit types interesting is that they can
be defined in a way so as to be almost indistinguishable from
regular C integer types. It may take some doing to give those
specifications relative to the terminology used in the Standard,
but the resulting language looks so much like C that most people
would hardly know the difference.

The same is true for 4-bit types. They are not prohibited but
they don't fit, so you have to specify almost everything about
them.

This doesn't seem that hard to me. "The data type 'nibble' is a
4-bit value similar to standard C integer data types. A region
of memory that may provide storage for values of this type is
called a /nobject/. The rules for nobjects are the same as the
rules for objects in standard C except ... . The semantics of
operators of expressions having operands of type nibble are the
same as they are for standard C integer types, except ... . The
rules for types derived from type nibble are the same as the
rules for derived types in standard C, except ... ." And so
forth.

Granted, what the differences are between "nobjects" and "objects"
needs to be spelled out carefully and in detail. But mostly how
everything works for nibbles/nobjects is just the same as regular
C types and objects, and that part of the specification can be
done simply by referencing corresponding parts of the Standard,
along the lines of the example above.

 

[BartC]

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?

What, that extra information is stored in those padding bits? How is that
going to help?

What bit-pattern could be returned by sizeof(*x) that would make
100*sizeof(*x) yield 50 instead of 100?

 

[Shao Miller]

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

C does say otherwise. The representation of pointers is
implementation-defined.

"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."

Why do you believe that any representation other than an unsigned
integer would lead to errors, undesired program behaviour, or code
that's difficult to understand? What makes an unsigned integer
representation so special?

 

[Shao Miller]

What bit-pattern could be returned by sizeof(*x) that would make
100*sizeof(*x) yield 50 instead of 100?

The 'sizeof' operator only requires parentheses when used with a
type-name. Your example clearly does not use a type-name, so it could
be: 100 * sizeof *x

 

[BartC]

The 'sizeof' operator only requires parentheses when used with a
type-name. Your example clearly does not use a type-name, so it could be:
100 * sizeof *x

<Completely confused...>

 

[Shao Miller]

<Completely confused...>

'sizeof' is an operator (like '+'), not a function. It has two forms:

sizeof (type-name)
sizeof unary-expression

You might enjoy the "sizeof and malloc" article at:

http://www.iso-9899.info/wiki/Code_snippets

 

[glen herrmannsfeldt]

On 2/1/2013 05:41, BartC wrote:

The 'sizeof' operator only requires parentheses when used with a
type-name. Your example clearly does not use a type-name, so it could
be: 100 * sizeof *x

Yes, but I usually put them in anyway. Sometimes I use a type,
other times not, and as usual, with the () I don't have to
worry about precedence.

How about sizeof(2**x) vs. (sizeof 2 * * x)?

-- glen

 

[Shao Miller]

How about sizeof(2**x) vs. (sizeof 2 * * x)?

I'm so conditioned to C that I don't see the difference, but I can
imagine some language that has '**' as an exponent operator...?

 

[Shao Miller]

I'm so conditioned to C that I don't see the difference, but I can
imagine some language that has '**' as an exponent operator...?

Ooh, heheh. I missed your point of the parentheses. My mistake. Don't
do that!