RE: [avr-gcc-list] Growing .data section when compiling with GCC 4.0instead of GCC 3.4.3

[stevech]

So – if you are into efficient code/RAM use – and fewer arcane macros – a compiler which “understands” inherently the Harvard architecture of dual-address spaces is a good idea.

There are 3 or so such C compilers for the AVRs which are but one of many Harvard architecture micro’s.

GCC is free and good for many things. But it is not the ideal solution for all situations. IMO.

 

 

---

From: address@hidden [mailto:address@hidden On Behalf Of address@hidden
Sent: Wednesday, April 27, 2005 10:07 AM
To: address@hidden; address@hidden
Cc: address@hidden; address@hidden; address@hidden
Subject: Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0instead of GCC 3.4.3

 

Not a bug. But worthy of consideration.

 

Flash/RAM situation is the same as with other constant data.

 

gcc does not understanding different address spaces and is thus not able to inherrently change addressing modes.

 

The workaround being llok at is the assocaited with the ability of compiler back end to recognise in all affected RTL instructions (lots) if the operands are uniquely constant (ie FLASH) and then use the right instructions (lpm etc). Currently this is a challenge and not fully resolved.

 

However, this case maybe easier as the jump table should only be relevant to one RTL instruction, and as far as I can see ALWAYS constant (flash). So it may well be possible to change code to always use flash based table (lpm etc) and get rid of RAM impact. (with the neccessary changes to the location of table)

 

 

 

 

 
-----Original Message-----
From: E. Weddington <address@hidden>
To: Dave Hylands <address@hidden>
Cc: address@hidden; Denis Chertykov <address@hidden>; Björn Haase <address@hidden>
Sent: Wed, 27 Apr 2005 10:49:43 -0600
Subject: Re: [avr-gcc-list] Growing .data section when compiling with GCC 4.0 instead of GCC 3.4.3

Dave Hylands wrote: 
 
>Hi Eric, 
> 
> > 
[Discussions about switch statements getting compiled into jump tables with the jump tables stored in RAM.] 
 
>>I'm not sure that it is a bug, per se. It's known that some swtich 
>>statements get compiled into tables which can increase the size of the code. 
>> >> 
> 
>It's really an issue of whether the tables are stored in flash or in 
>RAM. Actually, because they're in RAM, they take up space twice, once 
>in flash (used to initialize the RAM) and once in RAM, where they're 
>actually used. 
> 
> > 
Sure. I don't know for sure, though, but I would guess that that section of the port hasn't really changed, so in essence it's not a bug. It's a mis-feature, so! technically it would be an enhancement request. Somebody who is more familiar with the AVR port (see new additions to CC list) can perhaps comment. 
 
Eric 
 
_______________________________________________ 
AVR-GCC-list mailing list 
address@hidden 
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list 

---

Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register
 
Netscape. Just the Net You Need.
 
New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp