> > Napisałem procedurę w ASM i w C.
> > Oczywiście obie działają poprawnie.
> [ciach]
>
> Ja bym się aż tak bardzo nie ekscytował uzyskanymi wynikami.
Spokojnie. Wcale się nie ekscytuje. Przecież znałem z góry wynik.
Nie spodziewałem się tylko, że mechanika, jak na "głupie" układanie kody,
osiągnie nawet takie wyniki. Za naszego życia maszyna nie będzie lepsza od
człowieka.


> CPU procesora PIC18F2320 jest 16 bitowe
No tak w połowie, bym rzekł.
Jeśli mówisz o adresowaniu, no to rejestry FSRxH:L mają tylko 12-bitów,
więc do 4096 może i procedura się nie zmieni zbyt wiele po kompilacji.
O 100, może więcej instrukcji?
Spójrz na rysunek adresowania pośredniego:
ww1.microchip.com/downloads/en/DeviceDoc/39605b.pdf
strona 58AR (Acrobat Reader)/56DS.

Jak zapewne zauważyłeś, podałem w rozważaniach liczbę 5000.
Dla 5000 to naprawdę może kompilator przygotuje coś 16 bitowego.
Wtedy obawiam się, będzie dopiero tragedia.
A szyna danych jest z kolei 8-bitowa.
Jednak jeśli czytać ją z tablicy ROM to wtedy jest dopiero 16-bitowy procek.
Trudno tak rzec jaki on właściwie jest.

Na stronie 55(AC)/55DS Microchip podaje świetny przykład kasowania pamięci.
Dlaczego sam go nie stosuje?
Przecież można by go lepiej adaptować, nawet na kasowanie 16-bitowe.
Example 5-5
LFSR FSR0 ,0x100 ;
NEXT
CLRF POSTINC0 ; Clear INDF register then inc pointer
BTFSS FSR0H, 1 ; All done with Bank1?
GOTO NEXT ; NO, clear next
CONTINUE ; YES,

Oczywiście jest tutaj sprawdzany tylko przeniesienie z bitu 8 na 7 FSR,
ale przecież kompilator mógłby sobie poukładać w pamięci tak zmienne, aby
ostatnia kończyła się
na adresie modulo 256.
Przynajmniej do dwóch pętli w tym maleństwie dałoby się tak zrobić.
Ale ja też tak nie zrobiłem u siebie, a wyszło mi to krótsze.

> a Ty napisałeś program
> z pomieszaniem adresowania 8 i 16 bitowego.
Sam procesor juz pomieszany. Robiłem co mogłem.
Ja to nawet zrobiłem to 7-bitowo.

> Nic dziwnego, że
> kompilator dodał instrukcje konwersji typów. Bądż uprzejmy
> przepisać ten program na liczby i adresowanie 16 bitowe
> i dopiero wtedy porównać uzyskane rezultaty.
Taki szkielet. Nie widzę problemu (poza RAMem), aby go rozbudować.
Ale to będzie walka mojej głowy z głupim metakompilatorem.
Wynik obawiam się będzie jeszcze bardziej przerażający.
Myślę, że Ty z łatwością byś sobie też poradził.

> Oczywiście optymalizacja w C powinna być dla "release" a nie "debug".
Była ALL w drugim etapie.
Nie bawiłem się selektywnym klikaniem na checkboxy,
bo w totolotka nie gram :-)
Jednak nie sądzę, że przy jakiejś kombinacji da się coś uzyskać sensownego.
> Współcześnie sprzedawane kompilatory są często generowane przez
> metakompilatory, gdyż koszta zabiłyby producenta oprogramowania.
> K.
A tak zabijają nas kosztami:-)
Myślę, że wiesz, że musiałem spędzić wielokrotnie więcej godzin nad ASM.
W tym C to bajka - tylko kilka linijek :-)

S.