Extended GCC Support - General Discussion - Netduino Forums
   
Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

Extended GCC Support


  • Please log in to reply
26 replies to this topic

#1 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 25 October 2011 - 12:50 AM

I've been working on extending the GCC support for the firmware (patch for 4.2 RC3 is attached). The following is a comparison of code sizes produced by each of the toolchains I tested.

YAGARTO GNU ARM Toolchain
  • GCC-4.5.2 (20110318)
    • Firmware: 354,252 bytes
    • TinyBooterDecompressor.bin: 88,844 bytes
  • GCC-4.6.0 (20110429)
    • Firmware: 346,780 bytes
    • TinyBooterDecompressor.bin: 86,460 bytes
Sourcery G++ Lite
  • GCC-4.5.2 (2011.03-42)
  • Firmware: 379,260 bytes
  • TinyBooterDecompressor.bin: 88,700 bytes
RVDS
  • Firmware: 282,252 bytes
  • TinyBooterDecompressor.bin: 41,548 bytes

Attached Files


  • Stefan likes this

#2 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 25 October 2011 - 03:25 AM

I've been working on extending the GCC support for the firmware (patch for 4.2 RC3 is attached).


Wow that's a fantastic summary, and yet depressing. GCC won't be able to replace RVDS anytime soon, eh?

-Valkyrie-MT

#3 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 25 October 2011 - 06:32 AM

The following is a comparison of code sizes produced by each of the toolchains I tested.

Well done. Have you tried dumping the output ELF symbols and sort them by size? If I remember it correctly, the most significant difference is in C/C++ RunTime functions, like printf() and probably floating point support.

#4 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 25 October 2011 - 06:59 AM

Pardon my ignorance, but...what the h*ll does the RVDS that GCC is not able to do? It looks about an half of the overall size, not a small percentage. How it can possible that RVDS is able to squeeze the code so far? Thank you and good idea posting this kind of comparisons. Cheers
Biggest fault of Netduino? It runs by electricity.

#5 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 25 October 2011 - 07:36 AM

Hi Mario, I could be mistaken, since this is absolutely not my area of expertise. But RVDS is made especially for microcontrollers as far as I can find. It's quite possible it can use instruction sets available in those microcontrollers that are a bit hidden for GCC, which is more a generic compiler. Or not? Just a wild guess :-)
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#6 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 25 October 2011 - 09:09 AM

Sourcery CodeBench 2011.07-60 Trial (with additional optimized runtime libraries (?))

  • Firmware: 371,624 bytes
  • TinyBooterDecompressor.bin: 75,748 bytes


#7 Cuno

Cuno

    Advanced Member

  • Members
  • PipPipPip
  • 144 posts
  • LocationZürich / Switzerland

Posted 25 October 2011 - 09:14 AM

But RVDS is made especially for microcontrollers

ARM's RVDS is more geared towards higher-end ARM processors, not microcontrollers. ARM's Keil subsidiary sells the MDK tools, which are focused on microcontrollers. Actually I just had to order the MDK, because RVDS (which we already have) doesn't support Cortex-M4 :-(

Ironically, the actual compiler of both tool suites is basically the same. Its far better quality than GCC is probably simply a matter of more and better engineering. After all, it's an absolutely crucial piece of software for ARM. Its processors will be benchmarked and compared to other products based on this compiler's performance. So it makes sense to invest heavily in compiler optimizations.

#8 Stefan W.

Stefan W.

    Advanced Member

  • Members
  • PipPipPip
  • 153 posts

Posted 25 October 2011 - 10:35 AM

Pardon my ignorance, but...what the h*ll does the RVDS that GCC is not able to do?
It looks about an half of the overall size, not a small percentage. How it can possible that RVDS is able to squeeze the code so far?
Thank you and good idea posting this kind of comparisons.
Cheers


What Cuno said, and in addition to that keep in mind that there is not as much "manpower" available for gcc for e.g. AVR or ARM targets as for x86.
I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"

