I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.

My code includes a number of source lines all very similar (but obviously not identical) to this:

bis.b #4, &P2OUT ; Original code
bis.b #4, &P2OUT ; Original code
bis.b #4, &P2OUT ; Original code
bis.b #4, &P2OUT ; Original code

As CPU cycles are very valuable in this part of my code, I tried replacing &P2OUT with an indirect register reference.

I tried this as an example:

mov.b P2OUT, R12 ; Put the address of P2OUT into a register
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles

and the MSP430 FET assembler gives me this error message:

Error[0]: Invalid syntax (file name) (line number)

Is there a different way to express the failing line above so that I can use R12 as short-hand to reach P2OUT?

Thanks very much,

Dave





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

(re-posting to fix minor typos)

I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.

My code includes a number of source lines all very similar (but obviously not identical) to this:

bis.b #4, &P2OUT ; Original code
bis.b #4, &P2OUT ; Original code
bis.b #4, &P2OUT ; Original code
bis.b #4, &P2OUT ; Original code

As CPU cycles are very valuable in this part of my code, I tried replacing &P2OUT with an indirect register reference.

I tried this as an example:

mov.b #P2OUT, R12 ; Put the address of P2OUT into a register
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles

and the MSP430 FET assembler gives me this error message -->on the lines containing the bis.b #4, @R12 instruction<--

Error[0]: Invalid syntax (file name) (line number)

Is there a different way to express the failing line above so that I can use R12 as short-hand to reach P2OUT?

Thanks very much,

Dave




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

You can not use the @R12 as the destination address.
Use 0(R12) instead.

Blakely

--- In m..., David Feldman wrote:
> (re-posting to fix minor typos)
>
> I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.
>
> My code includes a number of source lines all very similar (but obviously not identical) to this:
>
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
>
> As CPU cycles are very valuable in this part of my code, I tried replacing &P2OUT with an indirect register reference.
>
> I tried this as an example:
>
> mov.b #P2OUT, R12 ; Put the address of P2OUT into a register
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
>
> and the MSP430 FET assembler gives me this error message -->on the lines containing the bis.b #4, @R12 instruction<--
>
> Error[0]: Invalid syntax (file name) (line number)
>
> Is there a different way to express the failing line above so that I can use R12 as short-hand to reach P2OUT?
>
> Thanks very much,
>
> Dave
>





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Tue, 7 Aug 2012 14:10:43 -0700 (PDT), you wrote:

>(re-posting to fix minor typos)
>
>I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.
>
>My code includes a number of source lines all very similar (but obviously not identical) to this:
>
>bis.b #4, &P2OUT ; Original code
>bis.b #4, &P2OUT ; Original code
>bis.b #4, &P2OUT ; Original code
>bis.b #4, &P2OUT ; Original code
>
>As CPU cycles are very valuable in this part of my code, I tried replacing &P2OUT with an indirect register reference.
>
>I tried this as an example:
>
>mov.b #P2OUT, R12 ; Put the address of P2OUT into a register
>bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
>bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
>bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
>bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
>
>and the MSP430 FET assembler gives me this error message -->on the lines containing the bis.b #4, @R12 instruction<--
>
>Error[0]: Invalid syntax (file name) (line number)
>
>Is there a different way to express the failing line above so that I can use R12 as short-hand to reach P2OUT?
>
>Thanks very much,
>
>Dave

Read this link of mine:
http://www.infinitefactors.org/jonk/msp430.html
Look for "Appendix" then read down.

