AVR GCC lub inny.

Pewnego dnia Krzysztof Rudnik przemówił ludzkim głosem:

dalej jest

i ta recepta mi się podoba :-)

bo programiscie zalezy na krotkim kodzie :-)

I przeciez jest wygodny, wiec nie bedzie przepisywal z wydrukow linkera gdzie ten dana funkcje wstawil. Wiec linker wie ze jest wstawiona :-)

J.

Sprawdz najpierw czy w tych 17 bajtach nie miesci sie 1 bajt procedury test :-)

Ale i tak moze byc to sprawka kompilatora - nie ma tresci to nie skompilowal .. chociaz powinien, bo byc moze sa odwolania w innym pliku.

J.

W sumie powinno - dosc skomplikowane bedzie sprawdzenie przez kompilator ze jest to funkcja nieuzywana.

J.

I co - ma dopelnic nopami i czy przesuwac kod ?

J.

dla niektórych architektur to jest obsługiwane przez gcc i ld, ale akurat dla avr nie. zresztą co innego zmienić rodzaj relokacji i wstawić inną daną w konkretne miejsce w kodzie (nie trzeba przypadkiem używać

-fPIC?), co innego usuwać i przestawiać kawałki kodu będące z punktu widzenia linkera jedną logiczną całością.

w.

Albert Bartoszko napisał(a):

Np. IAR dla AVR

Użytkownik AK napisał:

[...]

A można prosić o kod wynikowy / ustawienia parametrów kompilacji?

Albert

W artykule snipped-for-privacy@4ax.com autorem którego mieni się J.F, napisano:

Jak dopełni, zysk będzie w jednym cyklu czasu wykonania mniej, czyli taki sobie.

Jak przesunie - oprócz w.w. się kod skróci, ale co linker się bajtami namacha, to jego. Nie wspominając już, że musi wiedzieć, którymi.

Sprawdziłem na programie dla ATmegi128:

- rozmiar kodu wynikowewgo ok. 100k (bez bibliotek i stałych),

- 3208 instrukcji call,

- 768 instrukcji można zamienić na rcall (pewnie nieco więcej, nie analizowałem dokładnie), wtedy kod skróciłby się o ok. 1.5%

Wywołania wewnątrzmodułowe (nawet funkcji statycznych) są też realizowane przez call. Optymalizacja wykonywana podczas generowania kodu (w obrębie jednostki kompilacji), realizowana tylko przez komilator, mogłaby być znacznie prostsza do realizacji (i być może da to większość korzyści możliwych do osiągnięcia tą metodą, bez potrzeby angażowania linkera).

Albert Bartoszko napisał(a):

Oczywiscie: Mamy dwa pliki: plik test.c

-------------------------------------------- #include <iom128.h>

#include <stdio.h>

extern int ext_function(int y);

int function1(int x, int c) { int i = 0; while(x--) { i += (x * 1000) + (c/2); c += 34; i &= 0xFFFE; } return i; }

void main(void) { int z; z = ext_function(2345); z = function1(z, 1234); printf("Result: %d", z); while(1); }

------------------------------------------------------ plik test_2.c

------------------------------------------------------ #include <stdlib.h>

int ext_function(int y) { y *= 2; return abs(y); }

-------------------------------------------------------- I teraz wyniki kompilacji i linkowania: rozmiar rozmiar rozmiar kodu pliku pliku wynikowego test.c test_2.c

1. Pliki kompilowane w postaci jak powyzej 5884 141 8
2. Pliki kompilowane z usunietym wywolaniem funkcji <function1> (zaremowane) 5778 135 8
3. Pliki kompilowane z usunietym wywolaniem funkcji <function1> i z usunieta sama funkcja <function1> 5778 35 8

Jak widac, w przypadku drugim, cala funkcja zostala usunieta przez _linker_ ,

Kompilator: IAR AVR 3.10C Opcje kompilacji i linkowania:

