PocketMatrix

I know what's happening:

The ARM signed stores and loads for halfwords and bytes are pretty crappy (They are less capable than the unisgned versions, and in some casews slower). The compiler is shifting left, and when it shifts back right, the original sign bit is in bit 15 (the high bit of the short), and an unsigned store can be used. Without the shifts, either the sign would be lost, or the signed halfword instruction would need to be used.

In other words, unless you really need to save 8 bytes in your code, it's not hurting to have those there (I'm not sure how slow the signed store halfword is, but if the compiler does something to work around it, it must be slower than the workaround. Even Microsoft must know about the signed store instructions).

The STRSH (signed store) costs an extra cycle over the straight STRH, so the MS version is slower by a single cycle. In that routine it's not worth worrying about (and if it is, just write the whole fn in assembler and have done with it).

(Can't check now, but if you can use writeback with a STRH then there's an extra cycle to kill at the end).

angeldelamort:

So long as you're not waiting a result from a previous instruction for one of the registers (like a from a MUL):
MOV X,Y

will take one cycle.

MUL R,big_number_1, big_number_2
wait between 1 and 3 cycles for R to arrive
MOV X,R

It depends on the numbers you multiply by - the bigger the more goes the (8 bit, IIRC) Booth multiplier needs. IIRC it's also faster to put the smaller number of the two in big_number_2 (if you know which is smaller at compile-time).

Cheers,

Refractor[/quote]

Yeah, that site says the SRTSH is a StrongArm extension, the quickref card I have is plain ARM only. Which would indicate that the MS compiler isn't StrongARM specific.

As for the overflow, the compiler can't be sure that the programmer is smart enough to prevent overflow, so it has to cover it's bases. Since MS didn't provide us with very much choices for the level of optimization, the compiler has to take the safe road. In this case, the overflow check is done right before the write, but since there are so many ways to check for overflow, it would be difficult for a compiler to check for any possible overflow check. As a result, the only way to tell it not to would be to use a #pragma statement or something like that, but the MS compiler doesn't have one.

The writeback (I wasn't aware of that term for it, which is why I brought it up after you already did) is probably only used by the compiler when you use "*(p++)=a" instead of "*p=a; p++;". Unlike overflow checks, detecting this is relatively easy, so there isn't really any excuse.

My opinion is that the compiler isn't that bad, but it does have a few issues nonetheless. Most of the problems it does have are excusable for various reasons.