union with packed struct

[Walter Roberson]

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

 

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

 

[DHOLLINGSWORTH2]

Clearly more than you,
you see a pageffset is a pointer to ONE and ONLY one address, that is
contiguous with pageffset+1;

 

[Flash Gordon]

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]

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.

 

[Walter Roberson]

:Clearly more than you,
:you see a pageffset is a pointer to ONE and ONLY one address, that is
:contiguous with pageffset+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.

 

[Mark F. Haigh]

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*

Interestingly, the folks at Cornell University have quantified what
many of us have instinctively known to be true:

"Not only do these people reach erroneous conclusions and
make unfortunate choices, but their incompetence robs them
of the metacognitive ability to realize it."

Justin Kruger and David Dunning: "Unskilled and Unaware of
it: How Difficulties in Recognizing One's Own Incompetence
Lead to Inflated Self-Assessments"

In another place and time, we'd be thanking DHOLLINGSWORTH2 for his
participation in the study; unfortunately, though, this is
comp.lang.c, so I'd have to agree with your sentiments.

Mark F. Haigh
(e-mail address removed)

 

[Keith Thompson]

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[];

(I'd fix the top-posting, but I'm only quoting DHOLLINGSWORTH2's
original text.)

Your previous statement was

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

Consider this structure:

struct foo {
char c;
};

Assume sizeof(int) == 4. Typically, sizeof(struct foo) will be 1 (it
could be more if the compiler chooses to add padding). A structure
this small cannot be represented as an array of int.

I think (please correct me if I'm mistaken) that what you *meant* to
say is that an object of a structure type is implemented as a
contiguous chunk of memory, with a flat memory model within that
chunk. If that's what you meant, then you're correct. This is
implied by the rules about treating any object as an array of unsigned
char, about the layout of members within a structure, and about the
semantics of the offsetof() macro.

C requires a flat memory model within a single object, but not across
objects. (I don't think you've said anything about the flat memory
model applying across objects; I mention this for the sake of
completeness.)

So your basic idea was correct; the only problem is that you
incorrectly expressed it in terms of arrays of ints rather than arrays
of bytes. The difference is significant.

One of the most important things to know about the dynamics of this
newsgroup is that errors do not go uncorrected, even if they're not
necessarily central to the point being made. No single poster can
guarantee that everything he writes will be accurate; we take pride in
producing (or attempting to produce) an accurate final result by an
interaction among multiple experts. If you don't like that style of
interaction, that's fine, but you're not going to be able to avoid it
if you participate in this newsgroup.

 

[CBFalconer]

.... snip ...

Interestingly, the folks at Cornell University have quantified what
many of us have instinctively known to be true:

"Not only do these people reach erroneous conclusions and
make unfortunate choices, but their incompetence robs them
of the metacognitive ability to realize it."

Justin Kruger and David Dunning: "Unskilled and Unaware of
it: How Difficulties in Recognizing One's Own Incompetence
Lead to Inflated Self-Assessments"

In another place and time, we'd be thanking DHOLLINGSWORTH2 for his
participation in the study; unfortunately, though, this is
comp.lang.c, so I'd have to agree with your sentiments.

With slight modifications in the last paragraph, this has to be
retained here for GP use in the future.

 

[Michael Wojcik]

Not necessarily. It's a string literal, which can be stored in ROM.


Well, of course that one object is stored in one contiguous chunk.

And even then, only from the C program's point of view. The imple-
mentation might have scattered it about arbitrarily, as long as it
looks contiguous to the program. There's no guarantee whatsoever
that it's in "contiguous chunks" of "ram" [sic].

For that matter, even in the typical implementations on modern
desktop machines (for all-the-world's-an-x86 types like D11H here),
if that string crosses a page boundary the two pieces may well be
in non-contiguous "chunks" of RAM (assuming a suitable definition
of "chunk"), even though they're adjacent in the process' virtual
memory space.

 

[Mark McIntyre]

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

String literals are not dynamic data, and are explicitly allowed to be stored
anywhere. My computer's ROM contains the word Intel. My compiler, when
encountering a string literal "Intel" is allowed to point to that ROM address if
it wants.

and yes it is an int[],

No, and no amount of shouting and stamping your little foot, will make it so.

Go Blow Yourself!

Fool

 

[Mark McIntyre]

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

Lets put that comment back in context. You said

There is still only one address per Location!

And if you have ever encountered x86 segmented architecture, you;ll know that to
be false. Its been a while, but I believe 0F00 and 00F0 are the same on that
arch.
And by the way, if you know *anything* about the Pentium, you'll be aware that
by using selectors you can point several addresses to the same location.

Why dont you let intel do the telling.

I am doing. Why not read your manual for x86 assembly programming?

Thats what i've done for nearly 20 years.

And yet you've never come across a machine with nonlinear memory. Interesting.

 

[Mark McIntyre]

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

Oh, and by the way, is virtual memory in RAM? .

 

[Mark McIntyre]

show me one,

you want to see other processors? Go look in a mac shop, or under your car
bonnet (hood if you're a yank), in your fridge, in your calculator, in your
computer (yup), etc etc. Sheesh, they're all over the place.

I know how to build ram in HW. Do you.

yeah, triff. I work with bond traders, so I know all about big swinging.....

 

[Richard Bos]

[ Yet more nonsense, ending in: ]

Go Blow Yourself!
=----

Ok, let's look at the evidence, shall we?

- Posts provably untrue statements
- Insists that he's right even in the face of overwhelming evidence,
which would have made anyone merely wrong at least reconsider
- Has reverted to top-posting, and now has even
- stopped providing any context at all (yet is not on Google Broken)
- Refers to entirely ephemeral experience in merely related fields
- Tries to insult the competence of anyone who disagrees with him
- Finally, resorts to obscenities

Gentlemen, I'm not so sure we're dealing with a mere kook here. He
doesn't strike me as innocently imbecilic. I call him a troll.

Richard

 

[Old Wolf]

Only when "suitably converted".

I presumed that Richard's comment was before "suitable
conversion" in situations where no explicit conversion
is required.

Otherwise I don't see the value of what he is saying,
since it isn't possible to compare two non-null pointers
of different type (if you try to do so, and no constraint
violations occur, one of them will undergo an implicit conversion).

The only case I can see in C89 under which Richard was incorrect
was the clause about pointer to void.

Which cases is he correct about? Can you post some sample code,
if my above paragraph is unclear?

 

[Walter Roberson]

:> Richard Bos wrote:
:> Old Wolf wrote:
:> >Not true. For example, pointers to different members of a
:> >union must compare equal.

:> Only when "suitably converted".

:I presumed that Richard's comment was before "suitable
:conversion" in situations where no explicit conversion
:is required.

:Otherwise I don't see the value of what he is saying,
:since it isn't possible to compare two non-null pointers
f different type (if you try to do so, and no constraint
:violations occur, one of them will undergo an implicit conversion).

His point was that there are constrain violations involved in all
such cases of comparing non-NULL pointers of different types.
And he was right except that he missed the void* case (which I
probably would have missed too.)


:Can you post some sample code,
:if my above paragraph is unclear?

Your wording implied that for any two union members, &u.i == &u.j
and my reply was that "You can't do that" unless the types are
compatable or you have undertaken a cast that might have no meaning.

In the code below, gcc and SGI's cc warn about every pointer comparison
except when comparing identical objects or when comparing void * to
another pointer.


I was thinking of chopping out the identical object case when I
generated the table; the result turned out to be interesting.
In SGI's cc, u.Float == u.Float and u.Double == u.Double but in
gcc, u.Float != u.Float and u.Double != u.Double . (These are
not pointer comparisons, they are comparisons of the result of
interpreting a pointer as float or double.) This might be chance
positioning on the stack, but I suspect more likely it is NaN checks,
since IEEE 754 defines NaN to not compare equal to itself.



#include <stdio.h>

#define CP(T1,T2) printf( "&u.%s %s &u.%s\n", #T1, \
&u.T1 == &u.T2 ? "==" : "!=", #T2 )
#define CP2(T1,T2) printf( "u.%s %s u.%s\n", #T1, \
u.T1 == u.T2 ? "==" : "!=", #T2 )
#define CP3(T1,T2) printf( "u.%s %s &u.%s\n", #T1, \
u.T1 == &u.T2 ? "==" : "!=", #T2 )

int main(void) {

union {
float Float;
double Double;
int Int;
long Long;
short Short;
char Char;
long long LongLong;
unsigned int UnsignedInt;
unsigned char UnsignedChar;
void* VoidPtr;
} u;

u.VoidPtr = (void *)&u;

CP(Float,Float);
CP(Double,Float);
CP(Double,Double);
CP(Int,Float);
CP(Int,Double);
CP(Int,Int);
CP(Long,Float);
CP(Long,Double);
CP(Long,Int);
CP(Long,Long);
CP(Short,Float);
CP(Short,Double);
CP(Short,Int);
CP(Short,Long);
CP(Short,Short);
CP(Char,Float);
CP(Char,Double);
CP(Char,Int);
CP(Char,Long);
CP(Char,Short);
CP(Char,Char);
CP(LongLong,Float);
CP(LongLong,Double);
CP(LongLong,Int);
CP(LongLong,Long);
CP(LongLong,Short);
CP(LongLong,Char);
CP(LongLong,LongLong);
CP(UnsignedInt,Float);
CP(UnsignedInt,Double);
CP(UnsignedInt,Int);
CP(UnsignedInt,Long);
CP(UnsignedInt,Short);
CP(UnsignedInt,Char);
CP(UnsignedInt,LongLong);
CP(UnsignedInt,UnsignedInt);
CP(UnsignedChar,Float);
CP(UnsignedChar,Double);
CP(UnsignedChar,Int);
CP(UnsignedChar,Long);
CP(UnsignedChar,Short);
CP(UnsignedChar,Char);
CP(UnsignedChar,LongLong);
CP(UnsignedChar,UnsignedInt);
CP(UnsignedChar,UnsignedChar);
CP(VoidPtr,Float);
CP(VoidPtr,Double);
CP(VoidPtr,Int);
CP(VoidPtr,Long);
CP(VoidPtr,Short);
CP(VoidPtr,Char);
CP(VoidPtr,LongLong);
CP(VoidPtr,UnsignedInt);
CP(VoidPtr,UnsignedChar);
CP(VoidPtr,VoidPtr);

CP2(Float,Float);
CP2(Double,Float);
CP2(Double,Double);
CP2(Int,Float);
CP2(Int,Double);
CP2(Int,Int);
CP2(Long,Float);
CP2(Long,Double);
CP2(Long,Int);
CP2(Long,Long);
CP2(Short,Float);
CP2(Short,Double);
CP2(Short,Int);
CP2(Short,Long);
CP2(Short,Short);
CP2(Char,Float);
CP2(Char,Double);
CP2(Char,Int);
CP2(Char,Long);
CP2(Char,Short);
CP2(Char,Char);
CP2(LongLong,Float);
CP2(LongLong,Double);
CP2(LongLong,Int);
CP2(LongLong,Long);
CP2(LongLong,Short);
CP2(LongLong,Char);
CP2(LongLong,LongLong);
CP2(UnsignedInt,Float);
CP2(UnsignedInt,Double);
CP2(UnsignedInt,Int);
CP2(UnsignedInt,Long);
CP2(UnsignedInt,Short);
CP2(UnsignedInt,Char);
CP2(UnsignedInt,LongLong);
CP2(UnsignedInt,UnsignedInt);
CP2(UnsignedChar,Float);
CP2(UnsignedChar,Double);
CP2(UnsignedChar,Int);
CP2(UnsignedChar,Long);
CP2(UnsignedChar,Short);
CP2(UnsignedChar,Char);
CP2(UnsignedChar,LongLong);
CP2(UnsignedChar,UnsignedInt);
CP2(UnsignedChar,UnsignedChar);

/*
Void* to a non-pointer won't pass the parser so skip that
and try pointer tests instead
*/

CP3(VoidPtr,Float);
CP3(VoidPtr,Double);
CP3(VoidPtr,Int);
CP3(VoidPtr,Long);
CP3(VoidPtr,Short);
CP3(VoidPtr,Char);
CP3(VoidPtr,LongLong);
CP3(VoidPtr,UnsignedInt);
CP3(VoidPtr,UnsignedChar);
CP3(VoidPtr,VoidPtr);
}