Re: [avr-gcc-list] Avoiding copy_data in config/avr/avr.c avr_file_start()?

On Wed, Jul 27, 2005 at 09:11:06PM -0700, Ben Jackson wrote: Right. However, I think it's doomed. I'm getting into this case: else if (allocation_done == lang_final_phase_enum || assigning_to_dot) einfo (_(%F%S: undefined symbol `%s' referenced in

Re: [avr-gcc-list] FIXED - with Strings and Serial I/O

User Tomdean [EMAIL PROTECTED] wrote: How do I eliminate copying strings from flash to SRAM until I need them? And still keep copying other initialized variables? Maybe if I create the string in .text with asm? Then use ldm to fetch bytes as needed. That would be reinventing the wheel. The

Re: [avr-gcc-list] FIXED - with Strings and Serial I/O

RTFM is a lot of help. Where are the tools or the doc for the tools for preventing gcc from generating code to copy data segment to SRMA? tomdean ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org

Re: [avr-gcc-list] FIXED - with Strings and Serial I/O

I found the doc, thanks to Dave, first, then several others who provided pointers. Thanks, tomdean ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

Re: [avr-gcc-list] FIXED - with Strings and Serial I/O

Christopher X. Candreva wrote: On Thu, 28 Jul 2005, User Tomdean wrote: Where are the tools or the doc for the tools for preventing gcc from generating code to copy data segment to SRMA? There aren't because that's not what you need to do. There are special print routines for printing

[avr-gcc-list] Re: Avoiding copy_data in config/avr/avr.c

IIUC, there should be an easy workaround that, however, could result in slightly bloated assembler source files. In case that the compiler generates the \t.global __do_copy_data\n sequences each time, it emits a \t.data , it would no longer be necessary to communicate at the beginning of

Re: [avr-gcc-list] FIXED - with Strings and Serial I/O

Best I could do. I already know this stuff, so I haven't looked for the docs lately. Supporting newbies is not my job. Then, if you don't have anything constructive to add, stay out of this thread! tomdean ___ AVR-GCC-list mailing list

[avr-gcc-list] Don't use gcc 3.4.4, use 4.0.1

When I built gcc for AVR I wasn't sure what the Right version of GCC to use was. I've been using a cross-compiling GCC 3.4.4 for another platform with success so I went with that. However, even with -morder1 and -fnew-ra, the code is not nearly as good as 4.0.1 for AVR. My main test file .o

Re: [avr-gcc-list] Don't use gcc 3.4.4, use 4.0.1

Ben Jackson wrote: When I built gcc for AVR I wasn't sure what the Right version of GCC to use was. I've been using a cross-compiling GCC 3.4.4 for another platform with success so I went with that. However, even with -morder1 and -fnew-ra, the code is not nearly as good as 4.0.1 for AVR. My

Re: [avr-gcc-list] Don't use gcc 3.4.4, use 4.0.1

E. Weddington wrote: [...] I'd like some other issues in GCC 4.x to be cleaned up for the AVR port before including it in WinAVR, especially DWARF2 issues. Here is a list of known AVR GCC bugs: http://rtems.org/phpwiki/index.php/GCCAVRBugs As a Linux-hosted user, is 4.0.1 stable enough for

Re: [avr-gcc-list] Don't use gcc 3.4.4, use 4.0.1

Andy Warner wrote: E. Weddington wrote: [...] I'd like some other issues in GCC 4.x to be cleaned up for the AVR port before including it in WinAVR, especially DWARF2 issues. Here is a list of known AVR GCC bugs: http://rtems.org/phpwiki/index.php/GCCAVRBugs As a Linux-hosted

[avr-gcc-list] Should -mtiny-stack be the default for small devices?

The AT90S2313, for example, has only 128 bytes of memory. Is there any reason why -mtiny-stack shouldn't be the default for these devices? Looks like there are half a dozen ATtiny devices with 0 and =256 bytes of SRAM and several of the old AT90S* devices. -- Ben Jackson [EMAIL PROTECTED]