Hi
I have the following code in cryptography. It is a function which accepts a "key" and "state" inputs and then encrypts state using key.
uint state[4]={0,1,2,3}; uint key[8]={1,2,3,4,5,6,7,8}; Encrypt(state,key);
When I increase size of the "state" variable, I expect to see RW-Data to grow. Because variables are located in RAM. But I see that code size and RO-Data increase instead.
Why ?!
I appreciate your help.
Regards
If you have initialised data, it is put into CODE space and copied to RAM on startup. If you increase the size of the array, then the amount allocated in CODE will increase too.
This is NORMAL for an embedded system. You must learn to research how these things operate.
Thanks. I know how initialization data are copied from a non-volatile memory to RAM.
This is what I do not understand: I want to know how much RAM a crypto algorithm uses. But these two codes consume different CODE but the same RAM:
uint state[4]={1};
and
uint state[40000]={1};
This is not consistent with classic model of ROM/RAM memory usage. NORMALLY, "state" variable located in RAM and its initialization values copied from ROM to RAM at the startup. Therefore, When I increase "state" variable size, I expect to see a growth in RAM.
f.n: I have used the entire array in my code. So none of it is trimmed by the compiler optimization.
I know how initialization data are copied from a non-volatile memory to RAM.
But you seem unaware of at least three things:
1) the reason why Keil calls this process "decompression" rather than just "copying".
2) the distinction between static and automatic variable lifetime, and its effect on initialization.
3) the fact that if you really want to know what's going on, you'll have to look at the compiled directly, not just at global consumption numbers.
Thank you Hans-Bernhard. This was helpful. and I did not know that.
I am preparing a report on memory usage of numerous algorithms.
So, I will try to find the maximum RAM usage during the execution of the program. This is what I actually have been looking for. And apparently is not obvious in the compiler global memory report.