- Posts: 4402
Testing compiler builds
- PhracturedBlue
- Topic Author
- Offline
As such, it would be useful to benchmark compilers, to see which are good choices.
I am compiling a specific deviation version to ensure consistency:
hg co 6cec02426da6
When the code wouldn't fit it RAM, I modified target/devo7e/devo7e.ld and target/devo7e/devo7e_opt.ld to change the rom (rx) line to have LENGTH= 128k so the builod would go thorugh (this is more memory than we have, so you couldn't use this on a Tx)
Except where noted, all compilers have been tested to produce working binaries.
Anything over 116.00K in the 'ROM' section is too big
Here are my results so far:
Windows (mingw) +
arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.7.4 20130913 (re
lease) [ARM/embedded-4_7-branch revision 202601]
ROM: 0x08003000 - 0x0801ff24 = 115.79kB
RAM: 0x20000000 - 0x20002810 = 10.02kB
Windows (mingw) +
arm-none-eabi-gcc.exe (GCC) 4.7.1 (YAGARTO ~2012-06-16)
ROM: 0x08003000 - 0x08020114 = 116.27kB
RAM: 0x20000000 - 0x20002814 = 10.02kB
Linux (Ubunutu Lucid):
arm-none-eabi-gcc (Linaro GCC 4.6-2011.10) 4.6.2 20111004 (prerelease)
Built with summon-arm on 2012-08-04, no idea what version of newlibc
ROM: 0x08003000 - 0x0801feb0 = 115.67kB
RAM: 0x20000000 - 0x20002810 = 10.02kB
Linux (Ubuntu Precise)
arm-none-eabi-gcc (Linaro GCC 4.7-2013.01) 4.7.3 20130102 (prerelease)
Built with summon-arm on 2013-03-25: e80bd34562c5c42a026f7c86012825041a41dd75
ROM: 0x08003000 - 0x0801fd48 = 115.32kB
RAM: 0x20000000 - 0x20002814 = 10.02kB
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
I have verified that the following can compile the devo7e dfu small enough (for now) and also that it works on my Transmitter.
So my recomendation for those not compiling their own compiler is to use the following:
launchpad.net/gcc-arm-embedded
And get the relevant link for your OS.
This isn't quite as good as the Linaro compiler I'm using, But I'm still looking to see if I can find a pre-compiled version that supports the m3 architecture.
Please Log in or Create an account to join the conversation.
- blackmoon
- Offline
- Posts: 402
Hint sbstnp
Please Log in or Create an account to join the conversation.
- WheresWaldo
- Offline
- Posts: 253
I only know about Linaro because of all the buzz on xda and AOSP/AOKP projects.
Please Log in or Create an account to join the conversation.
- HappyHarry
- Offline
- Posts: 1136
blackmoon wrote: It's time for an updated VM.
Hint sbstnp
i'm in the midst of building a vm with gcc-arm-embedded just now, it's easy enough to do yourself if you follow the howto they provide >>
launchpad.net/gcc-arm-embedded/4.7/4.7-2...-build-toolchain.pdf
PB what switches do you use when compiling linaro?
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
For windows, I'd recommend using the binary at gcc-arm-embedded
Please Log in or Create an account to join the conversation.
- sbstnp
- Offline
- Posts: 649
This time it will have a GUI so emulator testing will be a breeze.
blackmoon wrote: It's time for an updated VM.
Hint sbstnp
Devo 10 + 4in1
FrSky Taranis + TBS Crossfire
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
sbstnp wrote: Already have it installed on 12.04 LTS, but need a few more days to polish everything up.
This time it will have a GUI so emulator testing will be a breeze.
blackmoon wrote: It's time for an updated VM.
Hint sbstnp
+1 from me
I've been using Rugwarriors Install and till this week flawless. So tried yours last night and up and running again, Thanks.
One thing how do i edit code to re-compile ? My knowledge of linux is ZERO Still worry about that when you've updated.
Please Log in or Create an account to join the conversation.
- blackmoon
- Offline
- Posts: 402
sbstnp wrote: Already have it installed on 12.04 LTS, but need a few more days to polish everything up.
This time it will have a GUI so emulator testing will be a breeze.
What was the previous compiler version installed on the VM ?
After I wrote my comment, I presumed that you used summon-arm, if so isn't it the linaro version of ggc ?
If so your VM still up to date, as they 4.6 and 4.7 produce still smaller (not by much) code than the gcc-arm-embedded version.
Please Log in or Create an account to join the conversation.
- sbstnp
- Offline
- Posts: 649
New VM: gcc-arm-embedded
I tend to stick with what PB is using in order to avoid toolchain induced issues.
New VM will use the same script for compiling.
blackmoon wrote:
sbstnp wrote: Already have it installed on 12.04 LTS, but need a few more days to polish everything up.
This time it will have a GUI so emulator testing will be a breeze.
What was the previous compiler version installed on the VM ?
After I wrote my comment, I presumed that you used summon-arm, if so isn't it the linaro version of ggc ?
If so your VM still up to date, as they 4.6 and 4.7 produce still smaller (not by much) code than the gcc-arm-embedded version.
Devo 10 + 4in1
FrSky Taranis + TBS Crossfire
Please Log in or Create an account to join the conversation.
- blackmoon
- Offline
- Posts: 402
Nevertheless two VM and one of which is graphical, is nice to have.
Please Log in or Create an account to join the conversation.
- PhracturedBlue
- Topic Author
- Offline
- Posts: 4402
I am not using the gcc-arm-embedded toolchain. I use my 'magic' summon-arm toolchain which produces code ~400-500bytes smaller than gcc-arm-embedded.sbstnp wrote: Old VM: summon-arm-toolchain
New VM: gcc-arm-embedded
I tend to stick with what PB is using in order to avoid toolchain induced issues.
But summon-arm is deprecated, and few have ever been able to build it to give similar results to what I get. So my recomendation for windows users is to use gcc-arm-embedded.
For Linux you can use either, but if you have a working summon-arm build and are building for Devo7e, I'd probably keep what you have.
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/dev/sat/libexec/gcc/arm-none-eabi/4.8.2/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-linaro-4.8-2013.07-1/configure --target=arm-none-eabi --prefix=/home/dev/sat --enable-multilib --enable-languages=c,c++ --with-newlib --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-threads --with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp --disable-werror --with-system-zlib --disable-newlib-supplied-syscalls
Thread model: single
gcc version 4.8.2 20130624 (prerelease) (Linaro GCC 4.8-2013.07-1)
+ Building 'devo7e.elf'
+ Optimizing placement and re-linking
ROM: 0x08003000 - 0x0801fa68 = 114.60kB
RAM: 0x20000000 - 0x200027e4 = 9.97kB
I had a 2 build warnings
pages/128x64x1/model_page.c: In function 'PAGE_ModelInit':
pages/128x64x1/model_page.c:142:26: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to remove the addressof? [-Wsizeof-pointer-memaccess]
memset(gui, 0, sizeof(gui));
^
pages/128x64x1/toggle_select.c: In function 'show_iconsel_page':
pages/128x64x1/toggle_select.c:100:26: warning: argument to 'sizeof' in 'memset' call is the same expression as the destination; did you mean to remove the addressof? [-Wsizeof-pointer-memaccess]
memset(gui, 0, sizeof(gui));
^
Now bin works but not right. Can this be recovered or do i get another go at 'summon-arm-toolchain' ?
rename file devo7e.zip to devo7e.bin
Please Log in or Create an account to join the conversation.
- rbe2012
- Offline
- So much to do, so little time...
- Posts: 1433
printf("##### gui=%x, sizeof(gui)=%d, sizeof(gui_objs.u.modelpage)=%d #####\n", gui, sizeof(gui), sizeof(gui_objs.u.modelpage));
##### gui=66c570, sizeof(gui)=8, sizeof(gui_objs.u.modelpage)=1032 #####
The size of 1032 seems to be correct; 8 is definitely the size of the pointer.
Maybe different compiler treat that different, but I think most do not recognize this (mine too).
This may lead to uninitialized values where some strange pointers inside could mix everything up.
My opinion: we should go through the code and fix this. I'll file a ticket for this so PB can look at.
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
Was only hoping if I could save it or least find out what not to do next time.
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/dev/sat/libexec/gcc/arm-none-eabi/4.8.3/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-linaro-4.8-2013.11/configure --target=arm-none-eabi --prefix=/home/dev/sat --enable-multilib --enable-languages=c,c++ --with-newlib --with-gnu-as --with-gnu-ld --disable-nls --disable-shared --disable-threads --with-headers=newlib/libc/include --disable-libssp --disable-libstdcxx-pch --disable-libmudflap --disable-libgomp --disable-werror --with-system-zlib --disable-newlib-supplied-syscalls
Thread model: single
gcc version 4.8.3 20131111 (prerelease) (Linaro GCC 4.8-2013.11)
+ Optimizing placement and re-linking
ROM: 0x08003000 - 0x0801fa84 = 114.63kB
RAM: 0x20000000 - 0x200027e4 = 9.97kB
Please Log in or Create an account to join the conversation.
- SadSack
- Offline
- Posts: 317
+ Optimizing placement and re-linking
ROM: 0x08003000 - 0x0801e100 = 108.25kB
RAM: 0x20000000 - 0x200027a0 = 9.91kB
with all options datalog/standard/advanced gui's, 900'ish shy of good build.
Have one question. #define HAS_PERMANENT_TIMER 0 is this off for a reason? Just to save space ?
Please Log in or Create an account to join the conversation.
- Home
- Forum
- Development
- Development
- Testing compiler builds