Hi Peter and JM (again) thanks again for the instructions on how to put and access data in the upper banks. And with the trick of getting the address from inline ASM I could even have multiple tables up there.
I'll try later if the array bound with my > 32 KB array comes from the address offset (as suggested be Peter), or by array index (as explained by JM) :) As I said, I'll have to use the inline function to access the data anyway, and by that can address the complete table already. Best Matthias Begin forwarded message: > From: Peter Bigot <big...@acm.org> > Date: 18. April 2011 23:10:44 MESZ > To: Matthias Ringwald <matth...@ringwald.ch> > Cc: JMGross <msp...@grossibaer.de>, mspgcc-users@lists.sourceforge.net > Subject: Re: [Mspgcc-users] Accessing data over 64K > > 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; >>>> } >> >> Begin forwarded message: > From: "JMGross" <msp...@grossibaer.de> > Date: 19. April 2011 13:45:00 MESZ > To: "matth...@ringwald.ch" <matth...@ringwald.ch> > Cc: mspgcc-users@lists.sourceforge.net > Subject: Re: [Mspgcc-users] Accessing data over 64K > Reply-To: mspgcc-users@lists.sourceforge.net > > Hi Matthias, > > ----- Ursprüngliche Nachricht ----- > Von: Matthias Ringwald > An: Peter Bigot; JMGross > Gesendet am: 18 Apr 2011 22:28:41 > >> I guess that adding a "nop" after the Clear GIE won't hurt. > I'd be surprised, if. :) > >> 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. > > There is, with a trick: > > First, you need to place the array in the uppe rmemory. > On mspgcc3.2.3, I did it by placinf the dat ainto the .fartext segment > manually: > > const char __attribute__ ((section(".fartext"))) > fardata[128]={9,8,7,6,5,4,3,2,1,0}; > > Then you can use the asm instruction to 'fetch' it into a long variable: > > unsigned long int longvar; > __asm__ __volatile__ ( "movx.a %1,%0":"=m"(longvar):"i"(fardata)); > > While the 'i' fails for constants, it works fine for everything that is > resolved at link stage. > The linker inserts the 20 bit value properly into the instruction and the > compiler > (not knowing that there could be a 20 bit reference) doesn't put an #llo() > around it. > Here the 'lazyness' of the programmer finally produces something good :) > > but be careful: the linker does not complain when the assembly instruction > does not take 20 bit operands. It will silently cut off the upper 4 bits then. > >> 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? > > As Peter already explained, this is because of the internal usage of signed > ints for the index. (yes, an index into an array can be negative, even if > nobody ever uses it). > So the maximum index value is 32767, which means 32768 elements. > Without 20 bit poitners, you could never reach element #32769. > > JMGross > ------------------------------------------------------------------------------ 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
