union with packed struct

packed structures means to put the next one emmediately following the first
one, instead of on 64 bit boundaries.

You should note that structs, unions, and classess are designed to help the
programmer not the computer. You will find that aligning your data within
each Struct to 64 bit boundaries allows you a few more machine cycles than
all the tidbitley wringing done to code to "optimize" it.

Keep in mind that a struct is just an int[], with mapping handles for the
"Programmer".

I hope you gain something from this.

"ccwork" <cc****@hotmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Hi,
How about assign "color.color_u.color_bit.red" to something other
than 0 and 1? Say color.color_u.color_bit.red=20. What will happen?
How about assign color.color_u.color_bit.red=(some expression) &&
(another expression)?

Actually all these are code from a senior engineer and I am helping
him...

Eric Sosman wrote:
ccwork wrote:
> Hi all,
> Here is a sample code segment:
> ...
> typedef PACKED struct

What is `PACKED'? It isn't a C construct -- it looks
like it's probably a #defined macro that expands to (one
would guess) some kind of implementation-specific extension
to C like `__attribute__((packed))'. If so, you'll need to
consult your implementation's documentation to find out
what's going on, because it isn't C.

Well, it *could* be C, if `PACKED' expands to something
like `volatile' or `const' or nothing at all. In what
follows, I'll assume that's the case.
> {
> union
> {
> PACKED struct
> {
> char red:1;
> char green:1;
> char blue:1;
> } color_bit;
> char color;
> } color_u;
> } color_t;
>
> color_t color;
> ...
> My question is: which bit in "color.color_u.color" reflect
> "color.color_u.color_bit.red", "color.color_u.color_bit.green" and
> "color.color_u.color_bit.blue"? Is this well defined?

Not by the C language. The compiler has great freedom
in how it chooses to arrange bit-fields within a struct.
Different compilers will arrange things differently.
> In other words, if I set "color.color_u.color_bit.red" as 0,
> "color.color_u.color_bit.green" as 0 and "color.color_u.color_bit.blue" > as 1, What will be "color.color_u.color"? is it 0x04?

Not necessarily. In fact, it's not guaranteed that
`color.color_u.color' will have a valid value at all: unions
are frequently (ab)used for this sort of type punning, but
the language doesn't promise that anything reasonable will
happen if you try it.

If you want to represent a color as three bits in a
`char', you're better off using bitwise operators with
pre-#defined (or enum-erated) masks:

typedef unsigned char color_t;
#define COLOR_RED 1
#define COLOR_GREEN 2
#define COLOR_BLUE 4
#define COLOR_YELLOW (COLOR_GREEN | COLOR_RED)
...

--
Eric Sosman
es*****@acm-dot-org.invalid

Nov 14 '05 #5

On Mon, 7 Mar 2005 23:37:20 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:

packed structures means to put the next one emmediately following the first
one, instead of on 64 bit boundaries.
Note that there's no requirement from the C Standard for data to be aligned
on 64-bit boundaries. This woudn't make much sense on a 36-bit machine.
Keep in mind that a struct is just an int[], with mapping handles for the
"Programmer".

Nonsense.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Nov 14 '05 #6

ccwork

Mark McIntyre wrote:

On Mon, 7 Mar 2005 23:37:20 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:
packed structures means to put the next one emmediately following the firstone, instead of on 64 bit boundaries.
Note that there's no requirement from the C Standard for data to be

aligned on 64-bit boundaries. This woudn't make much sense on a 36-bit machine.
Keep in mind that a struct is just an int[], with mapping handles for the"Programmer".
Nonsense.

Can you elaborate this further?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption

=----

Nov 14 '05 #7

I'm kind of wondering what you think is nonsense about it.
While it is true that the actual boundary, and size is dependent on the HW.
The idea is still the same.

And I'm afraid that what you call "nonsense", is actually refered to as a
FLAT MEMORY MODEL.

That means that 20 bytes is 20 bytes. it means that all of the memory on
your system is in the form of :
int[MEMORY_SIZE]
With int, being the size of the register Accessing memory, The actual # of
bits read in. I dont how else to describe it to you.

But
struct _tegname{
char some_of_ this_nonsense;
int * Some_of_that_nonsense;
short Some_mmore_Nonsense;
....
}, NONSENSE;

is stored in that FLAT MEMORY MODEL.
ie: int[];

"ccwork" <cc****@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

Mark McIntyre wrote:
On Mon, 7 Mar 2005 23:37:20 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:
>packed structures means to put the next one emmediately following the first >one, instead of on 64 bit boundaries.

Note that there's no requirement from the C Standard for data to be

aligned
on 64-bit boundaries. This woudn't make much sense on a 36-bit

machine.
>Keep in mind that a struct is just an int[], with mapping handles for the >"Programmer".

Nonsense.

Can you elaborate this further?
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet

News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World!

120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption

=----

Nov 14 '05 #8

In article <tDvXd.1029$Qz.700@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:And I'm afraid that what you call "nonsense", is actually refered to as a
:FLAT MEMORY MODEL.

What you are calling a "flat memory model" is one -particular- flat memory
model, which does not hold true on all flat memory systems.
:That means that 20 bytes is 20 bytes. it means that all of the memory on
:your system is in the form of :
:int[MEMORY_SIZE]
:With int, being the size of the register Accessing memory, The actual # of
:bits read in. I dont how else to describe it to you.

So then, how do you explain the Honeywell L66 architecture, which
could store 6 characters per word, 36 bits per word, and had 9 bit bytes?

You are assuming that all memory is alignable in "int" chunks. That
isn't true on all architectures: on some architectures (e.g., the L66),
you need to use different instructions to get at different data types.
Some architectures store 80 bits per double, and can put doubles
back to back, and yet for normal operations require that int be aligned
on 32 bit boundaries.

:But
:struct _tegname{
: char some_of_ this_nonsense;
: int * Some_of_that_nonsense;
: short Some_mmore_Nonsense;
:...
:}, NONSENSE;

:is stored in that FLAT MEMORY MODEL.
:ie: int[];

Some architectures have pointers which are not the size of int (or
long) and which can be aligned on different boundaries than int.

For example, the representation of two of the above in memory
could have this byte layout:

0 : some_of_this_nonsense character 0 = int 0 byte 0
1 : unused padding = int 0 byte 1
2 : Some_of_that_nonsense byte 0 = int 0 byte 2
3 : Some_of_that_nonsense byte 1 = int 0 byte 3
4 : Some_of_that_nonsense byte 2 = int 1 byte 0
5 : Some_of_that_nonsense byte 3 = int 1 byte 1
6 : Some_of_that_nonsense byte 4 = int 1 byte 2
7 : Some_of_that_nonsense byte 5 = int 1 byte 3
8 : Some_mmore_Nonsense byte 0 = int 2 byte 0
9 : Some_mmore_Nonsense byte 1 = int 2 byte 1

A : some_of_this_nonsense2 character 0 = int 2 byte 2
B : unused padding = int 2 byte 3
C : Some_of_that_nonsense2 byte 0 = int 3 byte 0
D : Some_of_that_nonsense2 byte 1 = int 3 byte 1
E : Some_of_that_nonsense2 byte 2 = int 3 byte 2
F : Some_of_that_nonsense2 byte 3 = int 3 byte 3
10: Some_of_that_nonsense2 byte 4 = int 4 byte 0
11: Some_of_that_nonsense2 byte 5 = int 4 byte 1
12: Some_mmore_Nonsense2 byte 0 = int 4 byte 2
13: Some_mmore_Nonsense2 byte 1 = int 4 byte 3

