I agree ... the way you used const originally defined a pointer to a function that returned a const int ... not a const pointer.
-----Original Message----- From: mspgcc-users-ad...@lists.sourceforge.net [mailto:mspgcc-users-ad...@lists.sourceforge.net] On Behalf Of Richard Willis Sent: Friday, November 12, 2004 12:05 AM To: Mspgcc-users@lists.sourceforge.net Subject: Re: [Mspgcc-users] Getting tables of function pointers to be in ROM and not RAM ... Hi Todd, Like your neat example :-) Try this change: Before: const int (*MyFunctions[])(int) = { gives... Disassembly of section .data: 00000200 <MyFunctions>: 200: 6a 80 sub.b @r0, r10 ; 202: 8a 80 0c 84 Address 0x204 is out of bounds. sub r0, -1(r10) ; After (note the extra const following the "*"): const int (* const MyFunctions[])(int) = { gives... 00008040 <MyFunctions>: 8040: 6e 80 sub.b @r0, r14 ; 8042: 8e 80 31 40 sub r0, 16433(r14); and 0000806e <Function1>: 0000808e <Function2>: Cheers, Rich :-) ----- Original Message ----- From: "Todd Hochwitz" <hochw...@technical-mandala.com> To: <Mspgcc-users@lists.sourceforge.net> Sent: Friday, November 12, 2004 3:41 PM Subject: [Mspgcc-users] Getting tables of function pointers to be in ROM and not RAM ... Hello everyone, I've been using MSPGCC for the past several months in a large firmware project with good success. The version I've been using is v3.2.3, from the mspgcc-20040723.exe release, running on Win2K. It took me a while to figure out how to get MSPGCC to actually put constant data into ROM/FLASH instead of RAM (just declaring as const didn't do it -- had to use array notation like const AString[]="String" instead of pointer notation like const *AString="String"). But I've been unsuccessful to get arrays of function pointers to be placed in ROM/FLASH. The tools want to place arrays of function pointers, even when declared as const, into RAM. Is this behavior of MSPGCC correct, or am I missing a command line flag, or is there some subtle syntax required? As an example, here is a simple (but contrived) source file that illustrates the problem: ========================================================= /* // Test file -- why are the function pointers placed in RAM instead // of in a ROM table? */ /* // Two functions to populate the function table. Declaring as const // is needed to keep gcc from griping. */ const int Function1(int); const int Function2(int); /* // Now declare an array of functions. Since they are // declared as constants, shouldn't they be placed in // ROM? */ const int (*MyFunctions[])(int) = { Function1, Function2 }; /* // Just a dummy main to get the code to compile and link. // The return(1) is to keep GCC from griping. */ int main(void) { int a; a = MyFunctions[0](10); a = a + MyFunctions[1](32); return(1); } /* // The dummy functions for the function table. Again, declared // as const to keep GCC from griping. */ const int Function1(int AVar) { return(AVar + 7); } const int Function2(int AVar) { return(AVar * 2); } /* // Done. */ ========================================================= Since I've declared the function array MyFunctions as a const, and am using a syntax consistent with what MSPGCC expects for strings or structures to be placed in ROM/FLASH, I'd expect MyFunctions to be placed at an address in ROM/FLASH. But after executing the following two commands: msp430-gcc -mmcu=msp430x449 -O2 -Wall -g -c Test.c -o Test.o msp430-gcc -mmcu=msp430x449 -Wl,-Map=Test.map,--cref -o Test.elf Test.o I see the following from the Test.map file: .data 0x00000200 0x4 Test.o 0x00000200 MyFunctions 0x00000204 . = ALIGN (0x2) *(.gnu.linkonce.d*) 0x00000204 . = ALIGN (0x2) 0x00000204 _edata = . MyFunctions is placed in the .data segment, at address 0x200, which is RAM. And the size is consistent with two function pointers -- two function pointers of two bytes each would indeed consume 4 bytes of RAM. I've tried compiling for several variants of the MSP430, and obtain the same results. So ... what am I missing? Thanks in advance. Just further contribution to white noise from Todd... ------======>>>>>>}}}}}}]]]]]]||||||[[[[[[{{{{{{<<<<<<======------ e-mail: hochw...@technical-mandala.com Some world-views are spacious And some are merely spaced - Neil Peart ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users ------------------------------------------------------- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
