Optimization (stand-alone)

[joost]

Hi All,

Fiddling with the standard examples for the VC21PC1 I noticed that
(through the standard -g option?) the generated code is not very
efficient.

Yet, my attempts to change this (e.g. adding -O option) does not
result in a working executable. From the assembly output it shows that
the optimizer has done its job (application of conditional
instructions), but the dumped .bin file grows to incredible size
(3GB?). It seems that something in the tool chain breaks.

Any advice?

Thanks,
joost.

[Dan Foisy]

Hi,

I'm not sure which toolchain you are using but I just compiled pctest
with -O2 and the bin file was only 12288 bytes. This is what I'm
currently using:
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure --target=arm-elf
--prefix=/g/gnuarm-4.1.
1 --enable-interwork --enable-multilib --with-float=soft --with-newlib
--with-he
aders=../newlib-1.14.0/newlib/libc/include --enable-languages=c,c++
Thread model: single
gcc version 4.1.1

You can download a preconfigured binary install of this toolchain from
gnuarm.com

Dan

--
Daniel Foisy
Virtual Cogs Embedded Systems Inc.
Unit 4, 5694 Highway 7 East, Suite 311
Markham, Ontario, Canada L3P 1B4
www.virtualcogs.com
416-238-2231

"Your future is modular"

[joost]

Hi Dan,

I am not sure either about the tool chain that you are using :-)

Mine I picked up from the VC wiki pages, and seems to be a gcc-3.4.3
thingy (http://www.virtualcogs.com/downloads/bu-2.15_gcc-3.4.3-c-c++-
java_nl-1.12.0_gi-6.1.exe).

Maybe you could verify your statement on this tool chain, or replace
the package by (a link to) the one you seem to be using?

Thanks,
joost.

[Dan Foisy]

As I indicated in my email, you can download the 4.1.1 toolchain from
http://www.gnuarm.com/

The 3.4.3 toolchain should have no issues with it either. I suspect you
linked in a library by accident. Your makefile should look something
like the attached.

Dan

--

[Joost 't Hart]

Dan, thanks for your promptness!

At 02:57 25-05-2008, you wrote:

>As I indicated in my email, you can download the 4.1.1 toolchain from
>http://www.gnuarm.com/

Ok, found the pre-compiled 4.1.1 under 'Files'. From the example
makefiles (which I needed to patch for this anyway) I could have
guessed this chain is even the preferred one. Would it be convenient
to update the wiki accordingly?

>The 3.4.3 toolchain should have no issues with it either. I suspect you
>linked in a library by accident. Your makefile should look something
>like the attached.

So from the makefile we can safely conclude that all application
object files can be created using make's implicit rules (including
CFLAGS usage, so with or without optimization), except for the crt0
(assembly, never mind) and emma (why?) thingies.

But you may be right anyway. I probably should have started telling
you about my fiddling, although I surely did not expect this part..

I activated the uart for some printf-like operation (those
interested, see attached files, just add a call to Uart_Init() after
the other init's) and wanted to use clib's strlen, instead of writing
it myself.

No accident here :-).

Got that working changing the ld command to:

$(LD) ... -L$(LIBPATH) -o $@ ... uart.o -lc

As said, this works fine without optimization (and indeed produces a
.bin of around 12K).

I guess there must be a better alternate way of doing this, such that
it also works with optimization?

Regards,
joost

>Dan
>
>joost wrote:
> > Hi Dan,
> >
> > I am not sure either about the tool chain that you are using :-)
> >
> > Mine I picked up from the VC wiki pages, and seems to be a gcc-3.4.3
> > thingy (http://www.virtualcogs.com/downloads/bu-2.15_gcc-3.4.3-c-c++-
> > java_nl-1.12.0_gi-6.1.exe).
> >
> > Maybe you could verify your statement on this tool chain, or replace
> > the package by (a link to) the one you seem to be using?
> >
> > Thanks,
> > joost.
> >
> > >
> >
>
>--
>Daniel Foisy
>Virtual Cogs Embedded Systems Inc.
>Unit 4, 5694 Highway 7 East, Suite 311
>Markham, Ontario, Canada L3P 1B4
>www.virtualcogs.com
>416-238-2231
>
>"Your future is modular"
>
>>
>

>PROC=arm
>TYPE=elf
>LDSCRIPT=ldscript
>
>LIBPATH='/cygdrive/f/GNUARM/lib/gcc/arm-elf/4.1.1'
>INCPATH=/cygdrive/f/GNUARM/include/c++/4.1.1
>CC=$(PROC)-$(TYPE)-gcc
>AS=$(PROC)-$(TYPE)-as
>AR=$(PROC)-$(TYPE)-ar
>LD=$(PROC)-$(TYPE)-ld
>NM=$(PROC)-$(TYPE)-nm
>OBJDUMP=$(PROC)-$(TYPE)-objdump
>CPPFLAGS=
>CFLAGS=-g -O2
>
>main: main.o Makefile $(LDSCRIPT) crt0.o vcmx212.o lcd.o cspi.o
>TSC2100.o touch.o switch.o i2c.o audio.o
> $(LD) -g -v -T $(LDSCRIPT) -o $@ crt0.o $@.o
> vcmx212.o lcd.o cspi.o TSC2100.o touch.o switch.o i2c.o audio.o
> $(NM) -n $@
> arm-elf-objcopy -O binary $@ $@.bin
> arm-elf-objdump -S -l $@ >$@.src
>
>crt0.o: Makefile $(LDSCRIPT) crt0.S
> $(CC) -g -c -o crt0.o crt0.S
>
>emma.o: Makefile $(LDSCRIPT) emma.c
> $(CC) -g -c -o emma.o emma.c
>
>clean:
> -/bin/rm *.o
> -/bin/rm LEDblink

[Dan Foisy]

Joost 't Hart wrote:
> Dan, thanks for your promptness!
>
> At 02:57 25-05-2008, you wrote:
>
>> As I indicated in my email, you can download the 4.1.1 toolchain from
>> http://www.gnuarm.com/
>
> Ok, found the pre-compiled 4.1.1 under 'Files'. From the example
> makefiles (which I needed to patch for this anyway) I could have
> guessed this chain is even the preferred one. Would it be convenient
> to update the wiki accordingly?

The older toolchain is the one we've been using for compiling umon but
either toolchain should work well.

>
>
>> The 3.4.3 toolchain should have no issues with it either. I suspect you
>> linked in a library by accident. Your makefile should look something
>> like the attached.
>
> So from the makefile we can safely conclude that all application
> object files can be created using make's implicit rules (including
> CFLAGS usage, so with or without optimization), except for the crt0
> (assembly, never mind) and emma (why?) thingies.
>
> But you may be right anyway. I probably should have started telling
> you about my fiddling, although I surely did not expect this part..
>
> I activated the uart for some printf-like operation (those
> interested, see attached files, just add a call to Uart_Init() after
> the other init's) and wanted to use clib's strlen, instead of writing
> it myself.
>

I'd be surprised if your Uart_printf function works properly - once the
uart fifo is full, sticking more characters into it without waiting for
an empty spot will cause some to be dropped.

> No accident here :-).
>
> Got that working changing the ld command to:
>
> $(LD) ... -L$(LIBPATH) -o $@ ... uart.o -lc
>
> As said, this works fine without optimization (and indeed produces a
> .bin of around 12K).
>
> I guess there must be a better alternate way of doing this, such that
> it also works with optimization?
>

Not sure what is being pulled in from the library - you're on your own here.