The architecture could have instructions able to load characters
from arbitrary bytes, to load 6 byte pointers from 2 byte boundaries,
to load 2 byte shorts from 2 byte boundaries, and yet might not
have any instruction to load int from 2 byte boundaries, only
from 4 byte boundaries. In such an architecture, the structure
is not representable as an array of int -- not without having
the array of int include data that belongs to another object!
If you examine the alignment rules of the Standard, you will
see that basically there -aren't- any alignment rules in
the Standard, other than that malloc() shall return a pointer
which satisfies the alignment rules for all primitive data types.
sizeof(short) <= sizeof(int) <= sizeof(long)
but that doesn't tell us anything about how short, int, or long
must be aligned in memory. Converting a short into an int
is not necessarily just a matter of moving 0 into the int
and then MOV.S the short into the "bottom short" of the int:
it is perfectly acceptable for the achitecture to use
a complete different set of registers for working with
shorts and int, with an explicit "extend short to int"
instruction instruction. (And yes, I really have seen
architectures with "extend short to int" instructions --
and no, they weren't synonyms for "sign extend short to
int".)
--
Warning: potentially contains traces of nuts.

Nov 14 '05 #9

I'm sorry, when you show me a computer with contiguous ram, that has more
than one memory location for any one given address then you'll have an
argument.

Call it what you want :
somesize[];
MyCompsRegWidth[];
MyRamsWordSize[];

There is a level of comprehension and understanding that I wrongfully
assumed that every english typing programmer had.

and yes : int[], char[], word[], WhatHaveYa[];

is all the same in HW.

STRUCTS are there for the programmer, not the computer!

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...

In article <tDvXd.1029$Qz.700@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:And I'm afraid that what you call "nonsense", is actually refered to as a
:FLAT MEMORY MODEL.

What you are calling a "flat memory model" is one -particular- flat memory
model, which does not hold true on all flat memory systems.
:That means that 20 bytes is 20 bytes. it means that all of the memory on
:your system is in the form of :
:int[MEMORY_SIZE]
:With int, being the size of the register Accessing memory, The actual #
of
:bits read in. I dont how else to describe it to you.

So then, how do you explain the Honeywell L66 architecture, which
could store 6 characters per word, 36 bits per word, and had 9 bit bytes?

You are assuming that all memory is alignable in "int" chunks. That
isn't true on all architectures: on some architectures (e.g., the L66),
you need to use different instructions to get at different data types.
Some architectures store 80 bits per double, and can put doubles
back to back, and yet for normal operations require that int be aligned
on 32 bit boundaries.

:But
:struct _tegname{
: char some_of_ this_nonsense;
: int * Some_of_that_nonsense;
: short Some_mmore_Nonsense;
:...
:}, NONSENSE;

:is stored in that FLAT MEMORY MODEL.
:ie: int[];

Some architectures have pointers which are not the size of int (or
long) and which can be aligned on different boundaries than int.

For example, the representation of two of the above in memory
could have this byte layout:

0 : some_of_this_nonsense character 0 = int 0 byte 0
1 : unused padding = int 0 byte 1
2 : Some_of_that_nonsense byte 0 = int 0 byte 2
3 : Some_of_that_nonsense byte 1 = int 0 byte 3
4 : Some_of_that_nonsense byte 2 = int 1 byte 0
5 : Some_of_that_nonsense byte 3 = int 1 byte 1
6 : Some_of_that_nonsense byte 4 = int 1 byte 2
7 : Some_of_that_nonsense byte 5 = int 1 byte 3
8 : Some_mmore_Nonsense byte 0 = int 2 byte 0
9 : Some_mmore_Nonsense byte 1 = int 2 byte 1

A : some_of_this_nonsense2 character 0 = int 2 byte 2
B : unused padding = int 2 byte 3
C : Some_of_that_nonsense2 byte 0 = int 3 byte 0
D : Some_of_that_nonsense2 byte 1 = int 3 byte 1
E : Some_of_that_nonsense2 byte 2 = int 3 byte 2
F : Some_of_that_nonsense2 byte 3 = int 3 byte 3
10: Some_of_that_nonsense2 byte 4 = int 4 byte 0
11: Some_of_that_nonsense2 byte 5 = int 4 byte 1
12: Some_mmore_Nonsense2 byte 0 = int 4 byte 2
13: Some_mmore_Nonsense2 byte 1 = int 4 byte 3

The architecture could have instructions able to load characters
from arbitrary bytes, to load 6 byte pointers from 2 byte boundaries,
to load 2 byte shorts from 2 byte boundaries, and yet might not
have any instruction to load int from 2 byte boundaries, only
from 4 byte boundaries. In such an architecture, the structure
is not representable as an array of int -- not without having
the array of int include data that belongs to another object!
If you examine the alignment rules of the Standard, you will
see that basically there -aren't- any alignment rules in
the Standard, other than that malloc() shall return a pointer
which satisfies the alignment rules for all primitive data types.
sizeof(short) <= sizeof(int) <= sizeof(long)
but that doesn't tell us anything about how short, int, or long
must be aligned in memory. Converting a short into an int
is not necessarily just a matter of moving 0 into the int
and then MOV.S the short into the "bottom short" of the int:
it is perfectly acceptable for the achitecture to use
a complete different set of registers for working with
shorts and int, with an explicit "extend short to int"
instruction instruction. (And yes, I really have seen
architectures with "extend short to int" instructions --
and no, they weren't synonyms for "sign extend short to
int".)
--
Warning: potentially contains traces of nuts.

Nov 14 '05 #10

In article <RkxXd.1045$Qz.218@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:I'm sorry, when you show me a computer with contiguous ram, that has more
:than one memory location for any one given address then you'll have an
:argument.

There are several systems around for which the smallest addressible
unit is the "word", and there are special instructions necessary
to extract characters within words. For some of those, a character
can start at an arbitrary bit position within the word!

On bitslice architectures, bit-wise packing of structures is
possible -- e.g., if you had

typedef struct { unsigned int i:3, char c, int j } s3cj;
s3cj A[2];

then the compiler might choose to lay A out in memory as (bitwise)

iiiccccccccjjjjjjjjjjjjjjjjjjjjj
jjjjjjjjjjjiiiccccccccjjjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjj
0123456789ABCDEF0123456789ABCDEF

Clearly on such an architecture, the offset to j is not
a multiple of a byte/word/int/long .

:and yes : int[], char[], word[], WhatHaveYa[];
:is all the same in HW.

Wrong. There has perhaps been an equivilence on all the architectures
you have worked on, but you have to remember that C is defined in such
a way as to be implimentable on oddities such as 1's compliment
machines and embedded microprocessors.

It isn't uncommon on RISC machines for the actual memory size read or
written for each access to main memory to be fairly large -- an entire
"cache line" at a time, where a cache might be (e.g.) 64 bytes. On
such systems, the smallest individually addressible unit may be the 32
bit or 64 bit long, with there being extra instructions needed to
access smaller units.

As far as the C standard is concerned, there is no problem if, instead
of the memory being a stream of individually addressible bytes, there
are addressing modes that take a base address and an index and access
or store at the appropriate location; e.g., MOV.S A3(D6),D0 could
perform an index operation into memory, taking the D6'th short from the
begining of A3, even though that might not fall onto a directly
addressible boundary.

If you re-examine what you are allowed to do with pointers, you will
find that you are not allowed to compare pointers to different
objects [even of the same type], and that casting a pointer to
anything other than a "compatible" type is not certain to be
meaningful. Converting a pointer to (void *) and back again
is constrained to compare equal to the original, but it is
legal for different pointer types to be different sizes
and to hold different internal information.
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

Nov 14 '05 #11

You can slice it by the bit, you can slice it by GiG.

There is still only one address per Location!

I have used microproccessors with RISC, with nonrisc, even some with a
PRogrammable micro code.

And on every Computer, microproccessor, digital circuit, there is still only
one location for the specified address, I dont care how big or small a chunk
you look at. Or on what HW you look at.

The computer will not change it's abilities to read what the Memory bus can
put out between members in a struct.
There is NO physical conection.

You act like your bits can't possibly be what the HW was designed to
manipulate.

Why would you build a 32 bit data bus and say that reading 4 chunks of 8
bits each were any faster than reading the whole 32.
would reading 32 chunks of 1 bit, be even faster?

IT doesn't matter, in memory, the BITS are stored in contiguous groups.

For example the 486 uses 32 bit registers, the actual indexing is done 8
bits per address. However reading 4 chars is slower than 1 dword.
Becuase you read 32 bits for each char read. FACT!

even on your micropro with bitslicing architecture, lets say you have 16
bits of data bus, but you only want to use 4 bits. OK you can, ITs still in
the middle of one huge array of integers. FACT! It's still contiguous.

And every time you access those 4 bits they are in the same Physical
location as before.

I think you may have confused what I was saying with how I was saying it.

Do you think we should optimize code that only utilized 1/8 of the register,
or 1/4 of the data bus, whats the point.
You have to get the code to run twice as fast to make up for only using 1/2
the registers, 1/2 data bus, etc.
Thats always going to be true. And that is my point.

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...

In article <RkxXd.1045$Qz.218@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:I'm sorry, when you show me a computer with contiguous ram, that has more
:than one memory location for any one given address then you'll have an
:argument.

There are several systems around for which the smallest addressible
unit is the "word", and there are special instructions necessary
to extract characters within words. For some of those, a character
can start at an arbitrary bit position within the word!

On bitslice architectures, bit-wise packing of structures is
possible -- e.g., if you had

typedef struct { unsigned int i:3, char c, int j } s3cj;
s3cj A[2];

then the compiler might choose to lay A out in memory as (bitwise)

iiiccccccccjjjjjjjjjjjjjjjjjjjjj
jjjjjjjjjjjiiiccccccccjjjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjj
0123456789ABCDEF0123456789ABCDEF

Clearly on such an architecture, the offset to j is not
a multiple of a byte/word/int/long .

:and yes : int[], char[], word[], WhatHaveYa[];
:is all the same in HW.

Wrong. There has perhaps been an equivilence on all the architectures
you have worked on, but you have to remember that C is defined in such
a way as to be implimentable on oddities such as 1's compliment
machines and embedded microprocessors.

It isn't uncommon on RISC machines for the actual memory size read or
written for each access to main memory to be fairly large -- an entire
"cache line" at a time, where a cache might be (e.g.) 64 bytes. On
such systems, the smallest individually addressible unit may be the 32
bit or 64 bit long, with there being extra instructions needed to
access smaller units.

As far as the C standard is concerned, there is no problem if, instead
of the memory being a stream of individually addressible bytes, there
are addressing modes that take a base address and an index and access
or store at the appropriate location; e.g., MOV.S A3(D6),D0 could
perform an index operation into memory, taking the D6'th short from the
begining of A3, even though that might not fall onto a directly
addressible boundary.

If you re-examine what you are allowed to do with pointers, you will
find that you are not allowed to compare pointers to different
objects [even of the same type], and that casting a pointer to
anything other than a "compatible" type is not certain to be
meaningful. Converting a pointer to (void *) and back again
is constrained to compare equal to the original, but it is
legal for different pointer types to be different sizes
and to hold different internal information.
--
"[...] it's all part of one's right to be publicly stupid." -- Dave Smey

Nov 14 '05 #12

ccwork

Hi,
for the struct:

struct S
{
char a;
char b;
char c;
} s;

According to your meaning that struct is int [], this mean:
1) ((int *)&s)[0] = s.a
2) ((int *)&s)[1] = s.b
3) ((int *)&s)[2] = s.c
Most likely this is wrong if sizeof(char) < sizeof(int). Walter
Roberson gave a very good example of bitslice architecture that
addressess of individual member of a struct can be ANY, not necessarily
multiple of char/short/int/long.

