RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
-Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Administrator Sent: Tuesday, March 15, 2011 12:43 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage On 14.03.2011 16:11, Georg-Johann Lay wrote: I agree to 100% with Eric that this is nothing anyone wants to have in official gcc releases. 100% disagree. A lot of people wants to have data qualifiers like __flash and __eeprom instead of intrinsic access functions and wants compiler to check correctness of pointers to such data typecasts. It requires address spaces support i.e. it's just the partial solution of topic starter's task. You are talking about 2 separate things. The Multiple Address Spaces feature is already in GCC, and two targets support it. Work is being done on the AVR port right now to support multiple address spaces, such as __flash and __eeprom. However, there won't be support for user-defined address spaces which then have the compiler generate special code to access some other chip X. That should rightfully be in the user's code, or at the very least, put into a GCC plug-in. This kind of stuff is very specific to a user or application, and is not generic enough to warrant inclusion in the compiler itself. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
On Tue, Mar 15, 2011 at 7:25 AM, Weddington, Eric eric.wedding...@atmel.com wrote: -Original Message- From: avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org [mailto:avr-gcc-list-bounces+eric.weddington=atmel@nongnu.org] On Behalf Of Administrator Sent: Tuesday, March 15, 2011 12:43 AM To: avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage On 14.03.2011 16:11, Georg-Johann Lay wrote: I agree to 100% with Eric that this is nothing anyone wants to have in official gcc releases. 100% disagree. A lot of people wants to have data qualifiers like __flash and __eeprom instead of intrinsic access functions and wants compiler to check correctness of pointers to such data typecasts. It requires address spaces support i.e. it's just the partial solution of topic starter's task. You are talking about 2 separate things. The Multiple Address Spaces feature is already in GCC, and two targets support it. Work is being done on the AVR port right now to support multiple address spaces, such as __flash and __eeprom. However, there won't be support for user-defined address spaces which then have the compiler generate special code to access some other chip X. That should rightfully be in the user's code, or at the very least, put into a GCC plug-in. This kind of stuff is very specific to a user or application, and is not generic enough to warrant inclusion in the compiler itself. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list Does this mean that the avr-gcc developers don't plan on adding support for the TR 18037 draft then? ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
-Original Message- From: John Myers [mailto:atomicdog@gmail.com] Sent: Tuesday, March 15, 2011 11:10 AM To: Weddington, Eric Cc: Administrator; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage Does this mean that the avr-gcc developers don't plan on adding support for the TR 18037 draft then? Huh? I said this: The Multiple Address Spaces feature is already in GCC, and two targets support it. Work is being done on the AVR port right now to support multiple address spaces, such as __flash and __eeprom. I *was* referring to TR 18037 above. So, yes, the avr-gcc developers *are* working on adding support for the multiple address space feature of TR 18037. (To be pedantic, TR 18037 contains several different features, one of which is multiple address spaces.) But, to go back to the OP, the multiple address spaces are still hard-coded in the compiler (such as for flash, eeprom, ram). Adding TR 18037 multiple address spaces does not allow the user to specify a custom address space and what code gets generated to access it. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
On Tue, Mar 15, 2011 at 10:34 AM, Weddington, Eric eric.wedding...@atmel.com wrote: -Original Message- From: John Myers [mailto:atomicdog@gmail.com] Sent: Tuesday, March 15, 2011 11:10 AM To: Weddington, Eric Cc: Administrator; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage Does this mean that the avr-gcc developers don't plan on adding support for the TR 18037 draft then? Huh? I said this: The Multiple Address Spaces feature is already in GCC, and two targets support it. Work is being done on the AVR port right now to support multiple address spaces, such as __flash and __eeprom. I *was* referring to TR 18037 above. So, yes, the avr-gcc developers *are* working on adding support for the multiple address space feature of TR 18037. (To be pedantic, TR 18037 contains several different features, one of which is multiple address spaces.) But, to go back to the OP, the multiple address spaces are still hard-coded in the compiler (such as for flash, eeprom, ram). Adding TR 18037 multiple address spaces does not allow the user to specify a custom address space and what code gets generated to access it. TR 18037 does support user defined address spaces. TR 18037 discusses supporting, via _Access and addressmod(), exactly what the OP wants but you said in a previous post that you would object to that. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
-Original Message- From: John Myers [mailto:atomicdog@gmail.com] Sent: Tuesday, March 15, 2011 12:50 PM To: Weddington, Eric Cc: Administrator; avr-gcc-list@nongnu.org Subject: Re: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage TR 18037 does support user defined address spaces. TR 18037 discusses supporting, via _Access and addressmod(), exactly what the OP wants but you said in a previous post that you would object to that. Ok, now I'm confused. Let me go back and re-read TR 18037. AFAIK, it just supported multiple address spaces, but not user-defined ones. And, AFAIK, multiple address spaces are supported in GCC (for those targets that use it), but not user-defined ones. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
RE: [avr-gcc-list] Re: an idea: adding serial sram to avr to extendheap storage
Hi Ray, As for the other concerns, I am not really looking at pushing this upstream but more a project for myself that I would make available to the world as an optional patch. I think it is too preliminary to decide whether this can go upstream. Let the requirement and design evolve. Then we can discuss the impact. Infact this is a pretty interesting one. If this feature is designed as an optional one (made possible with one of the new target specific options), I see no reason why it should not go upstream. The usage is upto the user. My inquiry here was mostly an early question of how feasible this would be and where should I start looking in the code to get a start on it. As for what project I am wanting to use this for, there are a number of them. It came to mind as I was looking at the python on a chip project that wants lots of memory. Ideas are always welcome :-) Anitha ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
