thanks. appreciated.
On Fri, Apr 15, 2011 at 7:12 AM, JMGross <msp...@grossibaer.de> wrote:
> ----- Ursprüngliche Nachricht -----
> Von: Eric Decker
> Gesendet am: 15 Apr 2011 05:38:43
>
> > 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.
>
> I don't know about z1 mods, but I too use 3.2.3 (Windows build from 12/08)
> It has worked for me so far. (well, I found two bugs, but there was an
> easy workaround)
> If your version is newer/mor improved and available for windows,
> please tell me where to get it.
>
It is a modified 3.2.3. Not sure what the mods are but it has been built
with the MSP430X mods. It definitely supports the 2616-2619. The
--target-help also
lists 5xxx processors but the little bit I've looked at says it doesn't work
right. I don't remember the details.
Peter has built a gcc4 based msp430 that does support the 5xxx processors
but GCC4 is much different from GCC3 so the X mods are really ugly. I tried
to do it at one point and gave up. It is really different.
Anyway Peter is doing the uniarch stuff which looks pretty good so far and
thinks he will get to the 20 bit support in a month or so.
Anyway the Z1 toolchain is buried in:
wget
http://sourceforge.net/projects/zolertia/files/tinyos-z1-2.1.1/tinyos-z1-2.1.1-15_i386.deb
sudo dpkg -i tinyos-z1-2.1.1-15_i386.deb
you know how to use deb's ?
It has tinyos bits from Z1 as well but the toolchain is in /opt/msp430-z1.
I got sick of working on windows a while ago so do everything on a Linux
box. Not sure how to mess with this stuff on a windows box.
The good stuff is happening in uniarch... If you really do want the z1
stuff I can extract the stuff out and tar ball it. I would need a place to
put it that you can nab it from.
let me know if you want me to do that...
> The following seems to work.. And is simpler...
> > void set_dma0sa(uint32_t addr) {
> > __asm__ __volatile__ ("movx.a %1,%0":"=3Dm" (DMA0SA):"m" Any(addr));
> > }
> > but does use 4 bytes on the stack.
> > (unoptimized)
> > void set_dma0sa(uint32_t addr) {
> > 3b90: 21 82 sub #4, r1 ;r2 As=3D=3D10
> > 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":"=3Dm" (DMA0SA):"m" (addr));
> > 3b9a: 00 18 e2 41 d2 01 movx.a @r1, &0x001d2
> > 3ba0: 21 52 add #4, r1 ;r2 As=3D=3D10
> > 3ba2: 10 01 reta
>
> In the above case, the addr value is on registers, so the compiler puts it
> to memory first. The asm statement will, however, still work if addr is
> already on a memory location (low mem).
> Even if it is passed by reference, "m"(*addr) will do it right then
> (as long as addr is a 16bit pointer)
> However, the used way to push the value on stack seems a bit clumsy.
> Two pushes would do the same but spare 6 bytes and 3 cycles.
> But if this simple operation is a function rather than a macro (or
> inlined),
> those wasted bytes and cycles do not seem to make much of a difference.
> (well, I know, this is just test code :) )
>
> I just tested an immediate value and the compiler generated the following:
>
> __asm__ __volatile__ ("movx.a %1,%0":"=m" (P1DIR):"m" (123456L));
>
> 1686 .p2align 1,0
> 1687 .LC17:
> 1688 01a2 40E2 0100 .long 123456
> [...]
> 1712 .LM200:
> 1713 /* #APP */
> 1714 000c 0018 D242 movx.a &.LC17,&0x200 + 0x04
> 1714 0000 0402
>
> Which seems to be correct.
>
> However, when trying to use an immediate value as such (not with the
> memory constraint), things seem to go wrong:
> __asm__ __volatile__ ("movx.a %1,%0":"=m" (P1DIR):"i" (123456L));
> Of course, the 'i' contraint extracts the lower 16 bit only, as it means a
> 16 bit immediate value (short int). The compiler is implicitely generating
> a "#llo(123456L)", which cuts off the upper bits.
>
well if "i" means 16 bit immediate then I have to say it is doing the right
thing. But is there somewhere this is documented?
I looked at the mspgcc manual under gcc extended asm syntax and it isn't
clear how it works.
20 bit stuff isn't sorted out. So not sure what that should look like.
I don't know whether there is a constraint for Address values (20 bit),
> at least there is none documented.
Right now it looks like 16 bit chunks are handled reasonably, low and high
parts
as long as they are 16 bits.
20 bit support is kind of odd so it will have to be added in in some fashion
when
Peter adds 20 bit support to uniarch. 20 bit chunks impact the
instruction because
the 16 bits show up one place and the other 4 bits a bit earlier in the
instruction.
The assembler handles it but the gcc would need to know that a 20 bit chunk
is
being dealt with. Probably not a big deal once the right place to tweak is
found.
However, if the immediate value is a number constant and no symbol
> or (macro) parameter, one can simply put it directly into the instruction
> and the assembler will handle it correctly.
>
> Also, I can imagine a macro that assembles the whole ASM instruction
> in a way that (long) macro constants can be used as parameter.
> It isn't trivial, since the preprocesor won't touch strings and the
> assembly instruction is a string. So it needs to be assembled and
> then 'stringized'. Doable, but not trivial.
>
>
> BTW: A nice introduction to the extended assembly syntax is found at
> http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html
>
>
thanks appreciated.
eric
> 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
>
--
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