DHOLLINGSWORTH2 wrote:

You can slice it by the bit, you can slice it by GiG.

There is still only one address per Location!

I have used microproccessors with RISC, with nonrisc, even some with a PRogrammable micro code.

And on every Computer, microproccessor, digital circuit, there is still only one location for the specified address, I dont care how big or small a chunk you look at. Or on what HW you look at.

The computer will not change it's abilities to read what the Memory bus can put out between members in a struct.
There is NO physical conection.

You act like your bits can't possibly be what the HW was designed to
manipulate.

Why would you build a 32 bit data bus and say that reading 4 chunks of 8 bits each were any faster than reading the whole 32.
would reading 32 chunks of 1 bit, be even faster?

IT doesn't matter, in memory, the BITS are stored in contiguous groups.
For example the 486 uses 32 bit registers, the actual indexing is done 8 bits per address. However reading 4 chars is slower than 1 dword.
Becuase you read 32 bits for each char read. FACT!

even on your micropro with bitslicing architecture, lets say you have 16 bits of data bus, but you only want to use 4 bits. OK you can, ITs still in the middle of one huge array of integers. FACT! It's still contiguous.
And every time you access those 4 bits they are in the same Physical
location as before.

I think you may have confused what I was saying with how I was saying it.
Do you think we should optimize code that only utilized 1/8 of the register, or 1/4 of the data bus, whats the point.
You have to get the code to run twice as fast to make up for only using 1/2 the registers, 1/2 data bus, etc.
Thats always going to be true. And that is my point.

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...
In article <RkxXd.1045$Qz.218@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:I'm sorry, when you show me a computer with contiguous ram, that has more :than one memory location for any one given address then you'll have an :argument.

There are several systems around for which the smallest addressible
unit is the "word", and there are special instructions necessary
to extract characters within words. For some of those, a character
can start at an arbitrary bit position within the word!

On bitslice architectures, bit-wise packing of structures is
possible -- e.g., if you had

typedef struct { unsigned int i:3, char c, int j } s3cj;
s3cj A[2];

then the compiler might choose to lay A out in memory as (bitwise)

iiiccccccccjjjjjjjjjjjjjjjjjjjjj
jjjjjjjjjjjiiiccccccccjjjjjjjjj
jjjjjjjjjjjjjjjjjjjjjjj
0123456789ABCDEF0123456789ABCDEF

Clearly on such an architecture, the offset to j is not
a multiple of a byte/word/int/long .

:and yes : int[], char[], word[], WhatHaveYa[];
:is all the same in HW.

Wrong. There has perhaps been an equivilence on all the architectures you have worked on, but you have to remember that C is defined in such a way as to be implimentable on oddities such as 1's compliment
machines and embedded microprocessors.

It isn't uncommon on RISC machines for the actual memory size read or written for each access to main memory to be fairly large -- an entire "cache line" at a time, where a cache might be (e.g.) 64 bytes. On
such systems, the smallest individually addressible unit may be the 32 bit or 64 bit long, with there being extra instructions needed to
access smaller units.

As far as the C standard is concerned, there is no problem if, instead of the memory being a stream of individually addressible bytes, there are addressing modes that take a base address and an index and access or store at the appropriate location; e.g., MOV.S A3(D6),D0 could
perform an index operation into memory, taking the D6'th short from the begining of A3, even though that might not fall onto a directly
addressible boundary.

If you re-examine what you are allowed to do with pointers, you will find that you are not allowed to compare pointers to different
objects [even of the same type], and that casting a pointer to
anything other than a "compatible" type is not certain to be
meaningful. Converting a pointer to (void *) and back again
is constrained to compare equal to the original, but it is
legal for different pointer types to be different sizes
and to hold different internal information.
--
"[...] it's all part of one's right to be publicly stupid." --

Dave Smey

Nov 14 '05 #13

Walter Roberson wrote:

In article <RkxXd.1045$Qz.218@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
<large snip>

If you re-examine what you are allowed to do with pointers, you will
find that you are not allowed to compare pointers to different
objects [even of the same type],

Incorrect:

6.5.9 Equality operators

[...]

6 Two pointers compare equal if and only if both are
null pointers, both are pointers to the same object
(including a pointer to an object and a subobject
at its beginning) or function, both are pointers to
one past the last element of the same array object,
or one is a pointer to one past the end of one array
object and the other is a pointer to the start of a
different array object that happens to immediately
follow the first array object in the address space.

