Na temat assemblera krąży wiele mitów, że jest trudny, dla wybranych (to w sumie stara legenda, dziś mało spotykana), że daje olbrzymią kontrolę... wszystko to bzdury.
Pisanie dla trybu rzeczywistego (bootloadery czy DOS) generalnie nie ma sensu, zdecydowanie lepiej zająć się pisaniem pod tryb rzeczywisty ze stronnicowaniem (każdy sensowny OS), co w gruncie rzeczy do trudnych nie należy. Jest tylko kilka form kodowania instrukcji, co przekłada się na postać argumentów, instrukcji poza SIMD-owymi wcale nie jest tak dużo, głównie używa się i tak kilkunastu ogólnego przeznaczenia... Pisanie normalnego oprogramowania z użyciem zewnętrznych bibliotek naprawdę nie jest niczym trudnym, wiele trudniejsze niż C nie jest... ba, jeżeli o nieszczęsne wskaźniki chodzi to assembler w wielu wypadkach wygrywa. Inna sprawa, że łatwiej błąd popełnić, jego znalezienie do prostych należeć nie musi, przykład z życia: w skomplikowanym algorytmie 'literówka' - ebx zamiast edx, kompiluje się, prawie działa, tylko czasem wynik nie taki.
Assemblera zdecydowanie można się nauczyć w krótkim czasie - to kwestia zapamiętania kilku regułek i zestawu instrukcji. Manualem Intela podeprzeć się można zawsze, zaś klamotów związanych z programowaniem systemowym i tak nie pisze się z pamięci. Poznanie asma jest rzeczywiście korzystne aby zrozumieć jak to wszystko na niskim poziomie funkcjonuje, dać ew. podstawy do RE. To chyba jedyny sposób żeby przekonać się, że w tym co procesor czy oprogramowanie na najniższym poziomie nie ma żadnej magii.
Co do mitu o kontroli nad maszyną i innych podobnych - niemal wszystko da się uzyskać bez użycia grama assemblera, a jeżeli już stosuje się asma to korzystając z podręcznikowych wstawek. Tak samo nie jest prawdą, że do napisania wirusa (tak, malware'u infekującego pliki wykonywalne) potrzebny jest asm...
Od dobrych kilkunastu lat programy użytkownika i tak nie mają bezpośredniego dostępu do maszyny, nie korzysta bezpośrednio z portów czy przerwań sprzętowych. Zresztą ze sterownikami sprawa wygląda w dużej mierze podobnie - nawet tu nie ma beztroskiego grzebania się w sprzęcie, niemal wszystko przez API systemu. Sterowników nie pisze się w asm, używa się C, ew. C++ (chociaż tutaj dochodzi kwestia alokatorów itd.).
Jeżeli można asm opisać w kilku słowach to są to prymitywne klocki lego.
Co do szkodliwości assemblera to jest to w sporym stopniu prawda. Programowanie w asm jest prymitywne i diametralnie różne od pisania w czymkolwiek wyższym, nawet C. Od tego specyficznego sposobu myślenia trudno się uwolnić, zaś jego użycie w wyższych językach jest zwyczajnie katastrofalne w skutkach. Wielokrotnie podawałem przykłady tego, co z kodem robią kompilatory, że kod maszynowy nie jest odzwierciedleniem kodu źródłowego w C/C++/wtf. Asm skłania do pisania pod niskopoziomową reprezentację, utrudnia posługiwanie się sensowną abstrakcją, bardzo silnie utrwala prymitywne do bólu programowanie imperatywne, zmusza do myślenia nad pojedynczymi krokami implementacji, nie nad całościowym rozwiązaniem problemu.
Poza tym asm jest jak BASIC albo Cobol, ryje psychikę, robi dziury w mózgu i zjada koty.
Mimo wszystko warto się tym chwilę pobawić. Proponowałbym potem posiedzieć np. nad Haskellem, może i potem nie napiszesz już ani linii w Haskellu, ale już nigdy nie będziesz w innych językach pisał tak samo jak wcześniej.
Gyn by mi nie wybaczył gdybym nie podlinkował jego videotutoriali - http://re.coldwind.pl/