On Thu, Apr 14, 2011 at 4:20 PM, Peter Bigot <big...@acm.org> wrote:
> uniarch mspgcc does not support 20-bit operations,
I know uniarch currently doesn't support 20 bit. That is why I'm using
3.2.3 with
the z1 mods. This supports some msp430X stuff correctly some not so much.
But I'm messing with gnu extended asm and that is what the question is
about.
> including
> generation of immediate values. You can fake it by putting a constant
> into the output template, but not a variable. Use -S to see what's
> really generated.
>
> Something like the following might work; it could certainly be improved.
>
> #include <msp430.h>
>
> void f (unsigned long addr)
> {
> unsigned int v1 = 0xF000 & (addr >> 4);
> unsigned int v2 = 0xFFFF & addr;
> __asm__ (
> "mov %1, r14\n"
> "rlam.a #4, r14\n"
> "bisx.a %2, r14\n"
> "movx.a r14, %0"
> : "=m" (DMA0SA)
> : "m" (v1), "m" (v2));
> }
>
The following seems to work.. And is simpler...
void set_dma0sa(uint32_t addr) {
__asm__ __volatile__ ("movx.a %1,%0":"=m" (DMA0SA):"m" (addr));
}
but does use 4 bytes on the stack.
(unoptimized)
void set_dma0sa(uint32_t addr) {
3b90: 21 82 sub #4, r1 ;r2 As==10
3b92: 81 4e 00 00 mov r14, 0(r1) ;0x0000(r1)
3b96: 81 4f 02 00 mov r15, 2(r1) ;0x0002(r1)
__asm__ __volatile__ ("movx.a %1,%0":"=m" (DMA0SA):"m" (addr));
3b9a: 00 18 e2 41 d2 01 movx.a @r1, &0x001d2
3ba0: 21 52 add #4, r1 ;r2 As==10
3ba2: 10 01 reta
>
>
> On Thu, Apr 14, 2011 at 5:25 PM, Eric Decker <cire...@gmail.com> wrote:
> > Anyone know how to get 20 bit immediate in gcc extended asm?
> >
> > ie.
> >
> > __asm__ __volatile__ ("movx.a %1,%0":"=m" (DMA0SA):"i" (0xefefeUL));
> >
> > which unfortunately generates...
> >
> > __asm__ __volatile__ ("movx.a %1,%0":"=m" (DMA0SA):"i" (0xefefeUL));
> > 3b12: 00 18 f2 40 fe fe d2 01 movx.a #65278,
> > &0x001d2;#0x0fefe
> >
> > Can the msp430X instruction set even access a 20 bit immediate field?
> >
> > Or do I have to initialize a long in memory first then load it using
> movx.a?
> >
> >
> > eric
> >
> >
> > On Wed, Apr 13, 2011 at 12:23 PM, JMGross <msp...@grossibaer.de> wrote:
> >
> >>
> >> ----- Ursprüngliche Nachricht -----
> >> Von: Eric Decker
> >> Gesendet am: 13 Apr 2011 15:00:48
> >>
> >> > Do you perhaps have a code snipet of access to a 20 bit register?
> Say
> >> > DMA0SA for example.
> >> > I love working examples.
> >>
> >> Not for the DMA. I don't use assembly here as I (yet) never had to deal
> >> with a source or destination above 64k.
> >> But I have something I wrote for accessing upper flash as data storage.
> >>
> >> static inline unsigned char FlashReadByte (unsigned long address){
> >> unsigned char result;
> >> unsigned int sr, flash;
> >> __asm__ __volatile__ ("mov r2,%0":"=r"(sr):);
> >> // save SR before disabling IRQ
> >> _DINT();
> >> __asm__ __volatile__ ("movx.a %1,%0":"=r"(flash):"m"(address));
> >> __asm__ __volatile__ ("movx.b @%1, %0":"=r"(result):"r"(flash));
> >> __asm__ __volatile__ ("mov %0,r2"::"r"(sr));
> >> // restore previous SR and IRQ state
> >> return result;
> >> // aligned address -> low-byte contains result
> >> }
> >>
> >> >> asm("movx.a %1, %0":"=m"(destination):"m"(source));
> >>
> >> > When would one use the
> >>
> >> > asm("movx.a %1, %0":"=m"(destination):"m"(source));
> >>
> >> > form. I'm confused as to what to put in for destination and source
> >> > and how this can reference 20 bit registers while still obstensibly
> >> > refering to memory locations.
> >>
> >> > Or is the above a 20bit memory to memory move? And if
> >> destination/source
> >> > are in registers, gcc will
> >> > still do the right thing, doing a 20 bit move. Is that correct?
> >>
> >> Yes. Peripheral registers are jsu tmemory locations.
> >> And by using the 'm' qualifier, I tell the compiler to provide the
> >> parameters given in the brackets (normal C symbols) in a memory
> >> location and substitute the placeholders %0 and %1 by the proper
> >> value/symbol and addressing mode. If needed, the compiler will
> >> put the values on stack right before the asm statement and use a #0(SP)
> >> addressing mode or something similar. However, the compiler does not
> >> check nor know whether this addressing mode is available for the
> >> instruction.
> >> And sometimes you still have to trick a bit.
> >>
> >> In the above
> >> "movx.b @%1, %0":"=r"(result):"r"(flash)
> >> I tell the compiler that I expect the value flash in a register
> >> and then let the compiler put the register name behind the @ for an
> >> indexed access.
> >>
> >> And in the following line (from a block copy function)
> >> __asm__ __volatile__ ("movx %0, @%1"::"m"(*source),"r"(flash));
> >> I tell the compiler to provide a memory access to the value source
> points
> >> to.
> >> The compiler generates
> >> 302 008a 4018 AF49 movx @r9, @r15
> >> where R9 is the compiler-chosen place for the source pointer (which I
> >> later increment with
> >> __asm__ __volatile__ ("incd %0":"=r"(source):"0"(source));
> >> (the"0" means same operand and type from the first destination is also
> the
> >> source)
> >>
> >> It's rather complex and sometimes irritating, yet really powerful.
> >>
> >>
> >> > I've read a bit out on the web and that has helped. But I find to
> >> > really learn it requires examples
> >> > which aren't very plentiful in the tinyos msp430 code.
> >>
> >> Indeed, the most examples are rather x86 specific and the mspgcc
> >> decumentation
> >> is no real help for learnign the msp specific implementation.
> >>
> >> >> Yep. in mspgcc, those registers are defined using sfra macro, but
> this
> >> only
> >> >> defines them as volatile unsigned long word. The compilers default
> >> action
> >> >> will be a normal 2*16 bit access.
> >>
> >> >That is what I'm seeing. If I try to write say DMA0SA (defined using
> sfra
> >> >as a ulong) it generates a write to the low 16 which behaves
> >> >fine (including a zero of the upper bits) and then a write to the upper
> >> >which doesn't do anything.... (both using simple mov (16 bit)
> >> >instructions).
> >>
> >> Yes, the sfra macro is mostly useless for register declarations.
> >> But maybe once the compiler natively supports 20 bit instructions,
> >> teh macro might be altered / extended with an additional qualifier
> >> which tells the compiler to do a 20 bit access instead of 2*16.
> >> maybe for register variables too
> >>
> >> But it is a long way to go. Once you use 20 bit registers and 20 bit
> >> data access, you also need to save and restore registers on 20 bit.
> >> Which enlarges the push/pop and complicates many other things
> >> Hence the DINT in the code above. To avoid the ISRs
> >> clearing my upper 4 bits.
> >>
> >>
> >> >> BTW: the DMA config registers (with the DMA triggers) are 16 bit
> acess
> >> >> only. The original documentation as well as the TI defines provided
> _L
> >> and
> >> >> _H aliases which didn't work (which was the original reason that
> >> >> brought me to the E2E community.
> >>
> >> >I figured that out the hard way. I came up with an algorithm for
> dealing
> >> >with the differences between the x2 and x5 dma engines but it involved
> >> >referenceing the trigger control words as bytes (which is implied by
> the
> >> >existence of _L and _H definitions). But it didn't work.
> >>
> >> Same for me. That was the reason why I joined the TI E2E community.
> >> Yet nobody there could help me, so I too figured it out myself.
> >> And later they changed the documentation because of my 'discovery'.
> >> Well, now I'm one of the four gurus there and contributor of the year
> 2010.
> >> With free lifetime supply of all MSP related tools. It was worth the
> sweat
> >> :)
> >>
> >> > At least on the 2617 part (x2) anything in the 0x01xx address space
> MUST
> >> be
> >> > referenced using 16 bit references. I'm pretty sure that anything in
> >> the 8
> >> > bit I/O area has to be referenced using byte instructions. I'm fairly
> >> > confident about that. But verification would be good.
> >>
> >> Yes, the 8 bit I/O is only connected to the lower 8 bit of the data bus,
> >> while the 16 bit I/O has the LSB of the address bus unconnected.
> >>
> >> > Does the 5438 behave the same way?
> >> No. It does not have any 8 or 16 bit I/O area anymore.
> >> It depends on the individual module how it is connected to the
> >> address and data bus. Sometimes both things work, sometimes
> >> only 8 or only 16 bit.
> >> e.g. in teh system module, you can write 8 bit to the password part
> >> of the first register and then do 8 or 16 bit accesses to any
> >> module register without password. THen you write a wrong password
> >> and all is locked again. Or you do a direct 16 bit write including the
> >> password.
> >>
> >> > Also Jens, what tool chain are you using on the 5438 to access high
> ROM?
> >>
> >> My own functions. Like the one above.
> >> I don't put code there (my projects are way smaller than the 40k flash
> >> below
> >> 64k, especially if I can put tables above)
> >> I use 64k to 128k as backup space for uploadign new firmware versions
> >> through the existing firmware and their communicaitons channels,
> >> then I copy the complete firmware down to <64k.
> >> The area above 128k is free for data tables and text strings (which
> >> need to be copied down to ram before being used with printf).
> >> Below, I don't use any 430X mode for the compiler.
> >>
> >> I modified the linker scripts to provide separate segments in the
> extended
> >> flash
> >> and manually put the table sthere with the segment attribute.
> >> Works fine.
> >> The compiler I use is still the old mspgcc3 (last windows build).
> >> However, for flashing I need to use the (free) elprotronic tool, as
> >> msp430-jtag
> >> cannot address the 54xx at all due to the changed jtag protocol.
> >>
> >>
> >> > My understanding is the differences between the cores (2617 vs. 5438)
> is
> >> in
> >> > instruction timings. The big differences are
> >> > in the way port addressing is done (willy nilly vs. base registers)
> and
> >> > interrupt mapping. The 5438 makes a bunch more sense.
> >> > And it looks like they moved the I/O space into normal memory so it
> >> behaves
> >> > consistently. But I haven't played with it yet.
> >>
> >> Yes. The memorty space has been unified and the interrupt handling is
> more
> >> consistent. Module enabling and interrupt flags have moved into the
> module
> >> registers and the interrupt vectors have been cleaned up a bit
> (especially
> >> for the USCI)
> >>
> >>
> >> > Right now I am testing the unified dma driver I wrote. The driver
> >> > rrently is 16 bit only and will stay that way for the time
> >> > being. Not too much call for DMAing into high ROM. But I got
> curious
> >> > about how the 20 bit support works.
> >>
> >> Same here for my DMA module. Well, perhaps when sending a stored
> >> webpage or image from flash to an SPI display or such...
> >>
> >> > All I can say is TI makes damn good h/w, great low power stuff etc.
> But
> >> > they have always really really really screwed up system architecture.
> >> The
> >> > 5438 architecture is much much improved.
> >>
> >> Ever worked with a PIC? THAT's s screwed system architecture.
> >>
> >> > But this 20 bit stuff with the msp430 isn't doing much to change
> >> > my opinion on the matter.
> >>
> >> They wanted it downward compatible as much as possible.
> >> It's always a problem when expanding past 16 bit address bus but wanting
> >> to stay a fast 16 bit processor.
> >> Well, the PICs I used were 14 bit processors :)
> >>
> >> > And their documentation.... well.
> >> > TI has always been painfull to use.
> >>
> >> It's not that bad, really. I've seen much worse. The problem is that you
> >> need
> >> to figure out the modular philosophy behind their document structure.
> >> Once you've gotten used to it, you'll find everything you need. Mostly.
> >>
> >> > I been doing
> >> > computers well before there were tiny little computers and used TI
> stuff
> >> > very early on, like when they first got into computers.
> >>
> >> Remember the TI99/4a? I loved to play Tombstone City on it.
> >>
> >> > From what I've seen not much has changed.
> >> > But the 5438 looks much improved from previous iterations.
> >>
> >> Definitely.
> >>
> >> > but the DMA might differ.
> >>
> >> perhaps, a bit. But it's great to have DMA at all.
> >> And you can do really nice things with it besides just
> >> shuffling data.
> >> Including auto-reprogramming of comm modules, math
> >> algorithms (with the hardware multiplyier) and other things.
> >> What I'm missing is
> >> 1) more DMA channels (3 is not enough for some ideas I have)
> >> 2) a way to program the DMA using DMA :)
> >> 3) two-step transfers: reading from a 16 bit source and do two
> >> 8-bit writes. However, if the 16 bit source can be read in two 8
> >> bit reads (and many can), then this can be done aleady.
> >> 4) more possible triggers.
> >>
> >>
> >> JMGross
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Forrester Wave Report - Recovery time is now measured in hours and
> minutes
> >> not days. Key insights are discussed in the 2010 Forrester Wave Report
> as
> >> part of an in-depth evaluation of disaster recovery service providers.
> >> Forrester found the best-in-class provider in terms of services and
> vision.
> >> Read this report now! http://p.sf.net/sfu/ibm-webcastpromo
> >> _______________________________________________
> >> Mspgcc-users mailing list
> >> Mspgcc-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
> >>
> >
> >
> >
> > --
> > Eric B. Decker
> > Senior (over 50 :-) Researcher
> >
> >
> ------------------------------------------------------------------------------
> > 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
> >
> >
>
--
Eric B. Decker
Senior (over 50 :-) Researcher
------------------------------------------------------------------------------
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
