W dniu 11.06.2009 10:16, Grzegorz Kurczyk pisze:
> Dziękuję wszystkim za odzew :-)
>
> Metody opisywane przez Kolegów męczyłem już wcześniej (poza przesiadką
> na C++), ale nie przynoszą one spodziewanego rezultatu. Może sprecyzuję
> o co mi chodzi. Sprawa jest czysto "akademicka" i wynika z mojego
> pewnego rodzaju "zboczenia" w dążeniu do absurdalnej optymalizacji kodu
> wynikowego ;-)
> Jest tak. Funkcja zdefiniowana tradycyjnie:
>
> void ProgressBar(char x, char y, char w, char h, char value) {
> ....
> }
>
> przy wywołaniu:
> ProgressBar(0, 90, 128, 5, y);
>
> otrzymujemy w kodzie wynikowym:
> 37e2: 0b 2d mov r16, r11
> 37e4: 25 e0 ldi r18, 0x05 ; 5
> 37e6: 40 e8 ldi r20, 0x80 ; 128
> 37e8: 6a e5 ldi r22, 0x5A ; 90
> 37ea: 80 e0 ldi r24, 0x00 ; 0
> 37ec: 0e 94 b4 17 call 0x2f68 ; 0x2f68 <ProgressBar>
>
>
> I to co mnie "wkurza", to czemu łachudra przekazuje parametry w
> rejestrach r16, r18, r20, r22, r24 niejako promując typ char do int ?
> Jakby nie mógł po kolei r16..r20.

Jakiej wersji gcc uzywasz? Ja tu nigdzie nie widze promocji do int bo
starsze czesci tych rejestrow nie zawieraja zera.

> Oczywiście w tym przypadku nie ma to większego znaczenia, ale przy
> większej ilości parametrów przekazywanych do funkcji i/lub większej
> ilości zmiennych lokalnych funkcji, zaczyna się kombinacja ze stosem lub
> z dolnymi rejestrami. Kompilator w pewnym sensie "szatkuje" sobie obszar
> rejestrów doprowadzając do sytuacji, że w pewnym momencie brakuje np
> czterech kolejnych rejestrów do zapamiętania lokalnej zmiennej typu long
> choć pojedynczych wolnych rejestrów jest wystarczająca ilość.

Sprawdz jak to sie zachowa przy wiekszej ilosci parametrow. Zapewne
kompilator bedzie oszczedniej gospodarowal rejestrami. Zauwaz, ze w
twoim przykladzie nie ma takiej potrzeby, a wygenerowany kod jest tak
samo efektywny.

--
Inteligentny dom - http://idom.wizzard.one.pl
http://idom.sourceforge.net/
Teraz takze forum dyskusyjne
Zobacz, wyslij uwagi, dolacz do projektu.