How to check the final file size will be download to MSP430 processor?

You can turn on the option in your toolchain to generate a linker mapping file. That file will tell you how much FLASH/RAM/etc is required. Anyway, you need to select a part to target when building, so the toolchain will tell you at link time if the design does not fit the part you chose.

Since you don't mention which toolchain you are using, I leave that as an exercise for you to look it up in your documentation/help files.

Sunglin Chen said:

I have checked the file size of *.out file

The .out file contains not only the binary data fot the MSP, but also debugging information such as references to the source code, variable name and locations etc. Even if you make a release build, which will remove most of the debugging information from the output, it wills till contain a lot mroe than jsut the binary code. So you cannot even guess the size of the code from the size of the .out file (except for the fact that it won't be larger than the file).

You can configure the linker to generate a map file that will shoe you the size and locations of functions and variables.
Or you add a huge array of known size to your project and then read the linker error telling you how much the total size is and that it won't fit. Subtracting the array size gives you the real size of code and data. :)

Juha Lumme said:

- Is it stupid to use USCIAB0RX_VECTOR for also TX stuff ?

Not stupid, but usually a bad idea. On 5x family, RX and TX interrupts both call teh same ISR. However, the ISR code will not serially handle them but rather branch depending on which interrutp it was triggered. But it may loop to check whether the other one has been triggered already while serving the first, savin ISR entry/exit time.

Juha Lumme said:

- Isn't USCIAB0RX_VECTOR triggered at every clock pulse ?

No. It is triggered when a new byte arrived in RXBUF. Which on SPI means every 8th external clock pulse.
Also, RXIFG and TXIFG, while appearing to be set at the same time, are actually set 7.5 or even 15.5 clock pulses apart.
When you first write to TXBUF, TXIFG is set immediately again, when the USCI begins sending.the jsut written word. So you can stiuff the next byt eto TXBUF. Now RXIFG is set 1/2 clock pulse after the first byte has been sent while TXIFG is set when the second byte begins sending. (1/2 clock pulse after RXIFG). But then the RXIFG that belongs to the byte received while the second byte is sent, arrives 15.5 clock cycles after you got the TXIFG for the second byte. So the two do not only appear not a tt heexact same moment, but are also interleaved by one byte ona continuous transfer.

Juha Lumme said:

- How about __bis_SR_register(GIE); is that a good mode for the uC to be in ?  

Well, it's not eactly a 'mode'. GIE means Global Interrupt Enable. If this bit is clear, teh processor will ignore all interrupt requests and never call an ISR. If it is set, an interrupt will cause the processor to call the appropriate ISR.
So yes, setting GIE is a good idea if you want to have any interrupts executed.