Mark F. Haigh
mf*****@sbcglobal.net

Nov 14 '05 #14

no,

what I mean is that

char * s ="Some text in ram!";

the text "Some text in ram!" is actually stored in ram.
in contiguous chunks.

you could say char s[]; represents an area in ram at s,

I'M Saying that all of your ram can be looked at like
int []; instead of some char [], some word[]; etc.

When you store the data in a form the Hardware naturally proccessess you are
going to save more clock cycles than you will pull out optimizing your code
by hand.

Simple put, Streamlining your code, does more for you than optimizing. When
you use data structures that are not in anyway equivelant to the native
operation of your HW.

char s[] = "Some text in Ram";

as an int[]; is the same exact pattern in memory;

as a programmer you would have to unpack the integer to get the individual
char values. when you use char []; the packing, and unpacking is done
"behind the scene".

Lets say you have a struct :

struct myStruct {
short x;
short y;
short z;
} coord;

accessing coord.x means you are loading an intire register with int, and
croping it to obtain the short portion.

in effect, incrementing x, y, z means you have loaded at least one of these
twice, once you through it out, and the second time, you through the rest
out.

on a 64 bit machine, Which reads and writes 64 bits at a time, you would
read in each value, 16 bits, once, and get the other 48 bits with it, crop
it ( unpack) , increment it, add the 48 bits back in,( pack it ), then save
it back to ram.

you could read all 3 shorts at once by alligning your structure on a 64 bit
boundary, and inc each one in one clock cycle, and similarly in one write
cycle store all three values back.
or
(this was my original statement)
you can redifine mystruct
struct mystruct {
int x;
int y;
int z,
} coord;

now since the x, y, and z values match the register width, the Databus
width, you don't have to ( unpack) or (pack) anything,

of the three methods here,

the first one really helps the programmer, and saves space, at the expense
of clock cycles,

the second method saves space, and saves clock cycles at the expense of the
programmer,

while the third method uses more space, but huals ass, and takes just as
much time to code as the 1st method.

I'm not going to suggest not using char, You would have to write a sh__ load
of string proccessing code, ( "already been done").
But you can logically order the information, and resize some information to
give you the best of all 3 methods.

I hope this clears up what I was trying to say the first post.

I thought everyone could follow it ok. I was wrong.

IF( I_hurt_anyones_feeling)
{
my_Oppologies();
}
else O_FN_WELL;

Later,

Dan

Nov 14 '05 #15

Richard Bos

"Mark F. Haigh" <mf*****@sbcglobal.net> wrote:

Walter Roberson wrote:
If you re-examine what you are allowed to do with pointers, you will
find that you are not allowed to compare pointers to different
objects [even of the same type],
Incorrect:

6.5.9 Equality operators

6 Two pointers compare equal if and only if

Equal, yes. You're allowed to compare pointers for equality. This is
simply done even in segmented or type-separated memory by noting that
two non-null pointers of different type need never compare equal at all:
they point to different kinds of objects, therefore not to the same
object; they are by definition not null; and if types are separated, an
array of one type never follows an array of another type.
If memory really were a gigantic array of ints, as DHOLLINGSWORTH2 seems
to think, then you would be able to do a lot more. You could, for
example, compare random pointers for order. That may be possible on many
common systems, but the Standard doesn't guarantee it.

Richard

Nov 14 '05 #16

----- Original Message -----
From: "Richard Bos" <rl*@hoekstra-uitgeverij.nl>
Newsgroups: comp.lang.c
Sent: Wednesday, March 09, 2005 4:01 AM
Subject: Re: union with packed struct

If memory really were a gigantic array of ints, as DHOLLINGSWORTH2 seems
to think, then you would be able to do a lot more. You could, for
if it wern't youd be wondering what a pointer is for. How to clear up the
ambiguity and what not.

if it weren't you would not be able to this:

char * text = "Some bs text to prove a DA point";
char text2[32];

int * pitext = text;
int * pitext2 = text2;

for( int i = 0; i < (32/ sizeof( int)); i++)
{
pitext2[i] = pitext[i];
}

// which copies from one string to the next
// by int's instead of by chars
// 4 times faster on 32 bit machine,
// and 8 times faster on a 64 bit machine

MEM is also just an array of bits;
also just an array of bytes;
also just an array of short's;
but where the i86 architecture is concerned
it's most like an array of int's.

I haven't seen a compiler one that shows any difference to that FACT.

common systems, but the Standard doesn't guarantee it.

I'll give you that, my specialty is doing all the Dirty NON-STANDARD work
you think can't get done.

Nov 14 '05 #17

DHOLLINGSWORTH2 wrote:

You can slice it by the bit, you can slice it by GiG.

There is still only one address per Location!
'Address' is not so easily defined. There may be 10,000 processes
running on a box, each with 10,000 different ideas of what exists at
virtual address 0x1234.

Further, a pointer with the integer value of 42 may mean the 42nd byte
of memory, the 42nd word, or the 42,000th quadword. It all depends on
the type of the pointer.

What we are concerned with here is the meaning the C standard gives to
'address', and what is guaranteed, no matter what the platform
involved.

I have used microproccessors with RISC, with nonrisc, even some with a PRogrammable micro code.

And on every Computer, microproccessor, digital circuit, there is still only one location for the specified address, I dont care how big or small a chunk you look at. Or on what HW you look at.

Whoopdee doo. You're talking to people here that deal with and develop
for these systems daily.
The computer will not change it's abilities to read what the Memory bus can put out between members in a struct.
There is NO physical conection.

You act like your bits can't possibly be what the HW was designed to
manipulate.

Why would you build a 32 bit data bus and say that reading 4 chunks of 8 bits each were any faster than reading the whole 32.
would reading 32 chunks of 1 bit, be even faster?

You clearly don't understand what you're talking about. Who said
anything about a 32 bit data bus? It could be a 1 bit data bus for all
you know.

IT doesn't matter, in memory, the BITS are stored in contiguous groups.
That's not even partially correct. There may be all kinds of holes in
a physical or virtual memory map. The 'next' bit may be on your local
DIMM 0 or in an undisclosed location across the Pacific in Kaz Khyleku
and Dan Pop's underground lair of doom. So no, bits are not always
stored contiguously, be it physically, virtually, or logically.

Additionally, objects themselves can contain 'padding' bits, whose
values are unspecified:

6.2.6.2 Integer types

1 For unsigned integer types other than unsigned char,
the bits of the object representation shall be divided
into two groups: value bits and padding bits (there need
not be any of the latter).
[...]
The values of any padding bits are unspecified.

For example the 486 uses 32 bit registers, the actual indexing is done 8 bits per address. However reading 4 chars is slower than 1 dword.
Becuase you read 32 bits for each char read. FACT!

even on your micropro with bitslicing architecture, lets say you have 16 bits of data bus, but you only want to use 4 bits. OK you can, ITs still in the middle of one huge array of integers. FACT! It's still contiguous.
And every time you access those 4 bits they are in the same Physical
location as before.

No. Your claims run from the misleading to the blatantly wrong.

I think you may have confused what I was saying with how I was saying it.
Do you think we should optimize code that only utilized 1/8 of the register, or 1/4 of the data bus, whats the point.
You have to get the code to run twice as fast to make up for only using 1/2 the registers, 1/2 data bus, etc.
Thats always going to be true. And that is my point.

Nothing you have just said will always be true. 'Optimization' itself
is even loosely defined, as it depends on the situation.

Also, please stop top-posting, it's annoying.
Mark F. Haigh
mf*****@sbcglobal.net

Nov 14 '05 #18

DHOLLINGSWORTH2 wrote:

----- Original Message -----
From: "Richard Bos" <rl*@hoekstra-uitgeverij.nl>
Newsgroups: comp.lang.c
Sent: Wednesday, March 09, 2005 4:01 AM
Subject: Re: union with packed struct

