05-02-2016 07:13 AM
Hello,
I am using the SDK to program a Zynq and checking the different optimization options.
Actually, I am getting impressive execution time improvement (85%) when changing the compiler optimization options from -O0 to -O3 plus adding -mcpu=cortex-a9. I guess the compiler is using the VFPv3 or the NEON vectorization automatically.
But there must be an increase in memory usage, am I right? How can be measured the memory used by the program?
Thanks.
Cerilet
05-04-2016 02:09 AM
Ok, finally!
I have found the way to introduce the linker options when called from GCC here:
Note---if the linker is being invoked indirectly, via a compiler driver (e.g. gcc) then all the linker command line options should be prefixed by -Wl, (or whatever is appropriate for the particular compiler driver) like this:
gcc -Wl,--start-group foo.o bar.o -Wl,--end-group
This is important, because otherwise the compiler driver program may silently drop the linker options, resulting in a bad link.
So you have to right click on the project folder in the Project Explorer and then select C/C++ Build Settings -> ARM gcc linker -> Miscellaneous and add in the Linker Flags -Wl,-M=output.map to be able to generate the map file.
Now the only (uh) thing left is to understand the file.
Many thanks Austin for your help!
05-02-2016 07:52 AM - edited 05-02-2016 07:53 AM
c,
In the past, a technique I used was to create a loop to write some pattern into the data storage area, so that I could the direct another program I wrote to report out how much of that space still had the initial value in it. I know that reports should be telling you the size (and location) of all variables, but sometimes it is nice to verify what the tools report so you get comfortable with the tool reports.
The linker has a 'GNU Objects Dump' that lists all variables, locations, etc.
I used 0xAAAAh, or 0x5555h as my pattern (unlikely for huge sections to have this value and be unused).
You may also use the Xilinx debugger to do the above XMD (ug1043).
05-03-2016 09:50 AM
Thanks for your reply Austin.
So there is not an automated way on SDK to quickly check it?
That will take time to implement...
05-03-2016 09:54 AM
gcc reports memory usage,
The GNU compiler/linker does report the memory used.
05-03-2016 11:54 AM
The only output I see in the compiler is this. But is not it just how much memory the program ocuppy? I need to know how much memory the program uses during runtime depending on the optimization option.
'Invoking: ARM Print Size'
arm-xilinx-eabi-size simple_tests.elf |tee "simple_tests.elf.size"
text data bss dec hex filename
59720 2376 301996236 302058332 12010b5c simple_tests.elf
'Finished building: simple_tests.elf.size'
By the way, what these values mean?
Thanks again for your help.
05-03-2016 11:59 AM
the option:
"--print-map
This command tells the linker to create a map file."
is used with gcc. Look up linker scripting with gnu gcc.
05-04-2016 02:09 AM
Ok, finally!
I have found the way to introduce the linker options when called from GCC here:
Note---if the linker is being invoked indirectly, via a compiler driver (e.g. gcc) then all the linker command line options should be prefixed by -Wl, (or whatever is appropriate for the particular compiler driver) like this:
gcc -Wl,--start-group foo.o bar.o -Wl,--end-group
This is important, because otherwise the compiler driver program may silently drop the linker options, resulting in a bad link.
So you have to right click on the project folder in the Project Explorer and then select C/C++ Build Settings -> ARM gcc linker -> Miscellaneous and add in the Linker Flags -Wl,-M=output.map to be able to generate the map file.
Now the only (uh) thing left is to understand the file.
Many thanks Austin for your help!