What does a struct look like in memory?

[Ben Hsu]

I'm rephrasing my problem posted before...

if i have a struct like this:
struct abc
{
short a;
short b;
char c;
};

what does this look like in memory? Is there
any tool to see what it looks like?

Thanks

[Schol-R-LEA]

>On 2002-02-16 13:03:37, Ben Hsu wrote:
>I'm rephrasing my problem posted before...
>
>if i have a struct like this:
>struct abc
>{
> short a;
> short b;
> char c;
>};
>
>what does this look like in memory? Is there
>any tool to see what it looks like?
>
>Thanks
>

It depends on the language (C and C++ may compile
differently), compiler, and it's version, as well
as the *specific* structure, and possibly the
order in which the elements were defined, and
possibly the target processor model (i.e., code
optimized for the Pentium may differ from code
optimized for the PIII).

However, as a rule, C compilers will produce more or less straightforward structs:

struct abc
.a resw 1
.b resw 1
.c resb 1
endstruct

(This is in NASM format; I don't know if you know AT&T/GAS format, Also, I assumed that short was two bytes and char was one byte, which is what ANSI C compilers should produce generally).

However, you shouldn't count on this, as the compiler may, for example, try to word-align the variables for efficiency's sake. C++ compilers may also mangle names on structures, depending.

If you're using GCC (as you mentioned earlier) then there is a simple way to answer your question, namely using the -S (assembly output) option. You can then review the resulting code at your leisure. Note, however, that GAS uses the AT&T style of mnemonics and syntax, which is quite different from the Intel/NASM syntax; indeed, it doesn't support struct directly at all, AFAICT. Good Luck.

[Ben Hsu]

Thank helps,

Thanks!

Ben Hsu
>On 2002-02-16 23:12:10, Schol-R-LEA wrote:
>>On 2002-02-16 13:03:37, Ben Hsu wrote:
>>I'm rephrasing my problem posted before...
>>
>>if i have a struct like this:
>>struct abc
>>{
>> short a;
>> short b;
>> char c;
>>};
>>
>>what does this look like in memory? Is there
>>any tool to see what it looks like?
>>
>>Thanks
>>
>
>It depends on the language (C and C++ may compile
>differently), compiler, and it's version, as well
>as the *specific* structure, and possibly the
>order in which the elements were defined, and
>possibly the target processor model (i.e., code
>optimized for the Pentium may differ from code
>optimized for the PIII).
>
>However, as a rule, C compilers will produce more or less straightforward structs:
>
>struct abc
> .a resw 1
> .b resw 1
> .c resb 1
>endstruct
>
>(This is in NASM format; I don't know if you know AT&T/GAS format, Also, I assumed that short was two bytes and char was one byte, which is what ANSI C compilers should produce generally).
>
>However, you shouldn't count on this, as the compiler may, for example, try to word-align the variables for efficiency's sake. C++ compilers may also mangle names on structures, depending.
>
>If you're using GCC (as you mentioned earlier) then there is a simple way to answer your question, namely using the -S (assembly output) option. You can then review the resulting code at your leisure. Note, however, that GAS uses the AT&T style of mnemonics and syntax, which is quite different from the Intel/NASM syntax; indeed, it doesn't support struct directly at all, AFAICT. Good Luck.

[Ben Hsu]

That helps,

Thanks!

Ben Hsu
>On 2002-02-16 23:12:10, Schol-R-LEA wrote:
>>On 2002-02-16 13:03:37, Ben Hsu wrote:
>>I'm rephrasing my problem posted before...
>>
>>if i have a struct like this:
>>struct abc
>>{
>> short a;
>> short b;
>> char c;
>>};
>>
>>what does this look like in memory? Is there
>>any tool to see what it looks like?
>>
>>Thanks
>>
>
>It depends on the language (C and C++ may compile
>differently), compiler, and it's version, as well
>as the *specific* structure, and possibly the
>order in which the elements were defined, and
>possibly the target processor model (i.e., code
>optimized for the Pentium may differ from code
>optimized for the PIII).
>
>However, as a rule, C compilers will produce more or less straightforward structs:
>
>struct abc
> .a resw 1
> .b resw 1
> .c resb 1
>endstruct
>
>(This is in NASM format; I don't know if you know AT&T/GAS format, Also, I assumed that short was two bytes and char was one byte, which is what ANSI C compilers should produce generally).
>
>However, you shouldn't count on this, as the compiler may, for example, try to word-align the variables for efficiency's sake. C++ compilers may also mangle names on structures, depending.
>
>If you're using GCC (as you mentioned earlier) then there is a simple way to answer your question, namely using the -S (assembly output) option. You can then review the resulting code at your leisure. Note, however, that GAS uses the AT&T style of mnemonics and syntax, which is quite different from the Intel/NASM syntax; indeed, it doesn't support struct directly at all, AFAICT. Good Luck.

[Schol-R-LEA]

Thanks, I hope it was helpful. I should, however,
point out a few more things.

First, you have to keep in mind that machine code
has no concept of structures, strong typing, etc. These exist solely as conveniences for the
programmer provided by the compiler or assembler.
It will quite happily, for example, add 0x48 to 0x65, despite the fact that it the variables were just enter as the first two characters in "Hello World!".

A compiler can, in principle, put the data
anywhere it wants, in any order it wants,
provided that it keeps track of the pointers and
offsets (though in the case of C the language
standard stipulates certain rules about how
structs are to be ordered in memory, IIRC). As
a matter of simple practicality, most compilers
groups structures together in more or less their
defined order, but you shouldn't rely on that
fact for the reasons I stipulated earlier.

Another thing to remember is that auto structs
(those that are local to a block or function) are
instantiated in the function's environment - in
C, this means on the stack within the function's
frame buffer. This is also true for parameter
structs (structs passed as arguments to a
function - yes, ANSI C allows this, but it is
rare in practice as it is highly inefficient
compared to passing a struct pointer as is the
conventional method).
Similarly, structs allocated dynamically will,
of course, be instatiated in the free heap.

What this means is, A struct may not be
explicitly defined at all in assembly language,
as it knows where the variables are and has no need to let ou in on the secret.
In machine language will be nothing more
than a group of pointer and/or frame buffer
offsets, anyway; so it has no real need to
provide the code in human readable form as a
rule.

I know these are fairly basic facts, but it is
far too easy to lose sight of them, and taking
an analogy or metaphor too literally is
something we've all done at one time or another.
This close to the machine, that can become a as
serious problem.

[Schol-R-LEA]

Thanks, I hope it was helpful. I should, however,
point out a few more things.

First, you have to keep in mind that machine code
has no concept of structures, strong typing, etc. These exist solely as conveniences for the
programmer provided by the compiler or assembler.
It will quite happily, for example, add 0x48 to 0x65, despite the fact that it the variables were just enter as the first two characters in "Hello World!".

A compiler can, in principle, put the data
anywhere it wants, in any order it wants,
provided that it keeps track of the pointers and
offsets (though in the case of C the language
standard stipulates certain rules about how
structs are to be ordered in memory, IIRC). As
a matter of simple practicality, most compilers
groups structures together in more or less their
defined order, but you shouldn't rely on that
fact for the reasons I stipulated earlier.

Another thing to remember is that auto structs
(those that are local to a block or function) are
instantiated in the function's environment - in
C, this means on the stack within the function's
frame buffer. This is also true for parameter
structs (structs passed as arguments to a
function - yes, ANSI C allows this, but it is
rare in practice as it is highly inefficient
compared to passing a struct pointer as is the
conventional method).
Similarly, structs allocated dynamically will,
of course, be instatiated in the free heap.

What this means is, A struct may not be
explicitly defined at all in assembly language,
as it knows where the variables are and has no need to let ou in on the secret.
In machine language will be nothing more
than a group of pointer and/or frame buffer
offsets, anyway; so it has no real need to
provide the code in human readable form as a
rule.

I know these are fairly basic facts, but it is
far too easy to lose sight of them, and taking
an analogy or metaphor too literally is
something we've all done at one time or another.
This close to the machine, that can become a as
serious problem.