If memory really were a gigantic array of ints, as DHOLLINGSWORTH2 seems to think, then you would be able to do a lot more. You could, for
if it wern't youd be wondering what a pointer is for. How to clear

up the ambiguity and what not.

if it weren't you would not be able to this:

char * text = "Some bs text to prove a DA point";
char text2[32];

int * pitext = text;
int * pitext2 = text2;

for( int i = 0; i < (32/ sizeof( int)); i++)
{
pitext2[i] = pitext[i];
}
No. You presume that &text[0] and &text2[0] are aligned properly for
int access. This code could generate an alignment trap on the ARM
processor box here on my desk.

Not to mention that since you're using signed ints to copy the data,
you could inadvertently cause an int to be loaded with a trap
representation.

Simply put, you are not qualified to be giving advice to anyone.

<snip>
I'll give you that, my specialty is doing all the Dirty NON-STANDARD work you think can't get done.

Maybe you can tell us where you work so we can all steer clear of your
company's products.
Mark F. Haigh
mf*****@sbcglobal.net

Nov 14 '05 #19

ccwork

DHOLLINGSWORTH2 wrote:

no,
No. What you said is: Keep in mind that a struct is just an int[],
with mapping handles for the "Programmer". This is wrong:
struct is not int[]. In other word, the offset of each struct member
is not always a multiple of fixed value. Say,
struct PACKED s
{
char a;
int b;
char c;
int d;
} x;
So &(x.a) has offset 0 to &x, &(x.b) has offset 1 to &x, &(x.c) has
offset 5 to &x and &(x.d) has offset 6 to &x. This is DIFFERENT from
array.
Obviously you gave a wrong example. And then you talked about data
bus, memory model, 64-bit, etc. All of them are dependent and not
standard C.
what I mean is that

char * s ="Some text in ram!";

the text "Some text in ram!" is actually stored in ram.
in contiguous chunks.

you could say char s[]; represents an area in ram at s,

I'M Saying that all of your ram can be looked at like
int []; instead of some char [], some word[]; etc.

When you store the data in a form the Hardware naturally proccessess you are going to save more clock cycles than you will pull out optimizing your code by hand.

Simple put, Streamlining your code, does more for you than optimizing. When you use data structures that are not in anyway equivelant to the native operation of your HW.

char s[] = "Some text in Ram";

as an int[]; is the same exact pattern in memory;

as a programmer you would have to unpack the integer to get the individual char values. when you use char []; the packing, and unpacking is done "behind the scene".

Lets say you have a struct :

struct myStruct {
short x;
short y;
short z;
} coord;

accessing coord.x means you are loading an intire register with int, and croping it to obtain the short portion.

in effect, incrementing x, y, z means you have loaded at least one of these twice, once you through it out, and the second time, you through the rest out.

on a 64 bit machine, Which reads and writes 64 bits at a time, you would read in each value, 16 bits, once, and get the other 48 bits with it, crop it ( unpack) , increment it, add the 48 bits back in,( pack it ), then save it back to ram.

you could read all 3 shorts at once by alligning your structure on a 64 bit boundary, and inc each one in one clock cycle, and similarly in one write cycle store all three values back.
or
(this was my original statement)
you can redifine mystruct
struct mystruct {
int x;
int y;
int z,
} coord;

now since the x, y, and z values match the register width, the Databus width, you don't have to ( unpack) or (pack) anything,

of the three methods here,

the first one really helps the programmer, and saves space, at the expense of clock cycles,

the second method saves space, and saves clock cycles at the expense of the programmer,

while the third method uses more space, but huals ass, and takes just as much time to code as the 1st method.

I'm not going to suggest not using char, You would have to write a sh__ load of string proccessing code, ( "already been done").
But you can logically order the information, and resize some information to give you the best of all 3 methods.

I hope this clears up what I was trying to say the first post.

I thought everyone could follow it ok. I was wrong.

IF( I_hurt_anyones_feeling)
{
my_Oppologies();
}
else O_FN_WELL;

Later,

Dan

Nov 14 '05 #20

Richard Bos

"DHOLLINGSWORTH2" <DH*************@cox.net> wrote:

From: "Richard Bos" <rl*@hoekstra-uitgeverij.nl>
If memory really were a gigantic array of ints, as DHOLLINGSWORTH2 seems
to think, then you would be able to do a lot more. You could, for
if it wern't youd be wondering what a pointer is for.

No, I wouldn't. If it _were_ I'd be wondering why we don't just use a
humongous integer as a pointer, but since I know that memory needn't be
flat, I realise that the purpose of pointers is to give us a reliable
way to address objects in memory, _regardless_ of how that memory is
arranged.
How to clear up the ambiguity and what not.
_What_ ambiguity? Make sense, man - cut the non sequiturs!
if it weren't you would not be able to this:

char * text = "Some bs text to prove a DA point";
char text2[32];

int * pitext = text;
int * pitext2 = text2;
Surprise, surprise: you _aren't_ guaranteed to be able to do that.

(Apart from which, do note that pointers to void and to char types have
special properties. Pointers to, and arrays of, struct and int do not.)
MEM is also just an array of bits;
also just an array of bytes;
also just an array of short's;
but where the i86 architecture is concerned
it's most like an array of int's.

Who says the i86 architecture is the corner-stone of the computing
world? There are other processors, you know.

common systems, but the Standard doesn't guarantee it.

I'll give you that, my specialty is doing all the Dirty NON-STANDARD work
you think can't get done.

That has nothing to do with comp.lang.c. This newsgroup discusses ISO C,
not gcc or MSVC half-assembler.

Richard

Nov 14 '05 #21

Richard Bos

"DHOLLINGSWORTH2" <DH*************@cox.net> wrote:

what I mean is that

char * s ="Some text in ram!";

the text "Some text in ram!" is actually stored in ram.
Not necessarily. It's a string literal, which can be stored in ROM.
in contiguous chunks.
Well, of course that one object is stored in one contiguous chunk. That
doesn't mean that memory is flat. Memory _within a single object_ is
flat, yes. That's required by the Standard.
you could say char s[];
char s[] is something entirely different from char *s.
I'M Saying that all of your ram can be looked at like
int []; instead of some char [], some word[]; etc.
And that's wrong. All memory (not just RAM) can be seen as a collection
of arrays of unsigned char. That's all you know, in ISO C. Nothing
requires all memory to be contiguous; nothing requires all memory to be
aligned to int boundaries.
struct myStruct {
short x;
short y;
short z;
} coord;

accessing coord.x means you are loading an intire register with int, and
croping it to obtain the short portion.

You do not know that.

[ Snip rest of system-specific and independable details. ]

By the way, could you _please_ learn to punctuate?

Richard

Nov 14 '05 #22

In article <OGyXd.1055$Qz.602@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:You can slice it by the bit, you can slice it by GiG.

:There is still only one address per Location!

Then you are telling me that the below architecture is not possible
to impliment in a manner which is conformant with the C standard?

- when using character instructions, the next adjacent HW address
gets you to the next character
- when using short instructions, the next adjacent HW address
gets you to the next short -- not just that you have to increment
the HW address by 2, but rather that (e.g.), 1117 is the address
of the short adjacent to the short 1118 and would correspond
to HW addresses 2234 and 2235 if one was examining memory using
character instructions
- when using int instructions, the next adjacent HW address gets
you to the next int, in a manner similar to that described for
short
- the process of casting a pointer involves bit shifting it
left or right an appropriate number of positions. This if one
casts a (char *) to an (int *) then information about character
position within the int gets lost and not restored if one then
converts that (int *) pointer back to (char *), but if one
converts any pointer to a (char *) and back again then one ends up
with the original pointer.

In this architecture, each location would have -several- different
addresses, one as a char, one as a short, one as an int, and all
well-defined C pointer casts would be possible. Given any one
particular (aligned) location in memory, this architecture would
have 3 different pointer values for the location, one per type.