#9 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 25 October 2011 - 11:33 AM

The following lists show size of symbols (larger than 1000 bytes) from GCC (Sourcery CodeBench 2011.07-60 Trial) and RVCT 4.1 (Trial, but not the latest) outputs, produced by nm tool (nm -C --size-sort -r -t d tinyclr.axf), symbols of the same size are rendered in gray (buffers, tables):

GCC:

00014619 t c_CLR_StringTable_Data
00006222 T CLR_RT_Thread::Execute_IL(CLR_RT_StackFrame*)
00005456 T _svfprintf_r
00003810 T _dtoa_r
00003544 t method_lookup
00002860 T _svfiprintf_r
00002780 B QueueBuffers
00002316 R g_ConfigurationSector

00002152 t c_CLR_StringTable_Lookup
00001786 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::set_Configuration{shortened}
00001646 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::get_Configuration{shortened}
00001284 T _malloc_r
00001178 T FAT_LogicDisk::FormatHelper(char const*, unsigned int)
00001100 T c_CLR_RT_DataTypeLookup
00001092 t c_TypeIndexLookup
00001064 d impure_data
00001036 B g_AT91_GPIO_Driver
00001032 D __malloc_av_
00001024 t c_CRCTable
00001024 B TxBuffer_Com
00001024 B RxBuffer_Com
00001008 T _realloc_r

RVCT:

00014619 t c_CLR_StringTable_Data
00005970 T CLR_RT_Thread::Execute_IL(CLR_RT_StackFrame*)
00003544 t method_lookup
00002780 B QueueBuffers
00002316 R g_ConfigurationSector
00002152 t c_CLR_StringTable_Lookup
00001100 T c_CLR_RT_DataTypeLookup
00001092 t c_TypeIndexLookup
00001036 B g_AT91_GPIO_Driver
00001024 t c_CRCTable
00001024 B TxBuffer_Com
00001024 B RxBuffer_Com

...
00000946 T FAT_LogicDisk::FormatHelper(char const*, unsigned int)
...
00000692 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::get_Configuration{shortened}
...
00000568 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::set_Configuration{shortened}

#10 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 25 October 2011 - 11:40 AM

Thank you all. Now I understand that the Netduino firmware is not free, but it costs about US$3000. That's the half of the RVDS price...the other half is free because it can be compiled by GCC. B) Okay, I deserve somewhat awful... Just a point on the comparison: it shows the size of the Netduino *standard* firmware. Any chance to see what is the expected result for Netduino Plus? Thanks again guys.
Biggest fault of Netduino? It runs by electricity.

#11 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 25 October 2011 - 11:49 AM

Now I understand that the Netduino firmware is not free, but it costs about US$3000. That's the half of the RVDS price...the other half is free because it can be compiled by GCC.

Well, in case of RVCT (ARM RVDS and Keil) the price includes highly optimized C/C++ RunTime libraries and a better compiler (and if I am not mistaken, some additional optimization like linker data compression is not even enabled when building the firmware). But I still believe we could use GCC, if we had CRT of comparable size (e.g. custom newlib build ?).

#12 Stefan W.

Stefan W.

    Advanced Member

  • Members
  • PipPipPip
  • 153 posts

Posted 25 October 2011 - 02:21 PM

Now I understand that the Netduino firmware is not free, but it costs about US$3000. That's the half of the RVDS price...the other half is free because it can be compiled by GCC. B)


That is not a fair statement. The "free" as it's used in open source doesn't mean free as in "free beer", but as in "not in chains". It's unfortunate that there is no cost-free toolsuite to build it, but that is not because there are things that are "closed" or because you are tied to something, it's just because of not-(yet-)done effort in the cost-free compiler department, not something you can blame Secret Labs for, IMO.
I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"

#13 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 25 October 2011 - 06:34 PM

Hehe, beat me to it.