The MSP430, terribly sadly to my mind, sacrified addressing
modes in order to get 16 registers. In the case of two
operand instructions, they have 2 bits for source operand and
1 bit for destination. Your source value is #4. Which is
fine. This gets coded as mode 2, register R2. But your
destination mode doesn't exist (it does, in source mode.) You
only have two destination modes -- register direct and
register offset indirect (and two special cases, only one of
which you should ever use -- absolute indirect. the other is
the constant 1 -- which you shouldn't ever use.)

You are hosed.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Tue, 07 Aug 2012 14:39:57 -0700, you wrote:

>You are hosed.

By this I mean you are stuck adding a word of 0, which costs
cycle time.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On 07/08/2012 23:10, David Feldman wrote:
>
> (re-posting to fix minor typos)
>
> I am doing some programmed bit-serial I/O using MSP430 assembly language
> and would like to improve execution speed. My target device is MSP430G2553.
>
> My code includes a number of source lines all very similar (but
> obviously not identical) to this:
>
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
>
> As CPU cycles are very valuable in this part of my code, I tried
> replacing &P2OUT with an indirect register reference.
>
> I tried this as an example:
>
> mov.b #P2OUT, R12 ; Put the address of P2OUT into a register
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
> bis.b #4, @R12 ; Now use register-indirect, with idea to save CPU cycles
>
> and the MSP430 FET assembler gives me this error message -->on the lines
> containing the bis.b #4, @R12 instruction<--
>
> Error[0]: Invalid syntax (file name) (line number)
>
> Is there a different way to express the failing line above so that I can
> use R12 as short-hand to reach P2OUT?
>
> Thanks very much,
>
> Dave

As Jon said, I don't think you will be able to save any cycles this way.

However, if your original code contains constants other than #4, you
might be able to save time by putting the constant into a register. The
msp430 has special addressing modes to generate constants 0, 1, 2, 8 and
-1 quickly - but other constants are fastest from a register.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 08 Aug 2012 08:30:17 +0200, David wrote:

>As Jon said, I don't think you will be able to save any cycles this way.

Probably not.

>However, if your original code contains constants other than #4, you
>might be able to save time by putting the constant into a register. The
>msp430 has special addressing modes to generate constants 0, 1, 2, 8 and
>-1 quickly - but other constants are fastest from a register.

As you sugggest, the constant generator is just as fast as a
register. So there is nothing to actually speed up code which
already uses the constant generator values, given what was
done to this instruction set design by its (misguided)
designers.

As you also say, consuming a register would be faster than
having an immediate mode constant used inline. But this
brings up another interesting point. Dave (Feldman) is using
the constant #4. He's also using the MSP430G2553. If he now
takes a look at the errata sheet for it:

http://www.ti.com/lit/er/slaz075/slaz075.pdf

He would see that it possesses the CPU4 bug. (TI NEVER FIXES
AN ERRATA and won't fix them on newer processor designs,
either, it seems.) The CPU4 bug means that the constants +4
and +8 DON'T WORK!!! So the assembler nicely, and without any
warning, stuffs the constant inline.

So. Your point is even BETTER than you may have imagined,
David. Dave Feldman might actually be able to improve the
response by using that register you just mentioned.

... TI's willingness to propagate the CPU4 bug forever almost
annoys me as much as the misguided German instruction set
designers did. But not quite as much.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 08 Aug 2012 00:30:20 -0700, I wrote:

>

>He would see that it possesses the CPU4 bug. (TI NEVER FIXES
>AN ERRATA and won't fix them on newer processor designs,
>either, it seems.) The CPU4 bug means that the constants +4
>and +8 DON'T WORK!!! So the assembler nicely, and without any
>warning, stuffs the constant inline.
>
>So. Your point is even BETTER than you may have imagined,
>David. Dave Feldman might actually be able to improve the
>response by using that register you just mentioned.

>

Shucks. It is definitely too late at night for me! This
affects the PUSH (which I ran into some time back.) But not
the BIS or BIC, so far as I'm aware. My mistake!! So there is
nothing to be done about cycles in this case. Oh, well.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On 08/08/2012 09:33, Jon Kirwan wrote:
> On Wed, 08 Aug 2012 00:30:20 -0700, I wrote:
>
> > >He would see that it possesses the CPU4 bug. (TI NEVER FIXES
> >AN ERRATA and won't fix them on newer processor designs,
> >either, it seems.) The CPU4 bug means that the constants +4
> >and +8 DON'T WORK!!! So the assembler nicely, and without any
> >warning, stuffs the constant inline.
> >
> >So. Your point is even BETTER than you may have imagined,
> >David. Dave Feldman might actually be able to improve the
> >response by using that register you just mentioned.
>
> > Shucks. It is definitely too late at night for me! This
> affects the PUSH (which I ran into some time back.) But not
> the BIS or BIC, so far as I'm aware. My mistake!! So there is
> nothing to be done about cycles in this case. Oh, well.
>

That's what I thought (and your web page confirms it - that's a nice
feature summary for the msp430).

As for the CPU4 bug, I can imagine that if TI /did/ fix it, it could
cause plenty of confusion as to which chips can use the constant
generator for push #4 and push #8, and which can't. Since all tools
take the issue into account, the only cost of the bug is an extra word
and an extra couple of cycles on the rare occasion when this instruction
could be used. Is fixing it worth the effort needed by tool vendors
adding extra flags and code (since the workaround will still be needed
for existing devices), and worth the effort needed by developers (who
need to use the extra compiler/assembler flags, and need to track which
chips can safely use the instructions)? I think not.

It might have made sense to fix it for the newer cores, given that there
are other significant changes there (20-bit support). But not for the
existing cores.

What TI /should/ do is change the documentation - it's not a bug, it's a
"previously undocumented feature". Simply change the documentation for
the constant generator addressing mode to make it clear which
instructions and address mode combinations are valid.

Of course, it would make sense for TI to fix the hardware too. But I
think it is perfectly reasonable to make a working push #4 and push #8
into an undocumented feature. That would give the least chance of
errors if someone accidentally used the instructions, while giving the
least chance of problems caused by tools generating the instructions on
code for existing devices. After all, reducing the chance of errors is
vastly more important than allowing a tiny speed increase in rare
circumstances.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 08 Aug 2012 10:39:10 +0200, you wrote:

>On 08/08/2012 09:33, Jon Kirwan wrote:
>> On Wed, 08 Aug 2012 00:30:20 -0700, I wrote:
>>
>> >
>>
>> >He would see that it possesses the CPU4 bug. (TI NEVER FIXES
>> >AN ERRATA and won't fix them on newer processor designs,
>> >either, it seems.) The CPU4 bug means that the constants +4
>> >and +8 DON'T WORK!!! So the assembler nicely, and without any
>> >warning, stuffs the constant inline.
>> >
>> >So. Your point is even BETTER than you may have imagined,
>> >David. Dave Feldman might actually be able to improve the
>> >response by using that register you just mentioned.
>>
>> >
>>
>> Shucks. It is definitely too late at night for me! This
>> affects the PUSH (which I ran into some time back.) But not
>> the BIS or BIC, so far as I'm aware. My mistake!! So there is
>> nothing to be done about cycles in this case. Oh, well.
>>That's what I thought (and your web page confirms it - that's a nice
>feature summary for the msp430).

Thanks. I wrote it within a few months of first seeing the
MSP430, I think. Quite a long time ago, now. First
impressions and all that.

>As for the CPU4 bug, I can imagine that if TI /did/ fix it, it could
>cause plenty of confusion as to which chips can use the constant
>generator for push #4 and push #8, and which can't.
>

Every other company DOES fix them. Mostly. Intel -- yes.
Microchip -- yes. Energy Micro -- yes. And so on.

It's not as though the idea is novel with me, David. People
do fix things. And other people get used to that, too, and
know where to look (the errata.) In fact, that is why you go
to the errata. To see if your stepping has certain bugs. If
it is NEVER fixed, then it is a feature and it should be
documented in the Family Manual, permanently and forever. But
TI chooses not to fix things, but to keep them in the errata
anyway. Weird. Actually, I don't know of another company that
doesn't ever fix this kind of errata (that TI doesn't own in
some way.)

TI does fix errata that would mean they couldn't sell chips
at all. But then, who wouldn't?

I see TI as standing unique, here. My other experience with
other companies has consistently been otherwise.

Anyway, per your point -- IT IS HANDLED IN THE DARNED
ASSEMBLER for gosh sake. Since it knows what chip you are
working on... guess what? It can pick and choose and generate
appropriately. It's doing that kind of thing now.

