----- 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.

> The following seems to work..  And is simpler...
>  void set_dma0sa(uint32_t addr) {
>    __asm__ __volatile__ ("movx.a %1,%0":"=3Dm" (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=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.
I don't know whether there is a constraint for Address values (20 bit),
at least there is none documented.
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

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

Reply via email to