I have one question regarding MSP430F2131 instructions execution times.

According to slau144d.pdf section 3.4.4, double operand instructions
in addressing mode #N,&EDE uses 5 cycles.

For example, following code would generate negative pulse on P2.5.
Pulse would be 5 MCLK periods wide because those instructions consumes
5 CPU cycles.

bic.b #BIT5,&P2OUT
bis.b #BIT5,&P2OUT

But if you try to generate negative pulse on P2.2, using similar code,
that pulse would be only 4 MCLK periods wide instead of 5 MCLK periods.

bic.b #BIT2,&P2OUT
bis.b #BIT2,&P2OUT

This is behavior which is not documented in slau144d.pdf and errata sheet.

Please may someone try this code and verify my observations. I found
that shorter execution time occurred only if you set/clear single bit
in lower nibble.

Goran
Start a New Thread

Hello!

I remember that there is a trick when assigning a value less than xxx (I don't
remember, I think it is 16 but I have no documents at hand). It is explained in
detail in the MSP assembler doc and search for "short constants".
And if you look at the exec code, you will notice that the hardware instruction
(not the assembler, the code) is different if you assign a constant which is more
or less than 16.

Pascal

--- In m..., "gorandragisic" wrote:
>
> I have one question regarding MSP430F2131 instructions execution times.
>
> According to slau144d.pdf section 3.4.4, double operand instructions
> in addressing mode #N,&EDE uses 5 cycles.
>
> For example, following code would generate negative pulse on P2.5.
> Pulse would be 5 MCLK periods wide because those instructions consumes
> 5 CPU cycles.
>
> bic.b #BIT5,&P2OUT
> bis.b #BIT5,&P2OUT
>
> But if you try to generate negative pulse on P2.2, using similar code,
> that pulse would be only 4 MCLK periods wide instead of 5 MCLK periods.
>
> bic.b #BIT2,&P2OUT
> bis.b #BIT2,&P2OUT
>
> This is behavior which is not documented in slau144d.pdf and errata sheet.
>
> Please may someone try this code and verify my observations. I found
> that shorter execution time occurred only if you set/clear single bit
> in lower nibble.
>
> Goran
>

Start a New Thread

You need to study the execution times, CPu operation and register use
more thoroughly. this is a very complex area on the MSP430. What is
happening is that certain bits correspond to values provided by the CG
registers, so that in fact what you THINK is #N, &EDE is in fact
Rm(CG),&EDE, which, if my aging memory serves me well, executes in 4
cycles.

Cheers

Al

gorandragisic wrote:

>I have one question regarding MSP430F2131 instructions execution times.
>
>According to slau144d.pdf section 3.4.4, double operand instructions
>in addressing mode #N,&EDE uses 5 cycles.
>
>For example, following code would generate negative pulse on P2.5.
>Pulse would be 5 MCLK periods wide because those instructions consumes
>5 CPU cycles.
>
>bic.b #BIT5,&P2OUT
>bis.b #BIT5,&P2OUT
>
>But if you try to generate negative pulse on P2.2, using similar code,
>that pulse would be only 4 MCLK periods wide instead of 5 MCLK periods.
>
>bic.b #BIT2,&P2OUT
>bis.b #BIT2,&P2OUT
>
>This is behavior which is not documented in slau144d.pdf and errata sheet.
>
>Please may someone try this code and verify my observations. I found
>that shorter execution time occurred only if you set/clear single bit
>in lower nibble.
>
>Goran
> Start a New Thread

Hi,

> -----Original Message-----
> From: m... [mailto:m...] On Behalf Of
> gorandragisic
> Sent: 14 October 2008 23:07
> To: m...
> Subject: [msp430] Shorther instruction execution time than documented
>
> I have one question regarding MSP430F2131 instructions execution times.
>
> According to slau144d.pdf section 3.4.4, double operand instructions
> in addressing mode #N,&EDE uses 5 cycles.
>
> For example, following code would generate negative pulse on P2.5.
> Pulse would be 5 MCLK periods wide because those instructions consumes
> 5 CPU cycles.
>
> bic.b #BIT5,&P2OUT
> bis.b #BIT5,&P2OUT
>
> But if you try to generate negative pulse on P2.2, using similar code,
> that pulse would be only 4 MCLK periods wide instead of 5 MCLK periods.
>
> bic.b #BIT2,&P2OUT
> bis.b #BIT2,&P2OUT
>
> This is behavior which is not documented in slau144d.pdf and errata sheet.
>
> Please may someone try this code and verify my observations. I found
> that shorter execution time occurred only if you set/clear single bit
> in lower nibble.

The constants BIT0, BIT1 etc are 1, 2, 4. These can be encoded using the
constant generator and the instruction is only two words in width, not three
words.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Start a New Thread

The MSP430 chip does take exactly the number of clocks to execute each
instructions as documented. You have been out-smarted by the
assembler. It has its own mind and ignores what your source code says.

--- In m..., "gorandragisic" wrote:
>
> I have one question regarding MSP430F2131 instructions execution times.
>
> According to slau144d.pdf section 3.4.4, double operand instructions
> in addressing mode #N,&EDE uses 5 cycles.
>
> For example, following code would generate negative pulse on P2.5.
> Pulse would be 5 MCLK periods wide because those instructions consumes
> 5 CPU cycles.
>
> bic.b #BIT5,&P2OUT
> bis.b #BIT5,&P2OUT
>
> But if you try to generate negative pulse on P2.2, using similar code,
> that pulse would be only 4 MCLK periods wide instead of 5 MCLK periods.
>
> bic.b #BIT2,&P2OUT
> bis.b #BIT2,&P2OUT
>
> This is behavior which is not documented in slau144d.pdf and errata
sheet.
>
> Please may someone try this code and verify my observations. I found
> that shorter execution time occurred only if you set/clear single bit
> in lower nibble.
>
> Goran
>

Start a New Thread

Thank you all for posts. You are right. I see that the problem is in
my assembler. I am using IAR EW430 KickStart V4.10E.

When I looked at listing file I have noticed that assembler, without
any notice, change address mode to Register mode using constant
generator in such way that the instruction performs the same operation.

Side effects are that code is smaller and execution time is shorter.
Both are welcome in most cases, but makes problem if someone wants to
make code with precise execution timing and must count execution cycles.

I don't know why IAR makes such code optimization in assembler? It
would be much better if they perform 1:1 assembly and leave
optimization to programmer.

Goran

--- In m..., "old_cow_yellow"
wrote:
>
> The MSP430 chip does take exactly the number of clocks to execute each
> instructions as documented. You have been out-smarted by the
> assembler. It has its own mind and ignores what your source code says.
>
> --- In m..., "gorandragisic" wrote:
> >
> > I have one question regarding MSP430F2131 instructions execution
times.
> >
> > According to slau144d.pdf section 3.4.4, double operand instructions
> > in addressing mode #N,&EDE uses 5 cycles.
> >
> > For example, following code would generate negative pulse on P2.5.
> > Pulse would be 5 MCLK periods wide because those instructions consumes
> > 5 CPU cycles.
> >
> > bic.b #BIT5,&P2OUT
> > bis.b #BIT5,&P2OUT
> >
> > But if you try to generate negative pulse on P2.2, using similar code,
> > that pulse would be only 4 MCLK periods wide instead of 5 MCLK
periods.
> >
> > bic.b #BIT2,&P2OUT
> > bis.b #BIT2,&P2OUT
> >
> > This is behavior which is not documented in slau144d.pdf and errata
> sheet.
> >
> > Please may someone try this code and verify my observations. I found
> > that shorter execution time occurred only if you set/clear single bit
> > in lower nibble.
> >
> > Goran
>
Start a New Thread

Hi!

Goran wrote:
> I don't know why IAR makes such code optimization in assembler? It
> would be much better if they perform 1:1 assembly and leave
> optimization to programmer.

We do that kind of optimization because 1) the MSP430 manual says that
is the way an assembler should work, and 2) that is what the user wants
in 99.9% of the cases.

What I would like to see is some kind of extended syntax that would
allow a user to explicitly specify the format. Typically, this could be
:S or :L for the different sizes. For example, this could look like the
following:

bic.b #BIT5:L,&P2OUT

However, we don't want to walk this line alone -- we need support from
TI and the other tool vendors so that we don't end up with something
that might be in conflict with future TI extensions.

-- Anders Lindgren, IAR Systems
--
Disclaimer: Opinions expressed in this posting are strictly my own and
not necessarily those of my employer.

Start a New Thread

Hi Anders,