I really don't think there is any justifiable barrier here.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On 08/08/2012 13:09, Jon Kirwan wrote:
> On Wed, 08 Aug 2012 10:39:10 +0200, you wrote:
>
> >On 08/08/2012 09:33, Jon Kirwan wrote:
> >> On Wed, 08 Aug 2012 00:30:20 -0700, I wrote:
> >>
> >> >
> >>
> >> >He would see that it possesses the CPU4 bug. (TI NEVER FIXES
> >> >AN ERRATA and won't fix them on newer processor designs,
> >> >either, it seems.) The CPU4 bug means that the constants +4
> >> >and +8 DON'T WORK!!! So the assembler nicely, and without any
> >> >warning, stuffs the constant inline.
> >> >
> >> >So. Your point is even BETTER than you may have imagined,
> >> >David. Dave Feldman might actually be able to improve the
> >> >response by using that register you just mentioned.
> >>
> >> >
> >>
> >> Shucks. It is definitely too late at night for me! This
> >> affects the PUSH (which I ran into some time back.) But not
> >> the BIS or BIC, so far as I'm aware. My mistake!! So there is
> >> nothing to be done about cycles in this case. Oh, well.
> >>
> >
> >That's what I thought (and your web page confirms it - that's a nice
> >feature summary for the msp430).
>
> Thanks. I wrote it within a few months of first seeing the
> MSP430, I think. Quite a long time ago, now. First
> impressions and all that.
>
> >As for the CPU4 bug, I can imagine that if TI /did/ fix it, it could
> >cause plenty of confusion as to which chips can use the constant
> >generator for push #4 and push #8, and which can't.
> > Every other company DOES fix them. Mostly. Intel -- yes.
> Microchip -- yes. Energy Micro -- yes. And so on.
>
> It's not as though the idea is novel with me, David. People
> do fix things. And other people get used to that, too, and
> know where to look (the errata.) In fact, that is why you go
> to the errata. To see if your stepping has certain bugs. If
> it is NEVER fixed, then it is a feature and it should be
> documented in the Family Manual, permanently and forever. But
> TI chooses not to fix things, but to keep them in the errata
> anyway. Weird. Actually, I don't know of another company that
> doesn't ever fix this kind of errata (that TI doesn't own in
> some way.)
>
> TI does fix errata that would mean they couldn't sell chips
> at all. But then, who wouldn't?
>
> I see TI as standing unique, here. My other experience with
> other companies has consistently been otherwise.
>
> Anyway, per your point -- IT IS HANDLED IN THE DARNED
> ASSEMBLER for gosh sake. Since it knows what chip you are
> working on... guess what? It can pick and choose and generate
> appropriately. It's doing that kind of thing now.
>

It could have been fixed for the newer (20-bit) cores that have more
changes - but there would be no point in fixing it for existing chips,
precisely because it is handled in the assembler. The assembler knows
which chip family you are using, but it certainly doesn't know which die
revision you have. So you could never take advantage of a fix in
existing series.

Also remember that in this case, the impact of the bug is totally
negligible - out of the tiny proportion of cases where "push #4" or
"push #8" might be used, only in a tiny proportion will the extra two
cycles and extra code word be measurable. That's why I think TI should
document it as part of the msp430 specifications, and leave it there.

