To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.nxt.nxthackingOpen lugnet.robotics.nxt.nxthacking in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / NXT / NXT Firmware Hacking / 4
3  |  5
Subject: 
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 15:32:31 GMT
Viewed: 
16599 times
  
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 4 Replies:
  Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
 
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" (...) (17 years ago, 14-Mar-07, to lugnet.robotics.nxt.nxthacking)
  Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
 
(...) Are you adjusting these values in d_loader.h? #define STARTOFFILETABLE (0x13FF00L) #define STARTOFUSERFLASH (0x11F000L) #define SIZEOFUSERFLASH (STARTOFFILETABLE - STARTOFUSERFLASH) I've been told by folks at LEGO that if I grow the size of (...) (17 years ago, 14-Mar-07, to lugnet.robotics.nxt.nxthacking)
  Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
 
(...) Have you experimented at all with the compiler optimisation flags? I don't know if all of them are supported for the ARM architecture, and some options cause problems on other architectures, but there's a bit of a list here: (URL) removing (...) (17 years ago, 14-Mar-07, to lugnet.robotics.nxt.nxthacking)
  Re: GCC vs. IAR compiler: Could GCC be tweaked to generate code as tight as IAR?
 
(...) I read a paper that attributed most of the code size increases in gcc generated code to the printf library - search for AN52-ARM-C-Benchmark.pdf to read the paper. Out of curiosity I built the firmware using the newlib libc and the gcc 4.1.1 (...) (17 years ago, 5-Apr-07, to lugnet.robotics.nxt.nxthacking)

11 Messages in This Thread:




Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR