> No dobra, ale teraz miej 10K takich instrukcji i zrob optymalizacje
> ercznie
>
> A.L.
Zauważ proszę, że takie myślenie jest podobne do niekontrolowanej reakcji
atomowej.
Jeżeli wyciągniemy pręty, jak w Czernobylu, zaraz się okaże, że co drugi kod
potrzebuje 1TB dysku.
Taka optymalizacja mechaniczna jest protezą, źle napisanego kodu.
Studiowanie MIPSów i tych chorych DELAY slots, zmuszała mnie do
przestawiania instrukcji, czy funkcji
na poziomie, nie mechanicznym, a logicznym.
Czuło się tak, jakby dwie procedury należało nałożyć na siebie jak firanka z
zasłonką,
aby wykonywały się równocześnie.
Żaden kompilator tego nie zrobi lepiej. Może najwyżej poprawić coś, co się
przeoczyło.
Jednak zgadzam się z tym, że te sloty to niepotrzebne utrudnienie.
Gdzieś wyczytałem, że w starych rozwiązaniach był jeszcze problem DELAY
slotów.
Jednak zwalanie całej roboty na kompilator i ufanie w jego nadzwyczajne
możliwości, jest
też na wyrost.
Toż przecież jeśli programista nie podglądnie jak będzie wyglądał jego kod
po skompilowaniu,
to zadowala się tym co jest, jeśli jakoś tam działa. Długość kodu w ogóle go
nie interesuje.
Jeśli nie starczy - wybierają większy chip.
A program ma regulację dwupołożeniową zrobić :-)

Jeżeli przyjrzysz się temu co wyprawia kompilator w środowisku MPLABa, to
zauważysz,
jak odkłada na stos wszystkie rejestry (tak na wszelki wypadek pewnie :-)),
a potem robi "r5++" i następnie ściąga z mozołem tobołki ze stosu.
A to tylko dlatego, że jest procedura obsługi przerwania i tak przyjęli
twórcy kompilatora.
Piszę też w C. Jednak do aplikacji działających w okolicy ~Tcy, kompilator
psuje możliwości
kontrolera. Wtedy trzeba brać większą kostkę i lepszy kompilator.
Potem już tylko Windows i robią się te 10k kody.
To zdecydowanie nie moja działka.
Ja lubuję się w zwartych i szybkich rozwiązaniach i przekroczenie 2k kodu to
rzadkość.
Zostawiam pole 10k dla innych :-)
S.