If you're using mspgcc4 or uniarch mspgcc, there is no data stored above 64KB, because there's no way to put it there[*]. So there's no address to get. When 20-bit support is available you'll use & just like normal.
Re 32k arrays: You've rediscovered https://sourceforge.net/tracker/?func=detail&aid=3152354&group_id=277223&atid=1177287. My suspicion is it's a limitation due to gcc believing the address space is limited to 16 bits, but I haven't had a chance to look into it. Peter [*] Unless you're using a section attribute to stick it in far memory, in which case it looks like the stuff below might work with mspgcc4. I apparently removed fartext in the uniarch binutils rework. unsigned char table[] __attribute__ ((section(".fartext"))) = { 1,2,3,4 }; unsigned long int table_address () { unsigned long int addr; __asm__ ("movx.a #table, %0" : "=m" (addr)); return addr; } Peter On Mon, Apr 18, 2011 at 3:28 PM, Matthias Ringwald <matth...@ringwald.ch> wrote: > Hi Peter & JM > > thanks for the help. I can confirm that the version below, with a single > inline asm instruction works as expected/hoped for. I guess that adding a > "nop" after the Clear GIE won't hurt. > > Another question: Is there a way to get the address of data stored above > 64kB? For now, I'm fine just assuming that my table starts at 0x10000, but if > there would be multiple tables I would need to calculate other addresses by a > series of sizeof() operations. > > Finally, a maybe related one: I got an error trying to declare an array with > over 32k bytes/items. In my code, I can also split it into two arrays and > access them one after another, or, even assume that there's no padding bytes > in the middle, directly use FlashReadByte function. What's the reason for the > limitation? Is this a consequence of the 16-bit architecture? > > Best > Matthias > > On 18.04.2011, at 16:51, Peter Bigot wrote: > >> Doesn't there need to be a nop between the clear of GIE and the >> following move? The DINT instruction description in the manual >> implies that without it the interrupt could still occur during the >> first movx. >> >> Peter >> >> On Mon, Apr 18, 2011 at 9:27 AM, JMGross <msp...@grossibaer.de> wrote: >>> extern inline __attribute__((always_inline)) unsigned char FlashReadByte >>> (unsigned long addr){ >>> unsigned char result; >>> unsigned int register sr, flash; >>> __asm__ __volatile__ ("mov r2 , %1 \n" >>> "bic %3 , r2 \n" >>> "movx.a %4 , %2 \n" >>> "movx.b @%2, %0 \n" >>> "mov %1 , r2 \n" >>> :"=X"(result),"=r"(sr),"=r"(flash) >>> :"i"(GIE),"m"(addr)); >>> return result; >>> } > > ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
