[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Comment #15 from eric dot weddington at atmel dot com 2008-06-06 20:39 --- This bug report is completely unclear. 'static const' will not be overloaded to imply that a variable is stored in flash. The relevant C language draft concerning mulitple memory spaces will have to be referred to when implementing such a feature. Closing bug as WONTFIX. -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From schlie at comcast dot net 2005-02-28 13:51 --- (In reply to comment #9) IMHO, solution of this issue would require a language different from C that is able to handle different classes of pointers. Was hoping that any designated read access to data stored in the .data segement would be suffecient to indicate to the back-end the nessesity access is via the restricted lpm z-pointer instruction (with out having to get fancier than that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From schlie at comcast dot net 2005-02-28 13:55 --- (In reply to comment #10) (In reply to comment #9) IMHO, solution of this issue would require a language different from C that is able to handle different classes of pointers. Was hoping that any designated read access to data stored in the .data segement would be suffecient to indicate to the back-end the nessesity access is via the restricted lpm z-pointer instruction (with out having to get fancier than that). which with a little luck would be uniquely identified as being accessed via a (static const x *) ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
-- What|Removed |Added CC||ericw at evcohs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-02-28 21:58 --- I think the key problem is, that C language permits you to pass pointers to your static const data structures to other functions. Possibly functions that are not located within the same source file. While functions whithin the source file that defines the const data structures could in principle know that these data should be located in program memory and that they should be accessed by using lpm instructions, I do not see how to pass this knowledge to externally defined functions. Only solution in my opinion would be to define different classes of pointers. Yours, Björn. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From ericw at evcohs dot com 2005-02-28 22:01 --- Subject: Re: static initialization .data redundantly copied to ram prior to use. bjoern dot m dot haase at web dot de wrote: --- Additional Comments From bjoern dot m dot haase at web dot de 2005-02-28 21:58 --- I think the key problem is, that C language permits you to pass pointers to your static const data structures to other functions. Possibly functions that are not located within the same source file. While functions whithin the source file that defines the const data structures could in principle know that these data should be located in program memory and that they should be accessed by using lpm instructions, I do not see how to pass this knowledge to externally defined functions. Only solution in my opinion would be to define different classes of pointers. Which is a *known issue* for the AVR port. At one point Svein Seldal was working on a patch to allow pointers to different memory spaces, but that was some time ago and I haven't heard from him about the status of his work. Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From schlie at comcast dot net 2005-03-01 01:02 --- Subject: Re: static initialization .data redundantly copied to ram prior to use. --- Additional Comments From bjoern dot m dot haase at web dot de I think the key problem is, that C language permits you to pass pointers to your static const data structures to other functions. Possibly functions that are not located within the same source file. While functions whithin the source file that defines the const data structures could in principle know that these data should be located in program memory and that they should be accessed by using lpm instructions, I do not see how to pass this knowledge to externally defined functions. Only solution in my opinion would be to define different classes of pointers. - Understood, however would seem to correspondingly require a new type and/or attribute be defined and visible from the parser through to type checking and rtl template matching; So wonder if it's sufficient to use the existing static const attributes to designate program-memory mapped data (which is what it is) and thereby assume that only references to static const are prog-mem references, and correspondingly require functions which access such data directly to explicitly identify their arguments accordingly, as otherwise the reference will be presumed to reference data-memory. However any static const may first be copied to a data-memory variable and then passed as reference as desired to utilize functions with more generalized arguments, and then freed, or whatever. Hopefully such attributes are already visible at the tree/rtl/template level so that memory operand templates may identify (static const *) types, and utilize program vs data memory loads as appropriate; as otherwise, it's not real clear that this has much a chance of being accomplished; and would be a shame to otherwise waist RAM on static const data already stored and accessible the program-memory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 04:07 --- Huh? -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 04:11 --- I assume you are talking about the following code: /* __do_copy_data is only necessary if there is anything in .data section. Does not use RAMPZ - crt*.o provides a replacement for 64K devices. */ #ifdef L_copy_data .section .init4,ax,@progbits .global __do_copy_data __do_copy_data: ldi r17, hi8(__data_end) ldi r26, lo8(__data_start) ldi r27, hi8(__data_start) ldi r30, lo8(__data_load_start) ldi r31, hi8(__data_load_start) rjmp.do_copy_data_start .do_copy_data_loop: #if defined (__AVR_ENHANCED__) lpm r0, Z+ #else lpm adiwr30, 1 #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 04:14 --- And this fixme: /* FIXME: output these only if there is anything in the .data / .bss sections - some code size could be saved by not linking in the initialization code from libgcc if one or both sections are empty. */ fputs (\t.global __do_copy_data\n, asm_out_file); fputs (\t.global __do_clear_bss\n, asm_out_file); Then this is a dup of bug 18145. *** This bug has been marked as a duplicate of 18145 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:24 --- (In reply to comment #3) *** This bug has been marked as a duplicate of 18145 *** sorry, no. - that bug says don't copy when there's no data to copy. - this bug says, don't static read-only data even if present, as it should be read read-only data should not be copied to read-write memory to be then only copied again; as little as a few KB of such data could effectivly consume all of RAM relegating the entire RAM useless. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 04:28 --- (In reply to comment #4) (In reply to comment #3) *** This bug has been marked as a duplicate of 18145 *** sorry, no. oh, this is still a target bug. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From schlie at comcast dot net 2005-02-28 04:40
---
oh, this is still a target bug.
Possibly (but likely of similar concern for other small embedded targets)
The problem is that the initialization data which is linked in .data (stored in
readable flash/rom)
is first copied to RAM, prior to then being copied to the data structure which
may require
initialization. (resulting in a needless redundant copy chewing up precious
RAM).
As in for example:
struct s{
long a;
long b;
long c;
long d;
};
void main (void){
volatile struct s x = {0, 1, 2, 3};
volatile struct s y = {0, 1, 2, 3};
/* etc. */
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
[Bug target/20243] static initialization .data redundantly copied to ram prior to use.
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-28 04:46 --- Yes because MOVE_RATIO is too low for avr really. But there might different issues here really, one is for an example MOVE_RATIO is too low which causes the addition of the .data stuff but the other is that target is doing the move which seems wrong because this is constant data. Both are target bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20243
