From: Shalabh J. <sha...@gm...> - 2012-08-30 20:33:05
|
Hi Peter Thanks for the advice. That seems to solve the problem. However, I have a few more questions and suggestions On Wed, Aug 29, 2012 at 3:19 AM, Peter Bigot <bi...@ac...> wrote: > Use '-mmemory-model=large' instead of the underlying flags and your > code should work. (In fact, use -mmemory-model=medium unless you need > code in far memory: due to limitations in gcc that I've mentioned > before certain optimizations get disabled when sizeof(void*) != > sizeof((*)(void)), which only holds when -md20 != -ma20.) > > The memory model large does the correct placement and code generation. However, since it implicitly converts all the instructions to 20 bit variant, which causes significant overhead. I did some experiments and I see almost 15% increase in code size and 50% increase in runtime. This is quite critical for our application. Secondly, memory-model medium errors out since it doesn't include -md20 flag. So that option though may reduce overhead, doesn't work! My task requirements are simple. I need to put multiple LUTs in the far memory (because of the size) and I had just one function accessing it to copy the data to temporary local variables. The overhead seems way too much for that. Here's what I did to get it to work and the problems encountered. It seems that only the placement of the code is a problem in the memory. I can manually change that by adding a section(".far.rodata") attribute along with the __d20__ attribute. This places the code correctly and the pointer is correctly made taken to be 20 bits, even without any memory related compilation flags. I can then use a small assembly routine (similar to the btstack flash memory access function) to copy the data. However, I need the pointers to all my LUTs accessible in a single pointer array. Here are the problems associated with this. I'm not sure if these are bugs/enhancement requests 1. The pointer array would need the underlying type __a20__. The compiler errors out saying that __a20__ cannot be applied to *[10] type element. 2. I tried to make the array as uint32_t and keeping the addresses in the array. From the assembly code generated, it seems that the compiler retains the 20 bits only for the first move and discards it in the later stages. This seems like a bug. My workaround was to write assembly code for this operation as well. Here's a small example of where the error comes. A program of type const char abc[5] __attribute__((__d20__, section(".far.rodata"))) = {1, 2, 3, 4, 5}; const char bcd[5] __attribute__((__d20__, section(".far.rodata"))) = {1, 2, 3, 4, 5}; uint32_t add[2]; void main() { add[0] = abc; add[1] = bcd; } Gets converted into the assembly as (only the first part) 5c3e: 3e 40 00 1c mov #7168, r14 ;#0x1c00 5c42: 8f 01 05 00 mova #0x10005,r15 5c46: 8e 4f 00 00 mov r15, 0(r14) ;0x0000(r14) // ok till here 5c4a: 8f 10 swpb r15 //this kills the higher order bits 5c4c: 8f 11 sxt r15 5c4e: 8f 10 swpb r15 5c50: 8f 11 sxt r15 5c52: 8e 4f 02 00 mov r15, 2(r14) ;0x0002(r14) I can workaround this by simply using __asm__ __volatile__ ("movx.a %0, %1\n"::"i"(abc), "m"(add[0])); This seems like something the compiler should be able to do! I would like to just verify with you if you see any problems with the way these things have been handled. The code seems to work fine for now, but I cannot guarantee correctness. Thanks for all your help Shalabh > As it turns out, though my intent was that compilation would be > determined solely by the -mX20 flags, the text of > > > https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design#memmodel > > is partially correct in its statement that if you leave the default > memory model at "none", everything is assumed to be 16-bit. There is > exactly one use of the -mmemory-model flag in mspgcc, and what that > use does is force data into the default region. > > I'm not sure yet whether this is going to be a bug or a documentation > change. It's now recorded as 3562647 for future review. > > Peter > > > On Tue, Aug 28, 2012 at 11:33 PM, Shalabh Jain <sha...@gm...> > wrote: > > Hi, > > > > I recently installed the 20120716 release (following the instructions in > > the readme and wiki). The installation seems fine as I can compile and > > correctly run the my code from v4.6. > > > > My chip is msp430f5438a on the experimenter board. > > > > I would like to put a lookup table in the far memory region. I was > testing > > some simple code using the __far__ attribute, but the code seems to be > > getting placed in the near region. I'm sure I'm missing something silly. > > Can somebody please help. (Note: The code is not mean to produce anything > > meaningful. I simply need to see if the memory assignment is happening > > correctly, for which I am using msp430-objdump > > > > My sample code > > > > #include <stdio.h> > > #include "sj.h" > > /* contains an initialized array declared as > > const char kuttest[30000] __attribute__((__far__)) = > > { 1, \ > > 2, \ > > 2, \ > > 2, \ > > 2, \ > > 2, \ > > ... > > }; > > > > int putchar(int c) {return 0;} > > > > void main() { > > int res; > > const char * __attribute__((__a20__)) abc = kuttest; > > for(res = 0; res < 10; res++) > > printf("%x abc", *(abc+res)); > > } > > > > I am compiling this will the most conservative options > > msp430-gcc-4.7.0 -mmcu=msp430f5438a -md20 -msr20 -mdata-region=far -mc20 > > -mcode-region=far fardata.c -Wall -o fardata > > > > The code compiles fine (with the warning about main return type not being > > int). > > The objectdump shows me > > > > Disassembly of section .rodata: > > > > 000066d6 <kuttest>: > > 66d6: 01 02 mova #4, r1 ;r2 As==10 > > 66d8: 02 02 mova #4, r2 ;r2 As==10 > > 66da: 02 02 mova #4, r2 ;r2 As==10 > > 66dc: 02 02 mova #4, r2 ;r2 As==10 > > 66de: 02 02 mova #4, r2 ;r2 As==10 > > 66e0: 02 02 mova #4, r2 ;r2 As==10 > > 66e2: 02 02 mova #4, r2 ;r2 As==10 > > 66e4: 02 02 mova #4, r2 ;r2 As==10 > > > > The variable is not in the far address space. > > > > Any help is appreciated. > > > > Thanks a lot > > > > Shalabh > > > > > ------------------------------------------------------------------------------ > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Mspgcc-users mailing list > > Msp...@li... > > https://lists.sourceforge.net/lists/listinfo/mspgcc-users > > > |