T.M.F. pisze:

>> Pomijając już tą nieszczęsną promocję do inta, to najbardziej w tym
>> kodzie rozwaliło mnie wyłuskiwanie 6 bitu.
>
> Promocja do int wynika ze standardu C wiec trudno tu robić zarzut
> kompilatorowi. Żeby to ominąć wystarczy explicite typecastowac.

Wyraźnie napisałem, że nie promocja jest tu największym problemem.
Zresztą rzutowanie i tak tego nie poprawia.

>> Łatwo policzyć, że poniżej 8 parametrów bardziej opłaca się wersja z
>> rcall (program optymalizowany na rozmiar).
>
> Tu sprawa nie jest tak oczywista. Co prawda rcall są krótsze w sensie
> długości kodu, ale zajmuja 3 takty zegara.

Specjalnie napisałem, że optymalizacja była ustawiona na rozmiar, więc
rcall powinno mieć pierwszeństwo.

>
> To zalezy zapewne od zdefiniowanej przez ciebie funkcji tab_size(tab).
> Kompilator za każdym obiegiem petli musi ja wywołać, żeby wilczyć wynik
> dla danego argumentu - dlaczego? Bo ja źle zdefiniowałeś.

Zapomniałem wstawić. Oto kod:

#define tab_size(__a) (sizeof(__a)/sizeof(__a[0]))

Jeśli według ciebie jest źle zdefiniowana, to czekam na poprawki.

> Sprawdziłem to u siebie i nic takiego się nie dzieje. Musiałem
> zdefiniować dodatkowo dziwna funkcje Babla bo mi kompilator to
> optymalizował i ją wywalał.

Ja na potrzeby przykładu w ogóle jej nie zdefiniowałem (nie jest to
potrzebne, disasemblację zrobiłem po kompilacji, bez linkowania).

>> A podobno gcc ma super optymalizator do pętli (widocznie moja wersja
>> gdzieś go zgubiła).
>
> Jak ci nie pasuje gcc to zaproponuj cos lepszego...

Chciałeś przykłady, to ci je pokazałem. Nie jest w tym przypadku istotne
czy inne kompilatory zrobiłyby to lepiej (a myślę, że IAR byłby lepszy).

> Jak ci nie pasuje gcc to zaproponuj cos lepszego... nie mowiac juz o
> tym, ze masz kod źródłowy wiec możesz się wykazać dla potomności :)

Dzięki, już kiedyś próbowałem (na innym porcie gcc). To nie jest robota
na 1 dzień, a ja mam swoją pracę.