> What I would like to see is some kind of extended syntax that would
> allow a user to explicitly specify the format. Typically, this could be
> :S or :L for the different sizes. For example, this could look like the
> following:
>
> bic.b #BIT5:L,&P2OUT
>
> However, we don't want to walk this line alone -- we need support from
> TI and the other tool vendors so that we don't end up with something
> that might be in conflict with future TI extensions.

I think we're all in conflict with CCE's assembler that assembles MSP430X
multi-bit shift instructions... I did bring this up with Horst, having the
same instruction assemble to *two* different encodings on EW and CCE and
wondered which would be more correct. The IAR encoding was certainly
correct and shorter. So, before moving forward with extensions we should
argue over the correct encoding of MSP430X instructions by the assembler!

Here's the guts of that e-mail:

** RRUX.W R15

Code Composer generates this for it:

7 000000 035F rrux.w r15

And EW generates this for it:

00F020 1940 100F rrux.w R15

Hmm, so who is right? It looks like IAR have used the two-word MSP430X
encoding whiles CCE has seen that it can optimize to a RRUM #1, R15.

Now let's take

** RRUX.W 2(r7)

CCE generates the following:

11 00000c C312 rrux.w 2(r7)
00000e 1840
000010 1017
000012 0002

If I disassemble this, CCE has encoded it as two instructions, CLRC and
RRCX.W 2(r7)

EW generates this:

00F030 1940 1017 0002 rrux.w 0x2(R7)
RRUX.W r15

That's a single instruction.

I am not certain how to encode these instruction and what the effects will
be if I "compress" the instructions like CCE does in the first or don't
generate the CLRC in the second case.

--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors

Start a New Thread

It isn't IAR making the mistake, it is you. You need to study the
manuals and data sheets correctly and completely before making
assumptions about such critical issues as instruction timings. It is
clearly spelled out there. This is one of the more powerful tools built
into the MSP430 instruction set. Too many people make the mistake of
thinking they don't need to read the whole manual, or the whole chapter
on the CPU, and blithely skip to the table on instrucion timings, but
even there you have clear hints about this behaviour in the emulated
instrcution expansions. I don't think Anders suggestion is even
necessary. It only applies to assembly language programming and frankly
I would expect people using assembler to know, or at least study the
subject thoroughly. Why program in assembler and then cripple your
efficiency by NOT making use of this designed in feature.

Cheers

Al

gorandragisic wrote:

>Thank you all for posts. You are right. I see that the problem is in
>my assembler. I am using IAR EW430 KickStart V4.10E.
>
>When I looked at listing file I have noticed that assembler, without
>any notice, change address mode to Register mode using constant
>generator in such way that the instruction performs the same operation.
>
>Side effects are that code is smaller and execution time is shorter.
>Both are welcome in most cases, but makes problem if someone wants to
>make code with precise execution timing and must count execution cycles.
>
>I don't know why IAR makes such code optimization in assembler? It
>would be much better if they perform 1:1 assembly and leave
>optimization to programmer.
>
>Goran
>
>--- In m..., "old_cow_yellow"
>wrote:
>
>
>>The MSP430 chip does take exactly the number of clocks to execute each
>>instructions as documented. You have been out-smarted by the
>>assembler. It has its own mind and ignores what your source code says.
>>
>>--- In m..., "gorandragisic" wrote:
>>
>>
>>>I have one question regarding MSP430F2131 instructions execution
>>>
>>>
>times.
>
>
>>>According to slau144d.pdf section 3.4.4, double operand instructions
>>>in addressing mode #N,&EDE uses 5 cycles.
>>>
>>>For example, following code would generate negative pulse on P2.5.
>>>Pulse would be 5 MCLK periods wide because those instructions consumes
>>>5 CPU cycles.
>>>
>>>bic.b #BIT5,&P2OUT
>>>bis.b #BIT5,&P2OUT
>>>
>>>But if you try to generate negative pulse on P2.2, using similar code,
>>>that pulse would be only 4 MCLK periods wide instead of 5 MCLK
>>>
>>>
>periods.
>
>
>>>bic.b #BIT2,&P2OUT
>>>bis.b #BIT2,&P2OUT
>>>
>>>This is behavior which is not documented in slau144d.pdf and errata
>>>
>>>
>>sheet.
>>
>>
>>>Please may someone try this code and verify my observations. I found
>>>that shorter execution time occurred only if you set/clear single bit
>>>in lower nibble.
>>>
>>>Goran
>>>
>>>
>>> Start a New Thread