The details about which exact RAM locations are accessed could
be dependant upon a few "width" pins that are distinct from the
address bus.
--
"I want to make sure [a user] can't get through ... an online
experience without hitting a Microsoft ad"
-- Steve Ballmer [Microsoft Chief Executive]

Nov 14 '05 #23

In article <11**********************@f14g2000cwb.googlegroups .com>,
Mark F. Haigh <mf*****@sbcglobal.net> wrote:
:Walter Roberson wrote:
:> If you re-examine what you are allowed to do with pointers, you will
:> find that you are not allowed to compare pointers to different
:> objects [even of the same type],

:Incorrect:

:6.5.9 Equality operators

:6 Two pointers compare equal if and only if both are
: null pointers, both are pointers to the same object
: (including a pointer to an object and a subobject
: at its beginning) or function, both are pointers to
: one past the last element of the same array object,
: or one is a pointer to one past the end of one array
: object and the other is a pointer to the start of a
: different array object that happens to immediately
: follow the first array object in the address space.

That last clause is not present in C89 3.3.9 Equality Operators.
"If two poinbters to object or incomplete types compare equal, they
both are null pointers, or both point to the same object, or both
point one past the last element of the same array object."

K&R2 A7.9 was even stricter:

"Pointer comparison is defined only for parts of the same object [...]"
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD

Nov 14 '05 #24

Old Wolf

Richard Bos wrote:

Equal, yes. You're allowed to compare pointers for equality. This is
simply done even in segmented or type-separated memory by noting that
two non-null pointers of different type need never compare equal at all: they point to different kinds of objects, therefore not to the same
object; they are by definition not null;

Not true. For example, pointers to different members of a
union must compare equal. Also, these two pointers must
compare equal:

int x;
&x == (char *)&x /* non-null pointers of different type */

Nov 14 '05 #25

On 8 Mar 2005 18:36:50 -0800, in comp.lang.c , "ccwork"
<cc****@hotmail.com> wrote:

Mark McIntyre wrote:
On Mon, 7 Mar 2005 23:37:20 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:
>Keep in mind that a struct is just an int[], with mapping handlesfor the
>"Programmer".

Nonsense.

Can you elaborate this further?

Yes: its nonsense to say that a struct is an array of ints.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

Nov 14 '05 #26

On Wed, 9 Mar 2005 02:43:27 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:

There is still only one address per Location!
Tell that to Intel. By the way, ever heard of a chip called the 8086?
I have used microproccessors with RISC, with nonrisc, even some with a
PRogrammable micro code.

And on every Computer, microproccessor, digital circuit, there is still only
one location for the specified address,
And you have some mathematical proof of this, or merely an instinct? And by
the way, you're completely wrong for any machine with virtual memory and/or
protected memory spaces.
For example the 486 uses 32 bit registers, the actual indexing is done 8
bits per address. However reading 4 chars is slower than 1 dword.
Becuase you read 32 bits for each char read. FACT!

So fscking what? This has NOTHING to do with either C, and nor is it in any
way showing that structs are arrays of ints.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

Nov 14 '05 #27

On Wed, 9 Mar 2005 03:58:34 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:

no,

what I mean is that

char * s ="Some text in ram!";
and s is a struct is it?
the text "Some text in ram!" is actually stored in ram.
Not necessarily.
in contiguous chunks.
Indeed, this is guaranteed by the C standard. But its not germane to your
argument.
Lets say you have a struct :

struct myStruct {
short x;
short y;
short z;
} coord;

in effect, incrementing x, y, z means you have loaded at least one of these
twice, once you through it out, and the second time, you through the rest
out.
Utter nonsense. Its implementation specific but any decent optimising
compiler would (if optimising for speed) align each member on a word
boundary for precisely this reason.
on a 64 bit machine, Which reads and writes 64 bits at a time, you would
read in each value, 16 bits, once, and get the other 48 bits with it, crop
it ( unpack) , increment it, add the 48 bits back in,( pack it ), then save
it back to ram.

no you wouldn't. Please stop spouting bullshit.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Nov 14 '05 #28

On Wed, 9 Mar 2005 04:44:17 -0600, in comp.lang.c , "DHOLLINGSWORTH2"
<DH*************@cox.net> wrote:

(of the idea that memory is a big array of ints)

if it weren't you would not be able to this:

char * text = "Some bs text to prove a DA point";
char text2[32];

int * pitext = text;
int * pitext2 = text2;
Surprise. You can't do that, and even microsoft know it.

warning C4133: 'initializing' : incompatible types - from 'char *' to 'int *'

So thats a bad start to your argument.
I haven't seen a compiler one that shows any difference to that FACT.

Don't make the mistake of assuming your own limited experience defines the known
universe.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Nov 14 '05 #29

All dynamic data is stored in memory, ram., no not ROM you cant load a
programm into rom, you burn a program into rom.

Don't confuse DATA ELEMENT's for MEMORY, or RAM.

and yes it is an int[], You are all arguing that a foot is not made up of
12 inches, there is no gaurantee, nop, nonsense.
Go Read what I originally posted, the subject.
Go Read your HW Manuf. Prog Ref. Man.
Go Write some code.
then
Go Blow Yourself!
=----

Nov 14 '05 #30

In article <11*********************@g14g2000cwa.googlegroups. com>,
Old Wolf <ol*****@inspire.net.nz> wrote:
:Not true. For example, pointers to different members of a
:union must compare equal.

Only when "suitably converted".

:Also, these two pointers must
:compare equal:

: int x;
: &x == (char *)&x /* non-null pointers of different type */

Are 'int' and 'char' "compatible types" ? If not, then
C89 section 3.3.9 says

Constraints
[...]
o both operands are pointers to qualified or unqualified versions
of compatible types;

o one operand is a pointer to an object or incomplete type and
the other is a pointer to a qualified or unqualified version of
void; or

o one operand is a pointer and the other is a null pointer constant
Richard Bos wrote:
:>
:> Equal, yes. You're allowed to compare pointers for equality. This is
:> simply done even in segmented or type-separated memory by noting that
:> two non-null pointers of different type need never compare equal at
:> all:

The only case I can see in C89 under which Richard was incorrect
was the clause about pointer to void.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

Nov 14 '05 #31

Actually a "virtual pointer" and a REAL PHYSICAL ADDRESS are different
things.

A pointer 0x040 is always at index 0x40, ALWAYS.
A relative offset is what you are thinking of.
And it is relative to some Physical Memory Address, and used to compute a
new Physical address.

There is no such thing in hardware as a "Virtual Address Bus", only
instructions that Compute the Physical Address.
"Mark F. Haigh" <mf*****@sbcglobal.net> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

DHOLLINGSWORTH2 wrote:
You can slice it by the bit, you can slice it by GiG.

There is still only one address per Location!

'Address' is not so easily defined. There may be 10,000 processes
running on a box, each with 10,000 different ideas of what exists at
virtual address 0x1234.

Further, a pointer with the integer value of 42 may mean the 42nd byte
of memory, the 42nd word, or the 42,000th quadword. It all depends on
the type of the pointer.

What we are concerned with here is the meaning the C standard gives to
'address', and what is guaranteed, no matter what the platform
involved.

Nov 14 '05 #32

Eric Sosman

Walter Roberson wrote:

In article <OGyXd.1055$Qz.602@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:You can slice it by the bit, you can slice it by GiG.

:There is still only one address per Location!

Then you are telling me that the below architecture is not possible
to impliment in a manner which is conformant with the C standard?

- when using character instructions, the next adjacent HW address
gets you to the next character
- when using short instructions, the next adjacent HW address
gets you to the next short -- not just that you have to increment
the HW address by 2, but rather that (e.g.), 1117 is the address
of the short adjacent to the short 1118 and would correspond
to HW addresses 2234 and 2235 if one was examining memory using
character instructions [...]

FWIW, I have written code for a machine with exactly this
arrangement. It had 128KB of addressable memory, but addresses
were only sixteen bits wide. Some instructions treated the
sixteen bits as a "word address," viewing memory as a flat
array of 64K 16-bit words. Other instructions treated them as
a "byte address," treating the lower half of memory as an array
of 8-bit bytes (the upper half of memory was inaccessible to
these instructions). Thus, all the "even-numbered" bytes in
the lower half of memory were addressable with byte addresses
or with word addresses, and in all but one case the two addresses
were numerically unequal.

(The infelicities didn't end with the addressing, either:
this was a ROTTEN machine to write code for! Almost thirty years
have passed since I last encountered it, and it still gives me
the willies.)

--
Er*********@sun.com

Nov 14 '05 #33

No, thats not what i'm saying.
That is what you are saying.

show me a map of physical memory, and take it all the way down to the
transistor, or Diode-Diode componant.

MEMORY, RAM, ROM are all arrays of individual bits, which store data
elements, char, ints, words, etc.

(1+1+1+1)+(1+1+1+1) = (4)+(4)

In any language, on every platform, on every planet, in every solarsystem.

As I said char, short, structs are there for you the programmer to disect
this array of memory. The memory itself, on all platforms, can be view as
int[]; safely, efficiently, and effectively.

That is why we CAN have pointers. Guaranteed.

You can argue that The is no guarantee, but your open minded optimism is
only a device for hiding your very real lack of understanding, and inability
to read, and understand what is being written.

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...

In article <OGyXd.1055$Qz.602@okepread05>,

Nov 14 '05 #34

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:i6********************************@4ax.com...

On Wed, 9 Mar 2005 02:43:27 -0600, in
Tell that to Intel. By the way, ever heard of a chip called the 8086?

Are you all Software nerds? Are do any of you know what HW is?

Why dont you let intel do the telling. Thats what i've done for nearly 20
years.

Nov 14 '05 #35

In article <Y3LXd.1100$Qz.938@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:All dynamic data is stored in memory, ram., no not ROM you cant load a
:programm into rom, you burn a program into rom.

So? Your statement that started this subthread was explicitly about
"all the memory on your system", not just about RAM.

There is also no constraint against a system having a table of frequently
used constants in ROM and using that table at need.

:and yes it is an int[], You are all arguing that a foot is not made up of
:12 inches, there is no gaurantee, nop, nonsense.

I used to work with a microprocessor which had a reserved I/O memory
page, in which the I/O could be done [via special instructions] in
a word size that was half the size of what the processor was otherwise
constrained to use -- you could load or store the high and low
nibbles separately but only in that portion of memory. This does not
fit into your model that "all memory" is int[].

:Go Read what I originally posted, the subject.

What you originally posted is not what you are posting now, and
what you originally posted was wrong.

:Go Read your HW Manuf. Prog Ref. Man.
:Go Write some code.

I never happened to have a peripheral connected that needed
"load high" or "load low", but it was there in the reference manual.

You have become accustomed to your flat memory systems and you
are ignorning those of us who say "Hey, I've met with some weird
things that didn't fit that model!" Computers existed before the
8-bit-byte flat-memory model become nearly pervasive; some of us
have worked on processors that worked in decimal, octal, 4 bit registers,
9 bit words, 10 bit words, 15 bit words, 18 bit words, 36 bit words,
80 bit floating point numbers, RISC, CISC, VLIW, bitsliced, embedded
processors with only 4 scratch memory locations; and more. There's some
pretty odd special-purpose stuff out there.

:then
:Go Blow Yourself!

That's not much of a way to convince us that your arguments are correct.
But then, they aren't correct; at most they are correct within your
experience.
--
Look out, there are llamas!

Nov 14 '05 #36

In article <ltLXd.1104$Qz.70@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:Are you all Software nerds? Are do any of you know what HW is?

Sure.

:Why dont you let intel do the telling.

Because there's a lot more to computing than Intel -- and even Intel
has put out some systems that don't fit your model.

:Thats what i've done for nearly 20
:years.

Somehow I knew that was coming. Proof by antiquity. For what it's
worth, I've been reading hardware manuals for nearly 30 years.
IBM. Motorola. DEC. Zilog. My magic words beat your magic words.
--
"This was a Golden Age, a time of high adventure, rich living and
hard dying... but nobody thought so." -- Alfred Bester, TSMD

Nov 14 '05 #37

Michael Mair

DHOLLINGSWORTH2 wrote:

"Mark F. Haigh" <mf*****@sbcglobal.net> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
DHOLLINGSWORTH2 wrote:
You can slice it by the bit, you can slice it by GiG.

There is still only one address per Location!
'Address' is not so easily defined. There may be 10,000 processes
running on a box, each with 10,000 different ideas of what exists at
virtual address 0x1234.

Further, a pointer with the integer value of 42 may mean the 42nd byte
of memory, the 42nd word, or the 42,000th quadword. It all depends on
the type of the pointer.

What we are concerned with here is the meaning the C standard gives to
'address', and what is guaranteed, no matter what the platform
involved.

[Fixed order of posting]
Actually a "virtual pointer" and a REAL PHYSICAL ADDRESS are different
things.
And neither is defined in the C standard.

A pointer 0x040 is always at index 0x40, ALWAYS.
Except if it is not. Apart from the fact that a pointer is (in C)
not an integer, even the conversion may not be straightforward and
lead directly to the index you think it specifies.
A relative offset is what you are thinking of.
And it is relative to some Physical Memory Address, and used to compute a
new Physical address.
This leads into an OT discussion but consider special addressing
modes which can give you different sizes for different pointer
types and different representations for the same physical address
without a real "computation" between the shorter (relative offset)
address and the long address.

There is no such thing in hardware as a "Virtual Address Bus", only
instructions that Compute the Physical Address.

Make this "one representation of the physical address".
Please do not top-post.
-Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

Nov 14 '05 #38

"Eric Sosman" <er*********@sun.com> wrote in message
news:42**************@sun.com...

