Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > size of a pointer on 4-bit system

Reply
Thread Tools

size of a pointer on 4-bit system

 
 
Rosario1903
Guest
Posts: n/a
 
      01-31-2013
On Wed, 30 Jan 2013 14:44:44 -0600, Robert Wessel
<(E-Mail Removed)> wrote:

>On Wed, 30 Jan 2013 10:12:07 -0800, Keith Thompson <(E-Mail Removed)>
>wrote:
>
>>Robert Miles <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
 
Rosario1903
Guest
Posts: n/a
 
      01-31-2013
On Thu, 31 Jan 2013 10:04:42 +0100, Rosario1903
<(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      01-31-2013
James Kuyper <(E-Mail Removed)> 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.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      01-31-2013
glen herrmannsfeldt <(E-Mail Removed)> 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-31-2013
Tim Rentsch <(E-Mail Removed)> writes:

> glen herrmannsfeldt <(E-Mail Removed)> 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.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      02-01-2013
Tim Rentsch <(E-Mail Removed)> wrote:
> glen herrmannsfeldt <(E-Mail Removed)> 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
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-01-2013
Ben Bacarisse <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>
>> glen herrmannsfeldt <(E-Mail Removed)> 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.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-01-2013
glen herrmannsfeldt <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> wrote:
>> glen herrmannsfeldt <(E-Mail Removed)> 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.
 
Reply With Quote
 
BartC
Guest
Posts: n/a
 
      02-01-2013
"Tim Rentsch" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> glen herrmannsfeldt <(E-Mail Removed)> 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

 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      02-01-2013
"BartC" <(E-Mail Removed)> writes:

> "Tim Rentsch" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>> glen herrmannsfeldt <(E-Mail Removed)> 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?
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
pointer to an array vs pointer to pointer subramanian100in@yahoo.com, India C Programming 5 09-23-2011 10:28 AM
Pointer to pointer or reference to pointer A C++ 7 07-05-2011 07:49 PM
Pointer to pointer Vs References to Pointer bansalvikrant@gmail.com C++ 4 07-02-2009 10:20 AM
passing the address of a pointer to a func that doesnt recieve a pointer-to-a-pointer jimjim C Programming 16 03-27-2006 11:03 PM
Pointer-to-pointer-to-pointer question masood.iqbal@lycos.com C Programming 10 02-04-2005 02:57 AM



Advertisments