union with packed struct

[Richard Bos]

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.

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

 

[Richard Bos]

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

 

[Walter Roberson]

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

 

[Walter Roberson]

:> 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 [...]"

 

[Old Wolf]

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 */

 

[Mark McIntyre]

On Mon, 7 Mar 2005 23:37:20 -0600, in comp.lang.c , "DHOLLINGSWORTH2"

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]

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]

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]

On Wed, 9 Mar 2005 04:44:17 -0600, in comp.lang.c , "DHOLLINGSWORTH2"

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

 

[DHOLLINGSWORTH2]

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!
=----

 

[Walter Roberson]

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

 

[DHOLLINGSWORTH2]

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.

 

[DHOLLINGSWORTH2]

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.

 

[Eric Sosman]

: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.)

 

[DHOLLINGSWORTH2]

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.

 

[Walter Roberson]

:All dynamic data is stored in memory, ram., no not ROM you cant load a
rogramm 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.

 

[Walter Roberson]

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

 

[Michael Mair]

[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

 

[DHOLLINGSWORTH2]

(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

 

[DHOLLINGSWORTH2]

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.