Subject:
|
Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
|
Newsgroups:
|
lugnet.robotics.nxt.nxthacking
|
Date:
|
Wed, 14 Mar 2007 19:53:10 GMT
|
Viewed:
|
16594 times
|
| |
|
|
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.
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.
You're right. The IAR tool chain recompiles firmware version 1.04 into
something around 128K.
"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 has 1 Reply:
Message is in Reply To:
11 Messages in This Thread:
   
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