(The infelicities didn't end with the addressing, either:
this was a ROTTEN machine to write code for! Almost thirty years
have passed since I last encountered it, and it still gives

I've never heard of a ROTTEN is that a description or a model? :)

Exactly what I'm talking about.

There are machines that only access 32 bits at a time.
address 0x0 has 32 bits before address 0x1.

There will eventually be computers that access 128 bits simultaneously, oops
they alrteady Do.

Now the intel indexes on the 8 bit boundary, while it accessess on the
8,16,32,64,and 128 bit sizes. but utilizing 8, and 16 bits of a 32 bit data
bus is a waist of proccessor time. Also lets say you have an double word, 4
bytes, 16 bits on one mem board, and the next 16 on the start of the next
mem board. This can be done, and it takes 4 times as long as utilizing an
int[];

You MUST for several HW devices force your data onto int[] boundaries.
pulling an int from 0x00 is quicker than pulling an int from 0x1. Becuse
the last 8 bits are at a different int[] offset than the first 24.

If I were so full of shit, then why does your comiler have an optin to place
data on these boundaries?

If anyone can answer that without confirming what i've said then I'll
unsubscribe from this group and leave it to the parsers, and lexical
scanners, that cannot communicate abstractly from Standard C.

( Please note that I am not directing this at anyone in particular)

Dan

Nov 14 '05 #39

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:42**************@news.individual.net...

"DHOLLINGSWORTH2" <DH*************@cox.net> wrote:
From: "Richard Bos" <rl*@hoekstra-uitgeverij.nl>

MEM is also just an array of bits;
also just an array of bytes;
also just an array of short's;
but where the i86 architecture is concerned
it's most like an array of int's.

Who says the i86 architecture is the corner-stone of the computing
world? There are other processors, you know.

show me one, and i'm not i86 specific. I know how to build ram in HW. Do
you.
You see in a BINARY system, there can never, NEVER be any different, than
each respectfful address bit deviding the Sum in half.

You probably lack the education to understand.

Nov 14 '05 #40

In article <biLXd.1101$Qz.180@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:Actually a "virtual pointer" and a REAL PHYSICAL ADDRESS are different
:things.

:A pointer 0x040 is always at index 0x40, ALWAYS.

Clearly you have never used a paged memory system.

:A relative offset is what you are thinking of.
:And it is relative to some Physical Memory Address, and used to compute a
:new Physical address.

You are assuming implimentations of virtual memory that do not hold true
on all systems. Segmented virtual address systems can refer down to
as low as one word, so virtual address 0x1234 might exist but there
might literally be nothing at virtual address 0x1233 or 0x1235, or
0x1235 might refer to a completely different part of physical memory,
or might refer to I/O memory.

:There is no such thing in hardware as a "Virtual Address Bus", only
:instructions that Compute the Physical Address.

Instructions? Well, instructions at the microcode level, perhaps.
The Motorola 68020 with its integrated MMU (Memory Management
Unit) did not have "instructions" for computing physical addresses:
a program running in Supervisor mode would send memory mappings to the
MMU co-processor which would read the internal virutal address bus and
output the appropriate physical address. But if you were using the
68010 which did not have an -integrated- MMU, then you would actually
output the virtual address onto the 68010 pins, and the seperate MMU
would read those pins and do the appropriate mapping.
--
This signature intentionally left... Oh, darn!

Nov 14 '05 #41

Martin Ambuhl

DHOLLINGSWORTH2 scribbled:
[more ridiculous uninformed bullshit]

This is my first reply to any of DHOLLINGSWORTH2's inane postings. It
is also my last, since I cannot stomach reading his crap any more.
*PLONK*

Nov 14 '05 #42

Clearly more than you,
you see a page:offset is a pointer to ONE and ONLY one address, that is
contiguous with page:offset+1;
"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.ca> wrote in message
news:d0**********@canopus.cc.umanitoba.ca...

In article <biLXd.1101$Qz.180@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:Actually a "virtual pointer" and a REAL PHYSICAL ADDRESS are different
:things.

:A pointer 0x040 is always at index 0x40, ALWAYS.

Clearly you have never used a paged memory system.

:A relative offset is what you are thinking of.
:And it is relative to some Physical Memory Address, and used to compute a
:new Physical address.

You are assuming implimentations of virtual memory that do not hold true
on all systems. Segmented virtual address systems can refer down to
as low as one word, so virtual address 0x1234 might exist but there
might literally be nothing at virtual address 0x1233 or 0x1235, or
0x1235 might refer to a completely different part of physical memory,
or might refer to I/O memory.

:There is no such thing in hardware as a "Virtual Address Bus", only
:instructions that Compute the Physical Address.

Instructions? Well, instructions at the microcode level, perhaps.
The Motorola 68020 with its integrated MMU (Memory Management
Unit) did not have "instructions" for computing physical addresses:
a program running in Supervisor mode would send memory mappings to the
MMU co-processor which would read the internal virutal address bus and
output the appropriate physical address. But if you were using the
68010 which did not have an -integrated- MMU, then you would actually
output the virtual address onto the 68010 pins, and the seperate MMU
would read those pins and do the appropriate mapping.
--
This signature intentionally left... Oh, darn!

Nov 14 '05 #43

Flash Gordon

DHOLLINGSWORTH2 wrote:

All dynamic data is stored in memory, ram.,
Or on disk. However, neither programs not string literals are dynamic
data, so that is irrelevant.
no not ROM you cant load a
programm into rom, you burn a program into rom.
You can also program string literals in to them. The example you
provided which you have now so conveniently failed to quote was of s
string literal.
Don't confuse DATA ELEMENT's for MEMORY, or RAM.
No one has, unless you have.
and yes it is an int[],
Quote the chapter and verse from the C standard that says so.
You are all arguing that a foot is not made up of
12 inches, there is no gaurantee, nop, nonsense.
No, we have said that an apple is not an orange.
Go Read what I originally posted, the subject.
We've already read the rubbish you have posted.
Go Read your HW Manuf. Prog Ref. Man.
I've read several thanks, and none have made the claims you have made.
Go Write some code.
Spent almost 20 years doing that proffesionally, although not all of
that in C (although a lot was assembler needing more detailed knowledge
of processors), and a few years before that programing occasionally on
an amature basis.
then
Go Blow Yourself!

Further evidence that you are just a troll.

I'll probably not bother responding further on this thread since it has
been more than adequately demonstrated that you are talking rubbish.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Nov 14 '05 #44

Flash Gordon

DHOLLINGSWORTH2 wrote:

"Eric Sosman" <er*********@sun.com> wrote in message
news:42**************@sun.com...
(The infelicities didn't end with the addressing, either:
this was a ROTTEN machine to write code for! Almost thirty years
have passed since I last encountered it, and it still gives
I've never heard of a ROTTEN is that a description or a model? :)

Exactly what I'm talking about.

Since the information you've cut included the fact that DIFFERENT
addresses were used for the same physical location depending on whether
you wanted a word or a byte, it is actually perfect proof that you are
talking bollocks.
There are machines that only access 32 bits at a time.
address 0x0 has 32 bits before address 0x1.

There will eventually be computers that access 128 bits simultaneously, oops
they alrteady Do.

Now the intel indexes on the 8 bit boundary, while it accessess on the
8,16,32,64,and 128 bit sizes. but utilizing 8, and 16 bits of a 32 bit data
bus is a waist of proccessor time. Also lets say you have an double word, 4
bytes, 16 bits on one mem board, and the next 16 on the start of the next
mem board. This can be done, and it takes 4 times as long as utilizing an
int[];

You MUST for several HW devices force your data onto int[] boundaries.
pulling an int from 0x00 is quicker than pulling an int from 0x1. Becuse
the last 8 bits are at a different int[] offset than the first 24.

If I were so full of shit, then why does your comiler have an optin to place
data on these boundaries?
Ones complement machines with -0 as a trap, then reading some bit
patterns as an int will nicely blow up your program.

Reading a char array you will often be reading at other than a word
boundary on machines where such things exist.

True 8-bit processors, where it makes absolutely no difference what the
int is aligned on because it is still two fetches of adjacent addresses.

Some systems have holes in the address space, so obviously not all
addressable memory can be considered ONE array of any type because if
you try to read through it you will hit non-existent addresses which
cause your program to abort.

By the way, even the current Intel HW provides a degree of HW support
for virtual memory so when a program accesses what IT thinks is address
40 the HW redirects it to another address or causes a page fault if it
is not currently mapped in to RAM.
If anyone can answer that without confirming what i've said then I'll
unsubscribe from this group and leave it to the parsers, and lexical
scanners, that cannot communicate abstractly from Standard C.

( Please note that I am not directing this at anyone in particular)

People have already pointed out systems (stranger than the systems I've
used) that don't fit in to your model.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Nov 14 '05 #45

In article <M7MXd.1116$Qz.778@okepread05>,
DHOLLINGSWORTH2 <DH*************@cox.net> wrote:
:Clearly more than you,
:you see a page:offset is a pointer to ONE and ONLY one address, that is
:contiguous with page:offset+1;

In systems in which the processor address space is less than the
amount of memory that people would like to use, then memory extension
is sometimes handled by writing a page number to a control register.
That triggers the paging in of a block of memory where a different block
of memory used to be, with the other block temporarily inaccessible.
This is also known as a "banked" memory system.

It was not uncommon for the banked address space to occupy the top end
of the physical address space -- say 0xC000 thru 0xFFFF . When such
a scheme is used, the physical address after 0XBFFF might refer to
memory bank #0 the first time, and two instructions later it might refer
to something in memory bank #5.

This was NOT a virtual memory scheme in the sense we know it now.
If you wanted to read something that was in memory bank #2 and write it
to something in memory bank #4, you either had to load it into temporary
storage in the non-banked area, or else you had to sit there and swap
banks on each read/write cycle.

Not every system has a flat address space. Not every system has
a meaningful answer for "the address after" a particular address.
--
Entropy is the logarithm of probability -- Boltzmann

Nov 14 '05 #46