| Kod nie jest przenośny, ponieważ każdy producent procesorów stosował swój własny (jak się nie mylę o to chodziło). |
Dokładnie, Intel miał swoją składnię, AT&T swoją, a inne firmy też robiły to po swojemu. Instrukcje też mogły być różne, zresztą same procesory były po prostu inne (różniły się fizycznymi połączeniami poszczególnych elementów, zestawem dostępnych instrukcji, wewnętrzny układ bramek logicznych był inny, właściwie wszystko mogło się różnić). Niby istniały pewne "standardy", na przykład część urządzeń bazowała na architekturze von Neumanna, ale tak właściwie to połączenia mogły być dowolne, byle działały szybko i bez większych problemów.
| skąd Wy, czerpaliście wiedzę o takich na przykład sprawach |
Ze wszelkich miejsc, które wydają się sensownym źródłem informacji. Parę lat temu z czystej ciekawości zajrzałem do asma, przerobiłem jeden dość stary kurs (ale na początek wystarczy -
http://bogdro.evai.pl/) i wróciłem do C++. Jakiś czas później po prostu potrzebowałem tej wiedzy (głównie do debugowania, bo od czasu do czasu trafiałem na dziwne błędy, których nie mogłem zignorować tak, jak kiedyś, więc zacząłem je w końcu naprawiać), następnie dowiedziałem się co nieco o inżynierii wstecznej (zahaczyłem o podstawy podstaw podstaw budowy kompilatorów, fazy translacji, optymalizacje, formaty plików wykonywalnych, zaciemnianie kodu, kod wykonywany jednorazowo w trybie "execute-only"), gdzieś w międzyczasie pisałem proste bootloadery pod tradycyjnego BIOSa (obecnie mam UEFI, ale okazało się, że producent jest ten sam i trafiłem na kolejną anomalię - może w końcu to naprawię używając C++, a nie asma?), chwytałem się różnych gałęzi informatyki i co jakiś czas trafiały się takie, gdzie trzeba było zejść na niższy poziom abstrakcji.
Wiele zależy od tego, co właściwie chcesz wiedzieć o asemblerze, z jaką architekturą procesora masz do czynienia, jakie cele sobie stawiasz. Zakładając, że chcesz to wykonywać na swoim komputerze, zapewne potrzebujesz wiedzy na temat x86, ewentualnie x64. Ja zacząłem od 16-bitowego trybu rzeczywistego, ale w przypadku tradycyjnych programów pewnie lepiej zająć się 32-bitowym trybem chronionym (i korzystać z tego, na co pozwala system operacyjny), można również od razu pisać aplikacje 64-bitowe. Możesz również sprawdzać, jaki kod generuje kompilator (przykładowe narzędzie do tego celu:
https://godbolt.org; czasami lepiej wyłączyć optymalizacje, aby łatwiej rozpoznać poszczególne kawałki) i starać się go zrozumieć, posiłkując się wszelkimi dostępnymi źródłami.
Dosyć szczegółowy opis jest dostarczany przez niektórych producentów, chociażby manuale Intela (mające obecnie nieco ponad 4500 stron, na przykład
http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf - ale tego się nie czyta od deski do deski, tylko szuka potrzebnych informacji). Są oczywiście także inne architektury, na przykład MIPS.