Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?
On Tue, 06 Dec 2005 00:46:18 -0500, Uwe Fechner [EMAIL PROTECTED] wrote: I want to build GCC 3.4.4/Binutils 2.16.1/AVR-LIBC 1.4 as I need to use the Tiny2313, Mega164, and Mega325. You could try: http://www.atmanecl.net/EnglishSite/indexEnglish.htm http://www.avrfreaks.org/index.php?name=PNphpBB2file=viewtopict=33742sid=a444ebfe988b2711165df1daf789d0ae I gave that a shot, but I don't think I want to trust production code to that. Overlaying AVRGCC 3.4.4 on top of WinAVR3.4.3 leads to some obscure differences between the header files, like stddef.h. It then is not clear to me exactly which header files are getting used. It is the files in lib\gcc\avr that are at issue. Also ran into some problems with respect to my own code when switching to AVR-LIBC 1.40, I'll address that in a separate message. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?
On Tue, 06 Dec 2005 01:47:51 -0500, Erik Christiansen [EMAIL PROTECTED] wrote: Have you considered running the windows machine, as asked, but a linux box as well? Been down that road. I had my personal Linux laptop under the desk, that I ran with TightVNC http://www.tightvnc.com/ to do PCB layout using http://pcb.sf.net/ . IT figured that out and putout a company edict that personal computer equipment was not allowed in the building. Don't come for a visit with your PocketPC... Can't do COLinux like systems either as that would show up when IT 'shadows' the hard drive. Note that my Boss has supported my efforts to do my job, IT has not. Company Politics. :-( ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?
Bob Paddock wrote: Apparently not. Boss was just told that this morning. So he is going to probably switch to a ARM part from Philips for his project. This makes two sockets Atmel has lost from us in the last two months due to availability problems. Well, not if you choose an AT91 part. ;-) -- Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?
Bob Paddock wrote: I've been following the list here and 4.x.x seemed like it was still changing often. Generally, anything later would be good as it fixed more bugs, so why not 4.0.2? ;-) I'm willing to go with 4.0.x if it is stable enough to be in the official WinAVR release, you had a message on the list a couple of weeks ago saying the next release was going to be 3.4.4, so that is what I was going to try to build. Björn Haase is probably more expert in determining which would be a better release. I know that the 4.x series has more bug fixes. However, because it is a new major release, there were some other bugs that were introduced especially in 4.0.0. I don't know for sure whether the bugs that are in 4.0.2 would be considered showstoppers for the AVR port. I know that I've heard more good things about the upcoming 4.1 than I have for 4.0.x. I know that GCC has branched for the 4.1 series, but they haven't officially released 4.1 yet, and I don't know what their timetable is for doing so. Can you make the WinAVR build scripts, or instructions a part of the standard release? I'm hoping to add Windows build instructions for all the various projects sometime in the near future. Lately I haven't been very successful with determining when I'll be able to get things done. I know that I should have some more time to devote to tools here in the near future (within a month). -- Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] multiply by constant always expands to int
Paulo Marques wrote: I had a somewhat similar problem with gcc 4.0.2. The following code: unsigned char a, b; unsigned short w; w = a * b; correctly translates into a single mul instruction under gcc 3.4.3 (modulo the register moves) but promotes a and b to 2-byte integers under gcc 4.0.2, generating a bunch of mul's and add's. Could you provide a complete testcase, and not just a snippet? I'm having a hard time reproducing what you are describing with 4.0.2. Is there any documentation (good or bad) about the gcc internals that I could use as a starting point? Or is this a use the source, Luke kind of scenario? :) That's a question for the gcc mailing list. The best thing to do is to start looking around on the GCC website and looking at all of the available documentation. Yes, they have an internals document. However, from what I've heard from others, it's not exactly easy to get through; it takes a lot of perserverance to learn GCC internals. -- Eric Weddington ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
[avr-gcc-list] LIBC 1.2.6 vs 1.4.0 header files, FLASH and EEPROM
AVR-LIBC 1.4.0 has added a couple of new defines for EEPROM and FLASH. Both that I had defined in my own code, leading to redefinition warnings. Here is a code snippet that lets you work around this type of issue. By checking the GCC version you can load the appropriate header files(s) from the correct directories: #ifdef __GNUC__ #define __GCC_VERSION__ (__GNUC__ * 1 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__) /* Test for GCC 3.4.0 */ #if __GCC_VERSION__ 30400 #include avr/ina90.h #endif /* Test for GCC = 3.4.3 */ #if __GCC_VERSION__ = 30403 #include compat/ina90.h #endif #include avr/eeprom.h #include avr/interrupt.h #include avr/io.h #include avr/sleep.h #include avr/wdt.h /* Watch Dog */ #include inttypes.h /* Test for GCC == 3.4.3 */ #if __GCC_VERSION__ == 30403 #define EEPROM __attribute__ ((section(.eeprom))) #endif [EEPROM was originally defined in my source code files.] /* Test for GCC 3.4.4 */ #if __GCC_VERSION__ 30404 #include avr/signal.h #include avr/delay.h #define FLASH [FLASH here is specific to my code, see below.] #endif /* Test for GCC = 3.4.4 */ #if __GCC_VERSION__ = 30404 #include util/delay.h #undef FLASH /* Use 'PROGMEM' */ #define FLASH [FLASH is NULL in the GCC case for me, code not shown here defines it for IAR, so the same source will build with both IAR and GCC.] #endif I put those in a file called compiler.h that I include with every project, so all compiler issues are localized to one file. Makes multiple GCC version and using non-GCC compilers work with the same source code. Hope the technique helps someone out... ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] How to rebuild AVR-GCC for Windows?
Can't do COLinux like systems either as that would show up when IT 'shadows' the hard drive. There's also bootable CD Linux distributions, like Knoppix. And USB pen drives can provide your transfer to/from the PC world. Leaves no trace behind... -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] multiply by constant always expands to int
Eric Weddington wrote:
Paulo Marques wrote:
[...]
(modulo the register moves) but promotes a and b to 2-byte
integers under gcc 4.0.2, generating a bunch of mul's and add's.
Could you provide a complete testcase, and not just a snippet? I'm
having a hard time reproducing what you are describing with 4.0.2.
So did I!
I thought this would just happen with any multiply operation, and tried
to build a simple test case, and to my surprise everything was just fine.
I tried to make the simple case more and more like my real program, to
no avail. I finally gave up and started the other way around, peeling of
code from my real program until I could get the simplest possible
program that also showed the problem.
After a lot of peeling, this is it:
void test(void)
{
unsigned short data;
unsigned char a, b;
a = PORTD;
b = PORTC;
data = b * a;
OCR1A = data;
b = PORTC;
data = b * a;
OCR1B = data;
}
I read/write values to ports just to make sure the compiler doesn't
optimize the values away.
The weird thing is that, if you comment out the _second_ multiply, the
_first_ one becomes properly compiled as a single mul instruction. If
you leave it in, then _both_ become 2 byte wide!
I compiled this with today's gcc from subversion and the result is the
same. This was compiled with -Os, but I believe it happens with other
otpimization levels too.
Is there any documentation (good or bad) about the gcc internals that
I could use as a starting point? Or is this a use the source, Luke
kind of scenario? :)
That's a question for the gcc mailing list.
Oops, sorry.
The best thing to do is to
start looking around on the GCC website and looking at all of the
available documentation.
Will do.
Yes, they have an internals document. However,
from what I've heard from others, it's not exactly easy to get through;
it takes a lot of perserverance to learn GCC internals.
Ok, thanks for all the help :)
--
Paulo Marques
Software Development Department - Grupo PIE, S.A.
Phone: +351 252 290600, Fax: +351 252 290601
Web: www.grupopie.com
Pointy-Haired Boss: I don't see anything that could stand in our way.
Dilbert: Sanity? Reality? The laws of physics?
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] LIBC 1.2.6 vs 1.4.0 header files, FLASH and EEPROM
Bob Paddock [EMAIL PROTECTED] wrote: #ifdef __GNUC__ #define __GCC_VERSION__ (__GNUC__ * 1 \ + __GNUC_MINOR__ * 100 \ + __GNUC_PATCHLEVEL__) Why not test for #if __AVR_LIBC_VERSION__ 10400UL put old code here #endif That macro comes from avr/version.h, but that file didn't exist previously, so in order to give people a transition path, we decided to include that file from avr/io.h as that is usually going to be included in virtually any AVR project anyway. (Code that is only supposed to work with avr-libc 1.4 and above is encouraged to explicitly #include avr/version.h though.) Any C preprocessor macro that hasn't been defined but is used in a preprocessor expression as shown above automatically evaluates to 0, so the above test will work. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] LIBC 1.2.6 vs 1.4.0 header files, FLASH and EEPROM
On Tue, 06 Dec 2005 14:37:53 -0500, Joerg Wunsch [EMAIL PROTECTED] wrote: Why not test for #if __AVR_LIBC_VERSION__ 10400UL put old code here #endif Any C preprocessor macro that hasn't been defined but is used in a preprocessor expression as shown above automatically evaluates to 0, so the above test will work. Lint would not like it. In this case there is no issue with that usage, but I don't like relying on implied evaluations as they can lead to very subtle bugs. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] multiply by constant always expands to int
On Tue, Dec 06, 2005 at 07:33:51PM +, Paulo Marques wrote:
I thought this would just happen with any multiply operation, and tried
to build a simple test case, and to my surprise everything was just fine.
I just did the same thing. Turns out there are at least two things
required for my version: one of the operands has to be `const', and
you must use `-Os':
void
g(void)
{
extern char f(char);
const char y = 20;
char x, z;
z = f(x * y);
}
Turn off `const' or `-Os' and you get __mulqi3, else __mulhi3
You can probably also just move the literal '20' in for y;
--
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