(Of course, the bug /was/ a big deal when it was newly discovered and
toolchain vendors hadn't implemented a workaround.)

> I really don't think there is any justifiable barrier here.
>

It's not a justification - just an alternative way of handling it.

In general, of course, you are right - errata should be fixed where
possible, and TI are not always good at doing that. There are a lot of
other errata in the link you sent that have existed for just as long,
and can have more of an impact on users. After all, the CPU4 issue is
almost completely transparent to users, while the others can affect
users who just read the datasheets and not the errata (i.e., most users).





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Thanks to everyone for the very helpful advice and commentary.

After (many years ago) much assembly language programming on PDP-11 and MOS
Technology 6501/6502 series, I clearly expected too much in terms of the
claims of nicely-orthogonal instruction set for the MSP430 (in my
opinion, rich addressing modes are more valuable than numerous registers...)

(also, the constant register issue discussion is interesting, but wasn't my
intended topic as I just cited "#4" in my example at random...)

Thanks again, everyone.

Dave

>The MSP430, terribly sadly to my mind, sacrified addressing
>modes in order to get 16 registers. In the case of two
>operand instructions, they have 2 bits for source operand and
>1 bit for destination. Your source value is #4. Which is
>fine. This gets coded as mode 2, register R2. But your
>destination mode doesn't exist (it does, in source mode.) You
>only have two destination modes -- register direct and
>register offset indirect (and two special cases, only one of
>which you should ever use -- absolute indirect. the other is
>the constant 1 -- which you shouldn't ever use.)
>
>You are hosed.
>
>Jon





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

> Thanks to everyone for the very helpful advice and commentary.
>
> After (many years ago) much assembly language programming on PDP-11 and
> MOS Technology 6501/6502 series, I clearly expected too much in terms of
> the claims of nicely-orthogonal instruction set for the MSP430 (in my
> opinion, rich addressing modes are more valuable than numerous
> registers...)

I think you're wrong: registers are much more precious than addressing
modes.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
SolderCore Development Platform http://www.soldercore.com





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

When the architecture relies on registers to get maximum execution speed
then I too believe that registers are more important, however if the
instruction set had a richer set of truly orthogonal addressing modes
then it would seem that these too would be equally important, until you
look at the execution speeds. The only true single cycle mode is
register to register, as soon as you use indirect or indexed register
modes the clock cycles climb anyway. So I would probably prefer 2 sets
of 16 registers and simpler 1 bit modes in both src and dst given the
choice,(register or indexed modes), so by using just a single bit in the
operand to define the register mode the freed up bit can signal register
bank 1 or 2.

Al

On 9/08/2012 1:12 AM, Paul Curtis wrote:
>> Thanks to everyone for the very helpful advice and commentary.
>>
>> After (many years ago) much assembly language programming on PDP-11 and
>> MOS Technology 6501/6502 series, I clearly expected too much in terms of
>> the claims of nicely-orthogonal instruction set for the MSP430 (in my
>> opinion, rich addressing modes are more valuable than numerous
>> registers...)
> I think you're wrong: registers are much more precious than addressing
> modes.
>
> --
> Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
> SolderCore Development Platform http://www.soldercore.com
>
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

FWIW The SPARC architecture has a single large set of registers and keeps a pointer to the subset of registers that are currently accessible. The idea being to preserve a portion of the register set by simply shifting the window pointer.

If more need to be saved then the normal manner of saving registers is used for those. I always thought it was a rather elegant solution.

Have Fun!
Reg

--- On Wed, 8/8/12, Onestone wrote:

> From: Onestone
> Subject: Re: [msp430] Re: (corrected) Assembler BIS instruction and register indirect as d
> To: m...
> Date: Wednesday, August 8, 2012, 11:39 AM
> When the architecture relies on
> registers to get maximum execution speed
> then I too believe that registers are more important,
> however if the
> instruction set had a richer set of truly orthogonal
> addressing modes
> then it would seem that these too would be equally
> important, until you
> look at the execution speeds. The only true single cycle
> mode is
> register to register, as soon as you use indirect or indexed
> register
> modes the clock cycles climb anyway. So I would probably
> prefer 2 sets
> of 16 registers and simpler 1 bit modes in both src and dst
> given the
> choice,(register or indexed modes), so by using just a
> single bit in the
> operand to define the register mode the freed up bit can
> signal register
> bank 1 or 2.
>
> Al
>
> On 9/08/2012 1:12 AM, Paul Curtis wrote:
> >> Thanks to everyone for the very helpful advice and
> commentary.
> >>
> >> After (many years ago) much assembly language
> programming on PDP-11 and
> >> MOS Technology 6501/6502 series, I clearly expected
> too much in terms of
> >> the claims of nicely-orthogonal instruction set for
> the MSP430 (in my
> >> opinion, rich addressing modes are more valuable
> than numerous
> >> registers...)
> > I think you're wrong: registers are much more precious
> than addressing
> > modes.
> >
> > --
> > Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk
> > SolderCore Development Platform      http://www.soldercore.com
> >
> >
> >
> >
> >
> >
> >
> >



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 8 Aug 2012 16:42:08 +0100, you wrote:

>> Thanks to everyone for the very helpful advice and commentary.
>>
>> After (many years ago) much assembly language programming on PDP-11 and
>> MOS Technology 6501/6502 series, I clearly expected too much in terms of
>> the claims of nicely-orthogonal instruction set for the MSP430 (in my
>> opinion, rich addressing modes are more valuable than numerous
>> registers...)
>
>I think you're wrong: registers are much more precious than addressing
>modes.

What was done to the MSP430 wasn't a logical tradeoff. They
simply screwed up. They could have managed the instruction
design in a way that didn't screw up the inability for a PC
relative function call, if nothing else. But if interested, I
can lay out a design that provides the 12 working registers
and doesn't nearly as badly injures the rest. What they did
is subject it to blind choices, not crafted design.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Wed, 8 Aug 2012 11:23:24 -0700 (PDT), you wrote:

> FWIW The SPARC architecture has a single large set of
> registers and keeps a pointer to the subset of registers
> that are currently accessible. The idea being to preserve a
> portion of the register set by simply shifting the window
> pointer.
>
> If more need to be saved then the normal manner of saving
> registers is used for those. I always thought it was a
> rather elegant solution.

Just about anyone could have improved the MSP430 instruction
design with a day's thought and a short list of mistakes to
solve. (There are several.) No need for such a sweeping
change. But your point is also worth taking, too.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

Perhaps I'm too engrossed in some of the mythology regarding the MSP430
origins, but my understanding was that it was designed by Ti's analog
group in Germany, primarily to meet a need for new ex eastern european
nations, now moving into the EEC, to meter energy usage, which had
previously been free. If that is really the case then could they have
been expected to be well versed in instruction set design, or to really
care?

At this time Ti were very DSPcentric, within Ti DSP was king,at times it
seemed that Ti corporate in the US actually hated the poor little MSP430
when it first came out, certainly they made no real effort to support it
until well after it had taken off and gained popularity with a sizable
group of engineers. yes it isn't pretty, but at the time I liked it a
lot better than Microchip, AVR, Motorola and 80xx stuff, and still
mostly do.

Al

On 9/08/2012 4:23 AM, Jon Kirwan wrote:
> On Wed, 8 Aug 2012 11:23:24 -0700 (PDT), you wrote:
>
>> FWIW The SPARC architecture has a single large set of
>> registers and keeps a pointer to the subset of registers
>> that are currently accessible. The idea being to preserve a
>> portion of the register set by simply shifting the window
>> pointer.
>>
>> If more need to be saved then the normal manner of saving
>> registers is used for those. I always thought it was a
>> rather elegant solution.
> Just about anyone could have improved the MSP430 instruction
> design with a day's thought and a short list of mistakes to
> solve. (There are several.) No need for such a sweeping
> change. But your point is also worth taking, too.
>
> Jon
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

--- In m..., David Feldman wrote:
> (re-posting to fix minor typos)
>
> I am doing some programmed bit-serial I/O using MSP430 assembly language and would like to improve execution speed. My target device is MSP430G2553.
>
> My code includes a number of source lines all very similar (but obviously not identical) to this:
>
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
> bis.b #4, &P2OUT ; Original code
>
> As CPU cycles are very valuable ...

I think your "original code" has the same effect as:

bis.b #4, &P2OUT ; one
nop
nop
nop
nop ; two
nop
nop
nop
nop ; three
nop
nop
nop
nop ; four

Thus you can eliminate some or all of the "nop" above to save CPU cycles.





(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

On Thu, 09 Aug 2012 05:50:48 +0930, you wrote:

>Perhaps I'm too engrossed in some of the mythology regarding the MSP430
>origins, but my understanding was that it was designed by Ti's analog
>group in Germany, primarily to meet a need for new ex eastern european
>nations, now moving into the EEC, to meter energy usage, which had
>previously been free. If that is really the case then could they have
>been expected to be well versed in instruction set design, or to really
>care?

I don't think that pure analog designers decided to suddenly
become instruction set designers and wear all hats in this
design, for several reasons. But I would guess they didn't
look too hard when finding someone to do that task. Perhaps
you are right -- they didn't care.

Still, when taking this to a general embedded engineering
public there remains no real excuse in not cleaning this up.
They had already done all the hard work on low power and it
would decidedly NOT have been a yeoman's work to tidy things
up a bit. I've done a complete CPU design before (not low
power of course about which I greatly respect the talent
involved), built and tested it, and looking over what went
wrong here it would not have been a difficult challenge, nor
expensive (in a cash sense.)

>At this time Ti were very DSPcentric, within Ti DSP was king,

Their 320C30 and 320C40 were terrible in their day. Used
them, didn't like the parts. And I really disliked the fact
that TI could NOT figure out, after many weeks of
consultations with "their supposed best team at corporate" on
the phone, by email, and otherwise, could not explain why
their parts didn't do what their documentation said they
would do and had no noticeably interest in actually caring,
either. They actually just said that they didn't know why,
agreed it was a mystery, and spent NO MORE TIME on it once
they admitted the problem. They didn't even change the docs
to let others know what I found. And it was important.

By comparison, Analog Devices were saints. When I uncovered a
CPU bug in their ADSP2111 chip, they worked VERY HARD and
showed great concern. They asked me for my test code, used
it, and tracked the problem down to their FAB. They changed
FABs for the parts and it fixed the problems and I had good
parts coming in about 6 months later. And given that they
changed FABs, and given my experience IN a FAB, I know they
had to work their ass off to do that.

TI doesn't fix things, doesn't care to. But they do make a
lot of good stuff, just the same. So it's a mixed bag. If I
use their parts and they test out okay, then I'm fine. If I
use their parts and they don't test out okay, I waste little
time going elsewhere. I'll write a note and send it on. But I
won't hold my breath. I just go find something else.

A problem is in investment of personal time and in cash
related to all the tools one buys. This is time and money.
Microchip has $500 tools. They add up. But I also know that I
get support, too. Both for their chips (which they fix if I
run into a serious problem, and they have on several
occasions so I am not talking through my hat -- I've had a
silicon fix in my hands in about 2 months from them) and
their tool support, which they support long after they no
longer sell them anymore. In fact, they still support the
oldest tool I own of theirs and it is more than 20 years old.

On the other hand, I love the MSP430's hardware, those parts
of it I've used a lot anyway. Who can beat a B7 timer unit?
Or the incredible clocking systems? And the price is
certainly right for someone wanting to get started with them.

>at times it
>seemed that Ti corporate in the US actually hated the poor little MSP430
>when it first came out, certainly they made no real effort to support it
>until well after it had taken off and gained popularity with a sizable
>group of engineers. yes it isn't pretty, but at the time I liked it a
>lot better than Microchip, AVR, Motorola and 80xx stuff, and still
>mostly do.

Well, that may explain a lot. It's success was perhaps a
pleasant, but unexpected surprise.

Jon




(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )

I agree with you on the DSP front. I hate Ti DSP's, I've tried several,
from the early 320C30, through the 24xx parts, and several of the newer
parts. And to may they simply don't compare to the old ADSP21xx parts. I
once crammed a 2400bps codec into a 2105 and even had a little room to
spare. And algebraic programming for DSP functions seems a no brainer.
The only thing I wasn't a big fan of was the complex header files
(compared to some other DSP's). Of course it sucked current like a
toothless parrot, but it was still a great machine I felt. I was a huge
fan of Microchip for many years, from the pre-microchip era, when I used
lots of little PICs as individual axis controllers for a FAB robot,
until the mid to late 90's when I was caught by 2 year delays in the
release of some parts, and ended up switching to the MSP after trying
AVR and a couple of others.

As you say the timers are one of the best peripherals around, and
compared to Microchip and AVR there is never a shortage of them on most
parts. The clock system has varied heaps over the years, but mostly has
become better each time, even the comm peripherals, though not truly
spectacular, are simple and quite powerful. I am able to get excellent
communication at 460800baud, for example, just using the pre-calibrated
DCO at 16MHz with a regulated voltage and across a decent temperature
range. More importantly it takes very few lines of code to implement
either a UART or an SPI control. Perhaps the worst peripheral though is
the DMA, since it isn't a 'true' independent module, but steals CPU
cycles. There are times when using the DMA is actually slower than
running your own code.

Al

On 9/08/2012 3:32 PM, Jon Kirwan wrote:
> On Thu, 09 Aug 2012 05:50:48 +0930, you wrote:
>
>> Perhaps I'm too engrossed in some of the mythology regarding the MSP430
>> origins, but my understanding was that it was designed by Ti's analog
>> group in Germany, primarily to meet a need for new ex eastern european
>> nations, now moving into the EEC, to meter energy usage, which had
>> previously been free. If that is really the case then could they have
>> been expected to be well versed in instruction set design, or to really
>> care?
> I don't think that pure analog designers decided to suddenly
> become instruction set designers and wear all hats in this
> design, for several reasons. But I would guess they didn't
> look too hard when finding someone to do that task. Perhaps
> you are right -- they didn't care.
>
> Still, when taking this to a general embedded engineering
> public there remains no real excuse in not cleaning this up.
> They had already done all the hard work on low power and it
> would decidedly NOT have been a yeoman's work to tidy things
> up a bit. I've done a complete CPU design before (not low
> power of course about which I greatly respect the talent
> involved), built and tested it, and looking over what went
> wrong here it would not have been a difficult challenge, nor
> expensive (in a cash sense.)
>
>> At this time Ti were very DSPcentric, within Ti DSP was king,
> Their 320C30 and 320C40 were terrible in their day. Used
> them, didn't like the parts. And I really disliked the fact
> that TI could NOT figure out, after many weeks of
> consultations with "their supposed best team at corporate" on
> the phone, by email, and otherwise, could not explain why
> their parts didn't do what their documentation said they
> would do and had no noticeably interest in actually caring,
> either. They actually just said that they didn't know why,
> agreed it was a mystery, and spent NO MORE TIME on it once
> they admitted the problem. They didn't even change the docs
> to let others know what I found. And it was important.
>
> By comparison, Analog Devices were saints. When I uncovered a
> CPU bug in their ADSP2111 chip, they worked VERY HARD and
> showed great concern. They asked me for my test code, used
> it, and tracked the problem down to their FAB. They changed
> FABs for the parts and it fixed the problems and I had good
> parts coming in about 6 months later. And given that they
> changed FABs, and given my experience IN a FAB, I know they
> had to work their ass off to do that.
>
> TI doesn't fix things, doesn't care to. But they do make a
> lot of good stuff, just the same. So it's a mixed bag. If I
> use their parts and they test out okay, then I'm fine. If I
> use their parts and they don't test out okay, I waste little
> time going elsewhere. I'll write a note and send it on. But I
> won't hold my breath. I just go find something else.
>
> A problem is in investment of personal time and in cash
> related to all the tools one buys. This is time and money.
> Microchip has $500 tools. They add up. But I also know that I
> get support, too. Both for their chips (which they fix if I
> run into a serious problem, and they have on several
> occasions so I am not talking through my hat -- I've had a
> silicon fix in my hands in about 2 months from them) and
> their tool support, which they support long after they no
> longer sell them anymore. In fact, they still support the
> oldest tool I own of theirs and it is more than 20 years old.
>
> On the other hand, I love the MSP430's hardware, those parts
> of it I've used a lot anyway. Who can beat a B7 timer unit?
> Or the incredible clocking systems? And the price is
> certainly right for someone wanting to get started with them.
>
>> at times it
>> seemed that Ti corporate in the US actually hated the poor little MSP430
>> when it first came out, certainly they made no real effort to support it
>> until well after it had taken off and gained popularity with a sizable
>> group of engineers. yes it isn't pretty, but at the time I liked it a
>> lot better than Microchip, AVR, Motorola and 80xx stuff, and still
>> mostly do.
> Well, that may explain a lot. It's success was perhaps a
> pleasant, but unexpected surprise.
>
> Jon
>



(You need to be a member of msp430 -- send a blank email to msp430-subscribe@yahoogroups.com )