The following lists show size of symbols (larger than 1000 bytes) from GCC (Sourcery CodeBench 2011.07-60 Trial) and RVCT 4.1 (Trial, but not the latest) outputs, produced by nm tool (nm -C --size-sort -r -t d tinyclr.axf), symbols of the same size are rendered in gray (buffers, tables):

GCC:

00014619 t c_CLR_StringTable_Data
00006222 T CLR_RT_Thread::Execute_IL(CLR_RT_StackFrame*)
00005456 T _svfprintf_r
00003810 T _dtoa_r
00003544 t method_lookup
00002860 T _svfiprintf_r
00002780 B QueueBuffers
00002316 R g_ConfigurationSector

00002152 t c_CLR_StringTable_Lookup
00001786 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::set_Configuration{shortened}
00001646 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::get_Configuration{shortened}
00001284 T _malloc_r
00001178 T FAT_LogicDisk::FormatHelper(char const*, unsigned int)
00001100 T c_CLR_RT_DataTypeLookup
00001092 t c_TypeIndexLookup
00001064 d impure_data
00001036 B g_AT91_GPIO_Driver
00001032 D __malloc_av_
00001024 t c_CRCTable
00001024 B TxBuffer_Com
00001024 B RxBuffer_Com
00001008 T _realloc_r

RVCT:

00014619 t c_CLR_StringTable_Data
00005970 T CLR_RT_Thread::Execute_IL(CLR_RT_StackFrame*)
00003544 t method_lookup
00002780 B QueueBuffers
00002316 R g_ConfigurationSector
00002152 t c_CLR_StringTable_Lookup
00001100 T c_CLR_RT_DataTypeLookup
00001092 t c_TypeIndexLookup
00001036 B g_AT91_GPIO_Driver
00001024 t c_CRCTable
00001024 B TxBuffer_Com
00001024 B RxBuffer_Com

...
00000946 T FAT_LogicDisk::FormatHelper(char const*, unsigned int)
...
00000692 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::get_Configuration{shortened}
...
00000568 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::set_Configuration{shortened}



#14 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 25 October 2011 - 06:37 PM

The firmware builds with YAGARTO are using newlib if I'm not mistaken. What are your thoughts on the custom build of newlib?

Well, in case of RVCT (ARM RVDS and Keil) the price includes highly optimized C/C++ RunTime libraries and a better compiler (and if I am not mistaken, some additional optimization like linker data compression is not even enabled when building the firmware). But I still believe we could use GCC, if we had CRT of comparable size (e.g. custom newlib build ?).



#15 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 25 October 2011 - 06:56 PM

The firmware builds with YAGARTO are using newlib if I'm not mistaken. What are your thoughts on the custom build of newlib?

