• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 53 subscribers
  • Views 946 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Code size/Data memory : how to find out?

Andreas Weishaupt
Expert 1270 points

Hi all

I should now how big my code is (or different sections of my code) and the used data memory. I was looking at the .map file from linker output. In particular, I am interested in the following entries:

.far       ...
                  c007a180    00005478     tracking.obj (.far)

.text      ...
                  c0119660    00003cc0     tracking.obj (.text)

Is it true that .far is for the data memory and .text for program memory? And am I correct if the total memory occupied by e.g. "tracking.obj (.far)" is the number in the second column in bytes, i.e. ~21.2 kbytes for "tracking.obj (.far)"? And last question: in the C6747 CPU and instruction set manual I see that it uses 32-bit instruction set and has 32-bit adresses for data (chap. 1-7). But how do I find out if I address 8-, 16 or 32 bit data, or in other words: is the length given in the second column really in bytes or would I have to multiply by 4 or whatever?

Sorry for these somehow naive questions but I think I never really understood things when it comes to memory management, adressing etc.

Thanks for all your help.

Andreas

 

  • 0
    Genius 3575 points

    Is it true that .far is for the data memory and .text for program memory?

    Yes, but .far is not the only place for data.  The normal memory model puts aggregate data (arrays, structs) in far and puts other globals in the .bss section.  You can also have data in .switch & .const sections, and if you use dynamic allocation the heap is usually in the .sysmem section.  Local variables are typically kept on the stack, but you won't see them allocated in the .stack section.

     

    and am I correct if the total memory occupied by e.g. "tracking.obj (.far)" is the number in the second column in bytes, i.e. ~21.2 kbytes for "tracking.obj (.far)"?

    Yes.


    But how do I find out if I address 8-, 16 or 32 bit data, or in other words: is the length given in the second column really in bytes or would I have to multiply by 4 or whatever?

    The length is given in bytes.  To test this out, you can declare an array of bytes as a global and watch how the number increases (be careful it isn't optimized away if you don't reference it)

  • 0 in reply to MattLipsey
    Expert 1270 points

    Hi Matt. Thanks for your fast answer. So far so good. Just one last question:

    is the data memory 8-bit, 16-bit or 32-bit adressed? how can I find this out?

  • 0 in reply to Andreas Weishaupt
    Expert 1270 points

    It's okay. By inspecting memory I found out that arrays are auto-aligned on 8-byte boundaries, i.e.

    Uint8 data1[1];
    Uint8 data2[1];

    will occupy 9 bytes of memory. And for the rest there is "padding" like:

    Uint8  var1;
    Uint16 var2;
    Uint8  var3;
    Uint32 var4;

    will occupy 12 bytes:

    var1 00 var2b0 var2b1 var3 00 00 00 var4b0 var4b1 var4b2 var4b3

  • 0 in reply to Andreas Weishaupt
    Genius 3575 points

    I think that memory alignment and padding is very much architecture dependent.  I know that the C64+ core that I use allows unaligned accesses and has all kinds of fancy hardware and intrinsics that are designed to operate on byte arrays that are tightly packed.  I have some "holes" in my map file to align things (I think the compiler/linker likes to put arrays at double word boundaries to allow optimization) but in other areas there are byte sized globals from different modules all in consecutive byte sized addresses.   Whereas if you are using a 32-bit ARM core you typically can't do unaligned accesses, so you will see padding like in your case.