[avr-gcc-list] Shift by multiple of 8 is really shifting...
Here I'm doing something like l = ((ulong)i 16) + ...; It's actually loading the i, expanding it, then shifting it. Once again I'm sure I've seen gcc do better (on i386 or PPC, not sure). If it's not useful for me to point out these problems as I run across them, feel free to tell me to shut up. :-) Better yet, give me an idea of where in gcc I should fix this (clearly it could be fixed with a peephole rule of some kind, but I bet it's also possible to just generate better code). BTW, this is not purely academic for me, I'm working on a LC meter that greatly benefits from the float math etc and I've managed to get the float-using version down from 2046 to 1662, which is going to leave space to finish the code. This asm got generated when I started tracking timer0/1 overflows and adding them in, scaled, at the end. It's still a win, but it'd be even better if both copies of this saved 4 more instructions! b2: 20 91 6a 00 lds r18, 0x006A b6: 30 91 6b 00 lds r19, 0x006B ba: 44 27 eor r20, r20 bc: 55 27 eor r21, r21 be: 53 2f mov r21, r19 c0: 42 2f mov r20, r18 c2: 33 27 eor r19, r19 c4: 22 27 eor r18, r18 -- Ben Jackson [EMAIL PROTECTED] http://www.ben.com/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Shift by multiple of 8 is really shifting...
Ben Jackson wrote: Here I'm doing something like l = ((ulong)i 16) + ...; It's actually loading the i, expanding it, then shifting it. Once again I'm sure I've seen gcc do better (on i386 or PPC, not sure). If it's not useful for me to point out these problems as I run across them, feel free to tell me to shut up. :-) Better yet, give me an idea of where in gcc I should fix this (clearly it could be fixed with a peephole rule of some kind, but I bet it's also possible to just generate better code). Oh, it's definitely useful, but I would suggest a slightly different process: - Submit bug reports to the GCC bug tracker (bugzilla). You can mark bugs as enhancements. Feel free to put my email address in the CC list and, at least, I can help keep track of the status of it. It's very important to submit bug reports because often times anything that goes to a mailing list can be easily forgotten. The GCC bug tracker is here: http://gcc.gnu.org/bugzilla/ - If you are serious about helping out on the code of the AVR port, then be sure to go through the process of submitting copyright assignment paperwork to the FSF. See the page on Contributing to GCC: http://gcc.gnu.org/contribute.html - Also read the GCC internals manual if you want to do some coding on the AVR port. - If you want to make changes to the AVR port, it would be best to do them in CVS HEAD (which currently will be 4.1), rather than any GCC 3.4.x release. A number of changes have gone in between the two. - And also let this list know of any bug reports / enhancements that you file. - Lastly, be sure to note the difference between bugs/enhancements in the compiler and in the library, avr-libc. avr-libc has it's own project (repository, bug list, etc.) on Savannah. And thanks for taking a look at the tools in detail! Any and all help is very appreciated! Eric ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
