Size is too big on linux (Ubuntu 11.10, avr-gcc 4.5.10)

I built the firmware on linux but the size is coming back 65712. Any tips on getting it down?

Got 62632 with 4.3.4 w00t! Thanks Mike and Oliver!

I also tried 4.3.3 but it came out at 64k. 4.5.1 puked with the prog_char errors like Mike got

Can you give a link to the avrfreaks package?

Where is gmp used? I can’t find it in the shruthi code. My system has:

ii libgmp10 2:5.0.1+dfsg-7ubuntu2 Multiprecision arithmetic library
ii libgmp3c2 2:4.3.2+dfsg-2ubuntu1 Multiprecision arithmetic library
ii libgmpxx4ldbl 2:5.0.1+dfsg-7ubuntu2 Multiprecision arithmetic library (C++ bindings)

This is on 32-bit but I’ve gotten the same size problems on 64-bit (both ubuntu).

gmp is used by gcc.

I used this one (64-bit) :
http://www.wrightflyer.co.uk/avr-gcc/avr-gcc-4.3.4-avrfreaks-2011-sep-20-u10.04.x64.deb

I didn’t installed it, just extracted.

On my system, libgmp3 is located here :

$ whereis libgmp.so.3
libgmp.so: /usr/lib/libgmp.so.3

and it’s from the package libgmp3c2

Solved by using avr-gcc-4.3.4 package from avrfreaks and installing lib32gmp3
Now I get 62264+544

Argh, I did make clean and recompile and now it’s all about those errors http://pastebin.com/kcqTr2vJ
Dunno.

00000038 T shruthi::ParameterDefinitions::Init()

0000008a T __vector_11
00000001 b __vector_11::sub_clock
00000001 b __vector_11::sub_clock_2

@mike-labo: which size is Init()? __vector_11? It looks like the big offenders like ProcessBlock() are smaller, which would hint at better code generation, so I’m puzzled why the overall size is that big…

This is mine with avr-gcc 4.7 on 64bit debian.

00003fff T shruthi::wav_res_waves
00000b08 W shruthi::Voice::ProcessBlock()
00000600 T shruthi::lut_res_oscillator_increments
00000409 B shruthi::user_wavetable
0000036a T shruthi::string_table
00000204 t shruthi::raw_parameter_definition
000001ee T shruthi::SynthesisEngine::ControlChange(unsigned char, unsigned char, unsigned char)
000001e4 T shruthi::Editor::HandleKeyEvent(avrlib::KeyEvent const&)
000001e0 T shruthi::VoiceController::TouchSequence()
000001d6 T shruthi::Oscillator::RenderVowel(unsigned char*)
000001ce T shruthi::Voice::Trigger(unsigned char, unsigned char, unsigned char)
000001cc W midi::MidiStreamParsershruthi::MidiDispatcher::MessageReceived(unsigned char)
00000192 T shruthi::Storage::SysExReceive(unsigned char)
0000018a T shruthi::Oscillator::RenderBandlimitedPwm(unsigned char*)
00000166 T shruthi::Oscillator::RenderFm(unsigned char*)
00000162 T shruthi::Editor::DisplayLoadSavePage()
00000144 T shruthi::wav_res_wavetables
00000142 T shruthi::Storage::SysExAcceptBuffer()
00000140 T shruthi::SynthesisEngine::ProcessBlock()
0000013c T shruthi::VoiceController::StepHandlerSequencer(signed char)

Firmware says 65090+544=65634

Tried all of the gcc options that mention “code size” with no success. Here are my top 20 from size_report:

00003fff T shruthi::wav_res_waves
00000da6 W shruthi::Voice::ProcessBlock()
00000600 T shruthi::lut_res_oscillator_increments
00000409 B shruthi::user_wavetable
0000036a T shruthi::string_table
00000306 T shruthi::SynthesisEngine::ProcessBlock()
000002e2 T SwitchesTask()
0000029c T Init()
00000254 T shruthi::Voice::Trigger(unsigned char, unsigned char, unsigned char)
0000020c T shruthi::Editor::HandleKeyEvent(avrlib::KeyEvent const&)
0000020c W midi::MidiStreamParsershruthi::MidiDispatcher::MessageReceived(unsigned char)
00000204 t shruthi::raw_parameter_definition
00000202 T __vector_11
000001fc T shruthi::SynthesisEngine::ControlChange(unsigned char, unsigned char, unsigned char)
000001ee T shruthi::VoiceController::TouchSequence()
000001de T UpdateLedsTask()
000001d2 T shruthi::Editor::DisplayLoadSavePage()
000001ca T shruthi::Oscillator::RenderBandlimitedPwm(unsigned char*)
000001ca T CvTask()
000001c8 T shruthi::Storage::SysExAcceptBuffer()

The best is still to look at the size of the objects in the binary itself… Try make size_report and inspect build/shruthi1/shruthi1.top_symbols

Top 20 offenders:

  • 00003fff T shruthi::wav_res_waves
  • 00000b92 W shruthi::Voice::ProcessBlock()
  • 00000600 T shruthi::lut_res_oscillator_increments
  • 00000409 B shruthi::user_wavetable
  • 0000036a T shruthi::string_table
  • 000002ba T shruthi::SynthesisEngine::ProcessBlock()
  • 0000029c T Init()
  • 00000284 T SwitchesTask()
  • 0000020c T shruthi::Editor::HandleKeyEvent(avrlib::KeyEvent const&)
  • 0000020c W midi::MidiStreamParsershruthi::MidiDispatcher::MessageReceived(unsigned char)
  • 00000204 t shruthi::raw_parameter_definition
  • 00000202 T __vector_11
  • 000001fc T shruthi::SynthesisEngine::ControlChange(unsigned char, unsigned char, unsigned char)
  • 000001f4 T shruthi::Voice::Trigger(unsigned char, unsigned char, unsigned char)
  • 000001ee T shruthi::VoiceController::TouchSequence()
  • 000001ca T shruthi::Oscillator::RenderBandlimitedPwm(unsigned char*)
  • 000001be T shruthi::Oscillator::RenderVowel(unsigned char*)
  • 000001b8 T UpdateLedsTask()
  • 00000184 T shruthi::Storage::SysExReceive(unsigned char)
  • 0000017c T shruthi::Editor::DisplayLoadSavePage()

5624 adc.o
4772 audio_out.o
21108 display.o
172248 editor.o
16240 envelope.o
3128 i2c.o
75672 midi_dispatcher.o
10708 note_stack.o
81820 oscillator.o
17392 parameter_definitions.o
34828 patch.o
3080 random.o
105584 resources.o
14176 sequencer_settings.o
1936 serial.o
347612 shruthi.o
142352 storage.o
6736 string.o
214420 synthesis_engine.o
8260 system_settings.o
10452 time.o
9548 voice_allocator.o
80992 voice_controller.o
9668 wii_nunchuk.o

(Note that a few of those are not used)

Can you post an ‘ls -la’ of your /build/shurthi1 folder? I want to see which files differ from mine in size.

I get 62580

64198 is at least below 65536 - 1024, though there’s only a few hundreds left for new features :frowning:

Got 64198 with 4.3.2 (the one that comes with the Arduino IDE)

Looks like the newer version makes bigger binaries :\\

You said there should be 2.5K of extra space now right? - seems like I’m still getting a bigger number than I should. What do you get?

I use 4.3.3

What version of avr-g++ are you using?

Awww. By how much? I thought that the code size reduction in v0.96 would have made this problem go away…