I was playing with YAGARTO some time ago and if I remember it correctly, there are several 'configuration options' (preprocessor directives) that control various newlib features - perhaps it is possible to reduce the size of newlib by excluding certain features and/or fine-tuning those options. I am not sure what is included in newlib built as a part of YAGARTO. Also, I am not really sure such library is used during firmware build, usually there are several libc (don't rely on the name here, I just mean C/C++ RunTime lib) copies, so a wrong one might be used...

#16 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 25 October 2011 - 11:28 PM

Ok, I custom built a GCC 4.6.1 toolchain with newlib and compiled the firmware; here are the code sizes.

  • GCC-4.6.1
    • Firmware: 343,040 bytes
    • 00014619 t c_CLR_StringTable_Data
    • 00005912 T CLR_RT_Thread::Execute_IL(CLR_RT_StackFrame*)
    • 00005124 T _svfprintf_r
    • 00003544 t method_lookup
    • 00003020 T _dtoa_r
    • 00002780 B QueueBuffers
    • 00002332 T _svfiprintf_r
    • 00002316 R g_ConfigurationSector
    • 00002152 t c_CLR_StringTable_Lookup
    • 00001390 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::get_Configuration___MicrosoftSPOTHardwareUsbClientConfiguration(CLR_RT_StackFrame&)
    • 00001312 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::set_Configuration___VOID__MicrosoftSPOTHardwareUsbClientConfiguration(CLR_RT_StackFrame&)
    • 00001100 T c_CLR_RT_DataTypeLookup
    • 00001092 t c_TypeIndexLookup
    • 00001066 T FAT_LogicDisk::FormatHelper(char const*, unsigned int)
    • 00001040 T _malloc_r
    • 00001036 B g_AT91_GPIO_Driver
    • 00001032 D __malloc_av_
    • 00001024 t c_CRCTable
    • 00001024 B TxBuffer_Com
    • 00001024 B RxBuffer_Com
  • TinyBooterDecompressor.bin: 88,188 bytes
    • 00005124 T _svfprintf_r
    • 00003020 T _dtoa_r
    • 00002332 T _svfiprintf_r
    • 00001040 T _malloc_r
    • 00001032 D __malloc_av_
    • 00001024 t c_CRCTable


#17 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 27 October 2011 - 01:56 AM

GCC 2.6.2 was released today so I gave it a go.

  • Firmware: 343,152 bytes
    • 00014619 t c_CLR_StringTable_Data
    • 00005912 T CLR_RT_Thread::Execute_IL(CLR_RT_StackFrame*)
    • 00005124 T _svfprintf_r
    • 00003544 t method_lookup
    • 00003020 T _dtoa_r
    • 00002780 B QueueBuffers
    • 00002332 T _svfiprintf_r
    • 00002316 R g_ConfigurationSector
    • 00002152 t c_CLR_StringTable_Lookup
    • 00001390 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::get_Configuration___MicrosoftSPOTHardwareUsbClientConfiguration(CLR_RT_StackFrame&)
    • 00001312 T Library_spot_hardware_usb_native_Microsoft_SPOT_Hardware_UsbClient_UsbController::set_Configuration___VOID__MicrosoftSPOTHardwareUsbClientConfiguration(CLR_RT_StackFrame&)
    • 00001100 T c_CLR_RT_DataTypeLookup
    • 00001092 t c_TypeIndexLookup
    • 00001066 T FAT_LogicDisk::FormatHelper(char const*, unsigned int)
    • 00001040 T _malloc_r
    • 00001036 B g_AT91_GPIO_Driver
    • 00001032 D __malloc_av_
    • 00001024 t c_CRCTable
    • 00001024 B TxBuffer_Com
    • 00001024 B RxBuffer_Com
  • TinyBooterDecompressor.bin: 88,044 bytes
    • 00005124 T _svfprintf_r
    • 00003020 T _dtoa_r
    • 00002332 T _svfiprintf_r
    • 00001040 T _malloc_r
    • 00001032 D __malloc_av_
    • 00001024 t c_CRCTable


#18 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 27 October 2011 - 06:33 AM

Ok, I custom built a GCC 4.6.1 toolchain with newlib and compiled the firmware; here are the code sizes.

Just out of curiosity, have you altered newlib configuration in the custom build?

#19 Valkyrie-MT

Valkyrie-MT

    Advanced Member

  • Members
  • PipPipPip
  • 315 posts
  • LocationIndiana, USA

Posted 27 October 2011 - 01:47 PM

Why is it that these from GCC: 00005456 T _svfprintf_r 00003810 T _dtoa_r 00002860 T _svfiprintf_r are completely absent in RVCT? why are they necessary for GCC, but not RVCT? Also, is it at all possible to have RVCT precompiled parts mixed with GCC newly compiled parts? -Valkyrie-MT

#20 KodeDaemon

KodeDaemon

    Advanced Member

  • Members
  • PipPipPip
  • 63 posts

Posted 27 October 2011 - 07:04 PM

No, I couldn't find any options to make the library smaller, do you know any off hand?

Just out of curiosity, have you altered newlib configuration in the custom build?






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.