I'm playing around with the Microchip C18 compiler after a hair-splitting experience with CCS. Apparently the optimizer of C18 is not that good. For instance: LATF = addr >> 16; where addr is an uint32, is compiled into a loop where 4 registers really get shifted 16 times in a loop. Any decent compiler should recognise that a shift by 16, stored to an 8 bit port could easily be done by simply accessing the 3rd byte.... sheesh....
Is LATF *defined* as a uint8_t? (i.e., does the compiler *know* it can discard all but the lowest 8 bits?)
Is uuint32_t *really* unsigned (and not a cheap hack to "long int")? I.e., can the compiler be confused (by the definition) to thinking it is signed and opting for a sign-preserving shift?
How about:
uint8_t pointer;
pointer = (uint8_t *) &addr; LATF = pointer[2];
Clumsy, admittedly, but perhaps more obvious what's going on? (I would have added that this would be easy for an optimizer to reduce to an "addressing operation" but I also would have expected your shift to be recognized as an easy optimization!)
I've been programming since 1977 and I have never seen any compiler turn a long word shift (and/or mask) into a corresponding short word or byte access. Every compiler I have ever worked with would perform the shift.
That said, something is wrong if it takes 4 registers. I don't know the PIC18, but I never encountered any chip that required more than 2 registers to shift a value. Many chips have only a 1-bit shifter and require a loop to do larger shifts - but many such chips microcode the shift loop so the programmer sees only a simple instruction. But, occasionally, you do run into oddballs that need large shifts spelled out.
Most likely you're somehow reading the (dis)assembly incorrectly: 4 temporaries that are really mapped into the same register. If the compiler (or chip) really does need 4 registers to do a shift, then it's a piece of sh*t.
You have a 8 bit architecture shifting a 32 bit value, shifting out of one byte and into the next, thus 4 temps. You have 1 bit shifts. I suspect the compiler is generating a right shift into carry so the code can tell if a 1 needs to be moved into the most significant bit of the next byte.
It would be informative to know what sort of "helper routines" the compiler calls on. E.g., it might (inelegantly) treat this as "CALL SHIFT_LONG_RIGHT, repeat" -- in which case the
4 temp access is the canned representation of *any* "long int".
I think George is commenting that a *smart* compiler can realize that an (e.g.) 8 bit shift is: foo[2] = foo[3] foo[1] = foo[2] foo[0] = foo[1] (if you are casting to a narrower data type and can discard foo[3])
and a *9* bit shift is the same as the above with a *single* bit shift introduced (i.e., you operate on a byte at a time instead of the entire "long")
(recall, the shift amount is a constant available at compile time)
That's irrelevant (or should be!) - expressions are evaluated in their own right, and /then/ cast to the type of the LHS. The compiler should, as it does, initially treat it as a 32-bit shift, but it's a poor compiler that can't optimise a 32-bit shift by 16 to something better than this. Optimising it to a single byte transfer comes logically at a later stage.
I believe that uint32_t /must/ be an unsigned 32-bit integer. If the compiler cannot work with such a type, then no such type should exist in . A standards-compliant compiler is not allowed to cheat in that way. Of course, I don't know if Microchip's compiler claims to be standards compliant...
I agree with your statement. The C18 suite has some canned libraries like
32 bit division and such. There are other helper routines for doing delays and such.
I just did a test using C18. I choose a 18F86J10 (for no particular reason other than I remember it has a port F and thus a LATF)
For: static unsigned long addr; LATF = addr >> 16;
I get results similar to what you have above. The compiler "shifts" addr into a 32 bit temp by doing two byte moves and two clear byte instructions. It then does a 1 byte move into LATF from the temp. I'm not sure what version the OP is using or what else might be going on behind the scenes with addr. I agree a compiler should be smarter but for the price (free) C18 is not bad for smaller projects.
BTW: I did a quick test with gcc 4.4.1 and it does a load, shift 16 and a store byte.
Interesting. But now that I think about it, I almost use shift with a constant count - it's almost always a computed shift - and even when the shift is constant, the value is often in a variable anyway due to surrounding processing.
- What version of GCC is it?
- What does it do if the shift count is a variable?
- What does it do for ((ul & 0xFFFFFF) >> 8) or ((ul >> 8) & 0xFFFF)?
If it recognizes the last as wanting just the middle word then that would be impressive.
Recognizing the last two as wanting just the middle word is moot because that 16-bit word is misaligned and can't be accessed using a 16-bit load instruction.
Yes, I meant a later logical stage within the compiler. Note that it may be an /actual/ later stage (such as a peephole optimisation), or combined with earlier optimisations. It comes later logically, but the actual order is implementation dependent.
Some compilers will use shifts, some will use byte or word movements.
On the ARM, a compiler will often use shifts because shifts (especially by constants) are very cheap on the ARM architecture, while unaligned and non-32-bit memory accesses may be expensive or illegal (depending on the ARM variant).
A quick test with avr-gcc shows that it uses byte register movements rather than shifts, although it's not optimal for 32-bit values (it is fine for 16-bit values, which are much more common in an 8-bit world). For your example below of "((ul& 0xFFFFFF)>> 8)" it is close to perfect.
That's very nice code generation - faster (on an ARM anyway) than using masking.
Both types are explicitly typed as unsigned. That is as far as my influence goes. Even the crappy toy compiler of CCS does this right. My Imagecraft AVR compiler does it right. I even remember that my old Franklin/Keil C51 compiler does it right.
Well, my experience with embedded cross compilers is different, see my other post. And I think it is fair to demand such a thing since embedded compilers are supposed to be tight on hardware resources.
My AVR compiler for instance does a real load-OR-store operation when more than one bit is set in the constant but a nice single SBI instruction when only one bit needs to be set. This keeps the C code ANSI compliant and this makes optimal use of processor resources. And that is IMO how an embedded cross compiler should work.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.