------------------------------------------------------------------- MAKE Version 5.2 Copyright (c) 1987, 2000 Borland Compiling src\test.c iccavr -I \INC\DLIB\ -I \INC\ -I ..\Common\ -I ..\common\rtos\include -I Include -o _obj\ --cpu=m128

-DENABLE_BIT_DEFINITIONS -lC _lst -r -ms -e -s9 -y src\test.c

IAR Atmel AVR C/EC++ Compiler V3.10C/W32 Copyright 1996-2004 IAR Systems. All rights reserved.

135 bytes of CODE memory (+ 7 bytes shared) 11 bytes of DATA memory

Errors: none Warnings: none Compiling src\test_2.c iccavr -I \INC\DLIB\ -I \INC\ -I ..\Common\ -I ..\common\rtos\include -I Include -o _obj\ --cpu=m128

-DENABLE_BIT_DEFINITIONS -lC _lst -r -ms -e -s9 -y src\test_2.c

IAR Atmel AVR C/EC++ Compiler V3.10C/W32 Copyright 1996-2004 IAR Systems. All rights reserved.

8 bytes of CODE memory

Errors: none Warnings: none xlink.exe -I_obj test.r90 test_2.r90 \LIB\DLIB\dl3s-ec.r90

-I\LIB\\DLIB\ -f cfgm128.xcl -D_..X_HEAP_SIZE=10

-D_..X_CSTACK_SIZE=A0 -D_..X_RSTACK_SIZE=20 -D_..X_EXT_CSTACK_BASE=0 -D_..X_EXT_CSTACK_END=0 -D_..X_EXT_SRAM_BASE=0 -D_..X_EXT_SRAM_END=0 -D_..X_EXT_RSTACK_BASE=0 -D_..X_EXT_RSTACK_END=0

-D_..X_EXT_ROM_BASE=0 -D_..X_EXT_ROM_END=0 -D_..X_EXT_NV_BASE=0

-D_..X_EXT_NV_END=0 -e_small_write=_formatted_write

-e_medium_read=_formatted_read -f cfg3s.xcl

-D_..X_FLASH_BASE=_..X_INTVEC_SIZE -H1895

-h(CODE)0-(_..X_INTVEC_SIZE-1) -xsem -ws -l _lst\test_out_01_MemoryMap.txt -Fubrof8 -o _exe\test_out_01.d90

-Ointel-extended,(CODE)=_exe\test_out_01.hex

-Ointel-extended,(XDATA)=_exe\test_out_01.eep -ws

IAR Universal Linker V4.58A/386 Copyright 1987-2004 IAR Systems. All rights reserved.

5 884 bytes of CODE memory (+ 136 range fill ) 275 bytes of DATA memory

Errors: none Warnings: none

---------------------------------------------------------------------

Tue, 25 Jan 2005 09:12:53 +0100, na pl.misc.elektronika, Willy napisał(a):

THX - ale chyba na razie to odpuszczę i poczekam na release.

Mon, 24 Jan 2005 20:04:18 +0100, na pl.misc.elektronika, Ania i Grześ napisał(a):

Sorry, nie podałem kompletu - sprawdź na

-> forum avrgcc, powinien byc gdzieś na początku anons.

Odnowiłem też dystrybucję na

:

- avr-gcc 3.4.3 ( release ) z patchem obsługi stałych w formacie binarnym, wyjściem dla debuggera elf/dwarf2 i poprawionym zgrubnie błędem instrukcji MUL dla attiny 13/2313;

- binutils 2.15 ( bez nie wspieranego już konwertera elf-coff );

- najnowsze avr-libc 1.2.0 ( z manualem html otwieranym z poziomu menu AvrSide ).

Cały folder można rozpakować w dowolne miejsce bez nadpisywania istniejacych w WinAvr plików. Jeśli użyjesz AvrSide to wystarczy ustawić odpowiednio scieżkę dostępu. Jeśli używasz make - można wpisać żądaną wersję kompilatora do makefile ( CC = ... ) .