Dzięki.
No faktycznie fajny kod.
W pętli głównej sortowania użyli tylko 14 instrukcji.
Jest to zrozumiałe, ze względu na możliwość adresowania indexowego.
I faktycznie użyli X(Rn),Y(Rm).
Tyle, że szacowałem, że użyją 3x, a użyli 5x.
No i w wersji bajtowej.
1) Pokazuje to niefrasobliwość tego co robi kompilator, bo mając do
dyspozycji przesuwanie
całych słów, korzysta z bajtu.
Ślepy indianin już zauważy, że te dwie instrukcje:
ADRDOUT[j][0] = ADRDIOD[i][0]
ADRDOUT[j][1] = ADRDIOD[i][1]
mogą być wykonane za pomocą jednego rozkazu, a nie jak tutaj:
mov.b 0x110A(R14),0x1114(R15)
mov.b 0x110B(R14),0x1115(R15)
Nigdy nie pisałem na MSP430, ale zapewne należałoby użyć:
mov 0x110A(R14),0x1114(R15)
2) Albo tutaj.
Kasowanie w pętli:
008022 clr.b 0x111E(R12)
for(i = 0 ; i < k ; ++i)
inc.w R12
cmp.w R13,R12
jl 0x8022
Tutaj 2 błędy:
a) po co kasować po bajcie, skoro w pętli można kasować po słowie?
i zmniejszyć liczbę obiegów o połowę!
b) dlaczego nie jest użyta autoinkrementacja.
16-bitowy MSP430 nie ma rozkazów z inkrementacją R12++?

Reasumując:
Kompilatory, mając do dyspozycji świetne rozwiązania techniczne producenta,
doskonale je marnują.
Dla zmylenia przeciwnika dają w opcjach rzekomą możliwość wybrania metody
optymalizacji
i żadna nie zauważa takiej gafy?
S.