I've just had a response from IAR. Apparently it is a known bug, the
distribution on the CD has the wrong IN430.H file.
Ian
>From: "Kris De Vos"
<microbit@micr...>
>Reply-To: msp430@msp4...
>To: <msp430@msp4...>
>Subject: Re: [msp430] New _SWAP_BYTES intrinsic function in IAR V1.26B
>Date: Mon, 25 Nov 2002 20:24:40 +1100
>
>
>
> > I have just come back from one of those really hectic weekends that
>always
> > seem to build up before Christmas and look, my inbox is full of
swapping
> > bytes!
>
>Heh :-)
>
>
> > My point was that IAR have added this intrinsic to their compiler.
>Whether
> > it is worthwhile or not I can leave for another day.
>
>That's what I figured.
>
> > What I think is important is that having added the thing to their
>compiler it should
> > actually work when used, not crash out a build.
>
>I agree, know the feeling.
>
> > I am still waiting for a response from IAR, so don't tell them
that I
>have
> > fixed the problem. They seem to have supplied an old version of the
>IN430.H
> > file that did not have the function prototype. Add the declaration
line
>to
> > the list of intrinsics and away it went.
> >
> > For this we are expected to pay 400 p.a. (USD/EUR 600)
>
>I can fully sympathise with this Ian.
>That's what I perceived to be the reason for your posting, albeit to
some
>disagreements here :-)
>
>Cheers
>Kris
>
>
>
>
>.
>
>
>
>">http://docs.yahoo.com/info/terms/
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?pageatures/junkmail
Reply by Richard F. Man●November 25, 20022002-11-25
At 07:29 PM 11/25/2002 +1100, Kris De Vos wrote:
>I don't really understand what the big deal is
when there's an intrinsic
>for it anyway.
>There's dozens of idioms that "should" be picked up much
better by most
>compilers, but
>you can't have it all, even when you pay top $$ for it...
Heh, well of course you can't have it all. We compiler people need to have
permanent source of income :-)
OTOH, we won't put something in, unless there is a demand. For example, the
swpb is trivial to add to the ICC compilers, just because the way we do
code generation. It's just another code pattern. 2 lines of code patterns,
literally.
As an aside, some code generators generally use the idea of maximal
munching. Some generally rely on dead simple code generation w/ smart peep
holes. Our is the first kind.
Anyway, the point is this. For example, there is probably a few hundred,
may be a thousand or more, projects going on right at this very moment that
use various ICC compilers. If I improve code generation for a particularly
oft-used expressions, it will add up in all these programs. So it behooves
us to know what the customers codes are doing, and customers can help by
telling us those details.
p.s. but to get back to the original msg, yeah, looks like IAR goofed on
not providing the right header file or whatever.
// richard <http://www.imagecraft.com>
<http://www.dragonsgate.net/mailman/listinfo>
On-line orders, support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all previous
replies in your msgs. ]
Reply by Kris De Vos●November 25, 20022002-11-25
> I have just come back from one of those really
hectic weekends that always
> seem to build up before Christmas and look, my inbox is full of swapping
> bytes!
Heh :-)
> My point was that IAR have added this intrinsic to
their compiler.
Whether
> it is worthwhile or not I can leave for another
day.
That's what I figured.
> What I think is important is that having added
the thing to their
compiler it should
> actually work when used, not crash out a build.
I agree, know the feeling.
> I am still waiting for a response from IAR, so
don't tell them that I have
> fixed the problem. They seem to have supplied an old version of the
IN430.H
> file that did not have the function prototype.
Add the declaration line
to
> the list of intrinsics and away it went.
>
> For this we are expected to pay 400 p.a. (USD/EUR 600)
I can fully sympathise with this Ian.
That's what I perceived to be the reason for your posting, albeit to some
disagreements here :-)
Cheers
Kris
Reply by Ian Okey●November 25, 20022002-11-25
I have just come back from one of those really hectic weekends that always
seem to build up before Christmas and look, my inbox is full of swapping
bytes!
My point was that IAR have added this intrinsic to their compiler. Whether
it is worthwhile or not I can leave for another day. What I think is
important is that having added the thing to their compiler it should
actually work when used, not crash out a build.
I am still waiting for a response from IAR, so don't tell them that I have
fixed the problem. They seem to have supplied an old version of the IN430.H
file that did not have the function prototype. Add the declaration line to
the list of intrinsics and away it went.
For this we are expected to pay 400 p.a. (USD/EUR 600)
Ian
>From: "Ian Okey" <ian_okey@ian_...>
>Reply-To: msp430@msp4...
>To: msp430@msp4...
>Subject: [msp430] New _SWAP_BYTES intrinsic function in IAR V1.26B
>Date: Fri, 22 Nov 2002 13:35:24 +0000
>
>The readme file for the new version 1.26B of the IAR compiler talks about a
>new intrinsic function _SWAP_BYTES.
>
><quote>
>New features
>
>A new intrinsic function _SWAP_BYTES has been implemented in the compiler.
>This function executes the SWPB instruction.
>
>unsigned short _SWAP_BYTES(unsigned short dst);
>
></quote>
>
>I thought that I would try it out. Result = disappointment.
>
>The function prototype does not appear in my copy of IN430.H (presumably it
>should have been updated by the installation of the new version), and XLINK
>throws an error E46 (undefined external).
>
>Has anyone managed to use this function or have IAR messed up this release?
>
>Awaiting a response from IAR support.
>
>Ian
>
>_________________________________________________________________
>Add photos to your messages with MSN 8. Get 2 months FREE*.
>http://join.msn.com/?pageatures/featuredemail
>
_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?pageatures/junkmail
Reply by Kris De Vos●November 25, 20022002-11-25
I don't really understand what the big deal is when there's an
intrinsic for it anyway.
There's dozens of idioms that "should" be picked up much better
by most compilers, but
you can't have it all, even when you pay top $$ for it...
What about generating a ROR or ROL instruction (ie. rotate around and insert MSB
into LSB or vice-versa) ??
I think we're comparing IAR EW430 with GCC here, not particularly a good
comparison ... ??
I'd rather see idioms that concentrate on bit handling, because that's
were the MSP430's only weak point is,
the lack of a swap-nibble-in-a-byte instruction.
I mean, like on the PIC you could go
XORWF FOO,w
XORWF FOO,same
XORWF FOO,w
to swap <FOO> and <W> in 3 cycles, and without using an extra RAM
location for the swap.
Wish could do something like that for a nibble swap on MSP430. The only way to
do it will cost at least 5 cycles
anyway, and then you might as well do 4 shift instructions......
Sigh ..
B rgds
Kris
----- Original Message -----
From: diwilru
To: msp430@msp4...
Sent: Monday, November 25, 2002 6:47 PM
Subject: [msp430] Re: New _SWAP_BYTES intrinsic function in IAR V1.26B
> > What's the problem with auto vars in a such 'rotate'
> > instruction?
>
> Perhaps the compiler doesn't spot the byte swap opportunity?
I'd say
> it's a rather limited peephole. Worthwhile? Perhaps not, as there
are
Well, not exactly. In earlier versions I made 'swpb' as a peephole
(in gcc
port). The problem with peepholes there that a variable which has to be
swpb'ed can be 'reloaded' earlier (or/and later). So, loads of
peepholes
required to spot this. (in my case I wrote about 6 of them to spot swpb)
But now gcc can spot (a<<x)|(a>>(sizeof(a)-x)) and there is an
instruction pattern for it. So, swpb suits it when a ia 16bits unsigned
and x==8.
> other shortcomings in all MSP430 compilers as no compiler ever
produces
> optimal code for all inputs.
... sometimes... it is possible to write a C code which will result an
optimal asm output. I hope, sometimes, I can do this :)
cheers,
~d
>
> -- Paul.
.
Reply by Paul Curtis●November 25, 20022002-11-25
Hi,
> > other shortcomings in all MSP430 compilers as
no compiler ever
> produces
> > optimal code for all inputs.
>
> ... sometimes... it is possible to write a C code which will
> result an
> optimal asm output. I hope, sometimes, I can do this :)
Yes, for some chosen, fixed input, a compiler may produce optimal
output. However, as I said, no compiler ever produces optimal code for
all inputs (i.e. in the general case) as this task reduces to solcing
the halting problem. This is also known to compiler writers as the as
the permanent employment condition. :-)
-- Paul.
Reply by diwilru●November 25, 20022002-11-25
> > What's the problem with auto vars in a
such 'rotate'
> > instruction?
>
> Perhaps the compiler doesn't spot the byte swap opportunity? I'd
say
> it's a rather limited peephole. Worthwhile? Perhaps not, as there
are
Well, not exactly. In earlier versions I made 'swpb' as a peephole (in
gcc
port). The problem with peepholes there that a variable which has to be
swpb'ed can be 'reloaded' earlier (or/and later). So, loads of
peepholes
required to spot this. (in my case I wrote about 6 of them to spot swpb)
But now gcc can spot (a<<x)|(a>>(sizeof(a)-x)) and there is an
instruction pattern for it. So, swpb suits it when a ia 16bits unsigned
and x==8.
> other shortcomings in all MSP430 compilers as no
compiler ever
produces
> optimal code for all inputs.
... sometimes... it is possible to write a C code which will result an
optimal asm output. I hope, sometimes, I can do this :)
cheers,
~d
>
> -- Paul.
Reply by Paul Curtis●November 24, 20022002-11-24
Hi,
> >
> > BTW : IAR will generate a swap even when merely stating :
> > a = (unsigned char) (a>>8);
> > Furthermore, it depends on where the UINT "a" is located.
> > If it's on the stack frame as an auto var, and not in a register
-
> then the C code will not work in generating a mere
> > "swap" instruction .........
>
> Are
> swbp @Rn
> or
> swpb &A
> or
> swpb X(Rn)
>
> incortect?
None of these are incorrect and all will work as expected. SWPB takes a
source addressing mode and swaps the datum it finds there. Thus, even
SWPB @R5+ will work as expected.
> What's the problem with auto vars in a such
'rotate'
> instruction?
Perhaps the compiler doesn't spot the byte swap opportunity? I'd say
it's a rather limited peephole. Worthwhile? Perhaps not, as there are
other shortcomings in all MSP430 compilers as no compiler ever produces
optimal code for all inputs.
-- Paul.
Reply by diwilru●November 23, 20022002-11-23
>
> BTW : IAR will generate a swap even when merely
stating :
> a = (unsigned char) (a>>8);
> Furthermore, it depends on where the UINT "a" is located.
> If it's on the stack frame as an auto var, and not in a register -
then the C code will not work in generating a mere
> "swap" instruction .........
Are
swbp @Rn
or
swpb &A
or
swpb X(Rn)
incortect? What's the problem with auto vars in a such 'rotate'
instruction?
Richard,
most recent (and actually all of them) .md file is available on the
web in mspgcc.sf.net
~d
> ----- Original Message -----
> From: Clyde Stubbs
> To: msp430@y...
> Sent: Saturday, November 23, 2002 3:12 PM
> Subject: Re: [msp430] Re: New _SWAP_BYTES intrinsic function
in IAR V1.26B
>
>
> On Sat, Nov 23, 2002 at 02:36:45PM +1100, Kris De Vos wrote:
> > > providing 'a' is 16bits unsigned
> > > normal compilers will do swap bytes for:
> > > (a<<8) | (a>>8)
> >
> > I don't think that's the point here ...........
> > Ian's talking about the presence/absence of an intrinsic
>
> I think you *missed* the point - given the code in question, the
compiler
> should produce a swpb instruction, so
there's no need for an
"intrinsic".
>
> --
> Clyde Stubbs | HI-TECH Software
> Email: clyde@h... | Phone Fax
> WWW: http://www.htsoft.com/ | USA: (408) 490 2885
(408) 490 2885
> PGP: finger clyde@h... | AUS: +61 7 3552
7777 +61 7 3552
7778
>
---
> HI-TECH C: compiling the real world.
>
> To unsubscribe from the msp430 group, send an email to:
> msp430-unsubscribe@e...
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
>
>
>
>
Reply by Richard F. Man●November 23, 20022002-11-23
At 09:13 AM 11/23/2002 +0000, you wrote:
>Richard,
>just look at the gcc port sources. It has already lots of features
>implemented (especially interesting peepholes).
>If you've got questions - ask :)
>
>~d
Sure, why don't you just email me the .md file :-)
// richard <http://www.imagecraft.com>
<http://www.dragonsgate.net/mailman/listinfo>
On-line orders, support, and listservers available on web site.
[ For technical support on ImageCraft products, please include all previous
replies in your msgs. ]
