Subject:
|
Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
Newsgroups:
|
lugnet.robotics.nxt.nxthacking
|
Date:
|
Thu, 15 Mar 2007 13:30:07 GMT
|
Viewed:
|
25577 times
|
| |
|
|
In lugnet.robotics.nxt.nxthacking, Dick Swan wrote:
> Regarrding overwriting the flash system. I encountered the problem of
> flash file system overwriting user code as well. It's because it is
> hard coded in the code the starting address of the file system.
> There's a constant named "STARTOFUSERFLASH" that defines where the
> file system ("USERFLASH") begins.
>
> I resolved this to make it a run-time definition and make things much
> easier. What I did was add a new segment to the linker file with
> command that it is to be located as the last linked section. I'm sure
> the IAR linker commands are different for GCC so I won't go into that.
> Then I modified the source to change the defines for the "first /
> start address for flash file storage" from being a constant to being a
> reference to a constant relating to the last address in my dummy
> section. Once I got this working, no more problems.
Hi Dick Swan,
That is a nice flexible way of doing it. I will see if I can figure it out in
gcc. Thanks for the idea.
>
> Within the IAR tool chain, enabling/disabling compiler optimization
> can make alarge different of 10s of 1K of code size. Make sure that
> you've got all the GCC optimizations enabled.
Well...I have -=Os on, which are all size reducing features. The actual
"problem" can also be this packed stuff that we e-mailed about. The is probably
the next thing to investigate in this forum.
>
> You're right. The IAR tool chain recompiles firmware version 1.04 into
> something around 128K.
What is the tightest you can compile it to (text+data)?
Best,
Rasmus
>
>
>
>
> "nxtmote" <nxtmote@gmail.com> wrote in message
> news:JEwGI7.60C@lugnet.com...
> > Hi,
> >
> > If I compile the LEGO firmware sources with gcc, the code size
> > increases much
> > beyond the 128 KB (which I think) the IAR compiled sources fits
> > into. That means
> > that one have to relocate part of the compiled code into the memory
> > areas
> > between 128KB-256KB. That is ok, but not totally optimal as the
> > files,
> > filehandles, and file verion info is also in that region making it a
> > puzzle.
> > Also I think it is hard to download new files if the flash is partly
> > taken for
> > code purposes.
> >
> > With the http://nxtgcc.sf.net project (which you need to look into
> > this) I get
> > these numbers from the make process:
> >
> > Size after:
> > m_sched.elf :
> > section size addr
> > .text 126176 1048576
> > .text2 23572 1279744
> > .data 6180 2097152
> > .bss 45828 2103332
> > .comment 2133 0
> > .debug_aranges 496 0
> > .debug_pubnames 31 0
> > .debug_info 2139 0
> > .debug_abbrev 512 0
> > .debug_line 2732 0
> > .debug_frame 216 0
> > .debug_str 276 0
> > .debug_loc 353 0
> > .debug_ranges 48 0
> > Total 210692
> >
> > text2 and data is relocated. (See AT91SAM7S256_memory.ldh linker
> > details in the
> > "common") folder for details. I have tried with a "home-made"
> > toolchain (see
> > "toolchain" folder and now with the precompiled WinArm toolchain,
> > which produces
> > tighter code. The GNUARM toolchain did worse than WinARM.
> >
> > Best,
> > Rasmus
|
|
Message is in Reply To:
11 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
