Pointer Array programming MSP430

It's not really clear what you want to do. Do you need just a (static) table of addresses or an array of changing pointers? Are the values known at compile-time or not? If your array is static, it should be built at compile-time. It reduces code size and you can declare it as static, so it can reside in FLASH and does not need RAM. There is no way to generate a loop that is executed at compile-time. For _really_ complex tasks, you could set up an external python script that generates a source file with the values you need. But that's plain overkill in this case. You can use the following construct: const unsigned int * A[8]= { 0, (unsigned int *)(ADRESSE_BASE + (CH_NB-1)*2), (unsigned int *)(ADRESSE_BASE + (CH_NB-2)*2), (unsigned int *)(ADRESSE_BASE + (CH_NB-3)*2), (unsigned int *)(ADRESSE_BASE + (CH_NB-4)*2), (unsigned int *)(ADRESSE_BASE + (CH_NB-5)*2), (unsigned int *)(ADRESSE_BASE + (CH_NB-6)*2), (unsigned int *)(ADRESSE_BASE + (CH_NB-7)*2) }; So you can access them as A[1]..A[7]. (I omitted A[0] to match your old numbering, as arrays always start with index 0). The values at the given addresses are accessible with *A[x]. This array will use 16 bytes of Flash and 0 bytes of RAM. You can of course define an array like unsigned int * A[8]; and fill it inside your main() with the required data. This way it would require 16 bytes RAM and no Flash, but some flash for the code filling it with the proper addresses. Probably more flash than what you save by not defining the array as a const one at compile time. Both have a major drawback if the addresses you want to use in your code are always the same ones: instead of just accessing the destination address (as it would do if you just use Ax as you do with your current defines), the code needs to first load the address of the array, calculate the offset to the array member, load the destination address from there and THEN access the register (or whatever else it is). This adds significant overhead to your code for every access of the destination. I had a (I guess) similar problem when writing a library structure for SPI that will handle any of the 8 SPIs of the MSP5438. Without hand-optimized code, the overhead for the access of the registers through an array of addresses was way too much to be acceptable, effectively limiting the SPI throughput to below 1MHz clock. Unless there's a really good reason to do so, you'd better stay with the DEFW defines you already use.