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.
New _SWAP_BYTES intrinsic function in IAR V1.26B
Started by ●November 22, 2002
Reply by ●November 24, 20022002-11-24
Reply by ●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 ●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 ●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 ●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 ●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 ●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 ●November 25, 20022002-11-25
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