IAR Map File

DATA size is always shown in the map file (and the hardware register 'variables' of course do not use any RAM space).

RAM usage, however, cannot be calculated easily. It fully depends on your program flow.

If you call a function, it takes 2 bytes on stack, on MSP430X systems (20 bit addresses) it takes 4 bytes. Then any register usind inside the called function must be saved on stack (another 2 bytes each). Local variables are put on the stack too (and removed when teh function exits). Exception are static variables, which take normal DATA space just like global ones, and are handles exactly as these (including initialisation inside the reset function), only that no global reference is generated.

If an ISR is called, 4 bytes are saved on stack and also all register which are required for the code inside the ISR (2 bytes each).

Depending on the compiler (each one can handle this differently, I only know of the mspgcc), parameters passed to functions are either passed in a register (the mspgcc uses r12..r15 for up to 4 words or 2 dwords, and these 4 registers are not saved on stack nor restored, but considered clobbered after a function call or hold the return value) or on the stack (on mspgcc, if there are more than 4 byte/word, 2 dword or 1 64bit value). Calling printf requires a LOT of stack space, not only for calling the function and assign hte parameters, but also for the subfunction calls to convert values to text and then for calling the output function.

If you dynamically allocate ram with malloc(), it also uses ram.

How much is required cannot be determined by compiler or linker.

You can try the following: at application startup, fill all memory above the used data area with a guard value (spare the uppermost bytes in case that main() uses them for the local variables) and then let your application run.  (a typical one is 0xaa55, usually used for testing ram integrity, but anything except 0 and 0xffff will do)
After some time, if you think you have done everything, stop the application with the debugger and check the ram area for how much of the gard values have been overwritten by the stack. So you know that you at least need this much ram for the stack.

If you do not find your guard value anymore at all, then your stack has already overflown into your data area and overwritten some of your variables.

I was looking for the answer to your question:

"Could you please explain how should I refer to 'absolute' value?"

I believe that this is the data accesses to hardware registers, which have fixed, i.e. absolute addresses. And this is the reason IAR does not count the data accesses towards the typical, i.e. relative, data memory usage.

I believe this is true because I see in the Module Summary at the end of the MAP file that all absolute data allocations come from modules with ISRs, which of course access hardware registers. I also confirmed that commenting out a single hardware register write reduced the absolute data usage by 2 bytes.

I'm not an IAR or MSP430 expert, can anyone else confirm this?

Update:

Anders confirmed this in What do Shared and Common Memory Represent in an IAR for MSP430 MAP File? on 11/21/2014.