W dniu 2013-10-11 14:49, Sylwester Łazar pisze:
>> Ile czasu potrzeba, żeby przenieść kod ASM chociażby z M3 na M0, albo
>> M4? A może za trzy lata będzie PIC32 bądź jakiś Freescale? Nie mówię tu
> Kod z Microchipa na Freescale był przenoszony w marcu tego roku :-)
> Dokładnie i w całości pisany w asemblerze.
> Był to system odczytujący kilka DS18B21 pracujących na 1-Wire, z obsługa
> wyświetlacza,
> i jak to nazwaleś .... z bibliotekami graficznymi. Całość w ASM.

Ile tego kodu było i na jakie uC? Do odczytania temperatury i
wyświetlenia danych to i 1kB pamięci flash na kod jest za dużo. 200
linii źródeł w C będzie odpowiadało 400 liniom w asemblerze - do opanowania.
Co do bibliotek graficznych można mieć namyśli np. taką
http://www.ramtex.dk/ lub taką http://www.segger.com/emwin.html
albo tylko zestaw funkcji putpixel, line, circle, rectangle, color,
ewentualnie prosty bitmap i print. W tym drugim przypadku akurat wiele
kodu nie ma, w 300-700 bajtach kodu się zamknie ten zestaw funkcji
graficznych. Ale jak się chce coś poważniejszego zrobić to niestety kodu
bardzo szybko przybywa niezależnie od języka.

> Jednak myślenie na poziomie C jest nieco inne.
> W C przenosimy kod, mając nadzieję, że on się skompiluje po prostu innym
> kompilatorem i na dodatek będzie działał.
> Ja, przy moim podejściu nie przenoszę kodu asm pisanego za pomoca mnemoników
> na inny kod pisany za pomoc innych mnemoników.
> W ogóle nie interesuje mnie listing źródłowy.
> Ja po prostu na poziomie algorytmu - takiego na wydrukowanym papierze z
> programu 2D,
> skreślam stare mnemoniki i wpisuje nowe. Bloczki pozostają te same.

Chyba czegoś nie rozumiem. Asemblery nie różnią się tylko mnemonikami,
ale listą rozkazów, argumentami, liczbą rejestrów, ograniczeniami
każdego rejestru. Czym jest bloczek? i gdzie się podziewa ten asembler?
Bo chyba nie zastępujesz kompilatora wyższego poziomu?

> Mało tego, ja nie muszę pisać w asm. Czasem wpisuje po prostu instrukcje C,
> BASIC,
> czy inne.
> Bazą jest zawsze algorytm i jego bloczki, a nie kod źródłowy.

Tak chyba jest zawsze. Mamy algorytm i go zapisujemy za pomocą jakiegoś
języka programowania.


> Dzięki takiemu podejściu kod jest zwięzły i jest do niego pełna dokumentacja
> graficzna.
> Jeżeli powstanie nowszy język programowania - baza zostanie ta sama.
>
>> o programie, którego kod wynikowy to 1-5kB (po odliczeniu tablic
>> stałych). Tu chodzi o biblioteki graficzne, obsługę USB, TCP/IP, systemu
>> plików czy chociaż proste systemy operacyjne.
> Często jest tak, że kod 5kB odpowiada systemowi opracowanemu na innym
> poziomie abstrakcji, który ma 1MB.
> Pisanie w ASM jest zawsze krótsze i szybsze niż w czymkolwiek innym.
> To co zrobisz w systemie operacyjnym, z obcymi bibliotekami i własnym kodem,
> może zająć i 10MB.
> Jeżeli zrobisz to w asm, to może być i 5kB+tablice i RAM.

Co to są biblioteki obce? Czy biblioteka obcą jest ta napisana przez
mojego kolegę z pracy? Kilka tygodni pracy i działa na AVR.
Przeniesienie na STM32 to tylko grzebnięcie w HAL (jeśli występuje). Nie
skreślam przy tym mnemoników.
Co do objętości kodu to się zgodzę, że w C jest większy, ale bez
przesady - nie 5kB->10MB! Jeśli w bibliotece są niewykorzystane funkcje
to linker może je po prostu wyciąć z automatu.

>
> Wymaga jednak w części znajomości tematu, czyli procesora.
> Nie jest to jednak złe, gdyż wszystkie procesory mają bardzo podobną budowę.
> Różnią się szczegółami i liczbą stron karty katalogowych wraz z erratami.

To jest na plus. Zawsze dogłębna wiedza jest cenna. Pytanie jednak, jak
głęboko powinniśmy sięgać. No bo kupując w sklepie mleko, lody, chleb,
płatki kukurydziane, czekoladę, wodę powinniśmy czytać ich skład.
Napotykając powiedzmy karagen zgłębić wiedzę o nim czy jest rakotwórczy
czy nie. Wiedza bardzo cenna dla Twojego zdrowia - wybierasz pod tym
kątem wszystkie produkty, czy zdajesz się na odgórne przepisy, które nie
pozwalają na sprzedaż żywności zagrażającej życiu? Takich obszarów z
naszego otoczenia jest za dużo, żeby je zgłębiać.


--
Michał