Akik szeretik az Assemblyt, mi az, amit leginkább szeretnek benne?

Én azt, hogy így legalább értem, amit csinálok, mármint a részletességét a dolgoknak, hogy működik a számítógép.

Csak hobbiból tanulnám, de mivel nagyon nehéz nyelv, és nem is nagyon tanítja senki, így nem tudom megtanulni.

Nem hiszem, hogy olyan nagyon magas lenne azok száma, akik szeretik az assemblyt. Az csak szükséges rossz. A ma uralkodó szemlélettel nézve, inkább utálják azok, akik rákényszerülnek a használatára. Nehézkes, körülményes nyelv. A szokásostól eltérő gondolkodásmódot és alapos hardverismeretet igényel. Idegesítő, hogy amit egy magas szintű nyelvben fél óra, óra alatt megvalósít az ember, ugyanahhoz assemblyben legalább egy nap kell, vagy még több.

Nem véletlen, hogy komplett alkalmazásokat már nem fejlesztenek asmben, csak a legritkább esetben, ha az tényleg elkerülhetetlen.

Az asm hozadéka ott mutatkozik meg, hogy a lehető leggyorsabb és legkisebb lehet a benne fejlesztett program, vagy programrészlet, ezért annak első és másodlagos tárigénye, műveletigénye csekély, valamint ott, hogy nincs semmiféle korlát a hardverhez való hozzáférésben, annak programozásában, hacsak az oprendszer le nem korlátozza egy utasításhalmaz használatát az adott processzoron.

100 %-ban assemblyben lefejlesztett nagyalkalmazás volt a Lotus-123 nevű "excel ős", vagy a Borland Pascal compilere.

"és nem is nagyon tanítja senki" Sajnos ez így nem igaz. Inkább olyanok tanítják akiknek nem kéne. Valamelyik szakokon van ilyen tárgy. Találkoztam már olyanokkal akiknek "taníották" egyetemen /hogy BSC, vagy MSC nem emlékszem, én a végeredményt láttam amit tudott a hallgató aki jött hozzánk friss diplomás junior pozícióra/. Az egyikük annyit mondott, hogy úgy érezték, hogy még a tanáruk szerint is "komplett h*ség az egész".

Mi napi szinten használjuk, bár egyre inkább kihalóban van. Mi főleg PIC mikrokontrollerre (meg néha AVR) fejlesztünk. És ahol a kódméret-sebesség-funkcionalitás lényeges ez van, nincs más.

Fejlesztettünk már ARM-ra is assemblyben, szintén a kódméret és a sebesség miatt. A boot loader volt C-ben megírva (mert találtunk rá ingyenes open source változatot és nekünk az jó volt), de maga az a rész amit érdemben csinált valamit assemblyben készült.

Miért szeretem?

1./ Mert alig függ a fordítótól az eredmény. Mert ott azt csinálja a proci ami le van írva. Nem kell azon gondolkodni, hogy hogyan fogja a fordító pl. az a^b hatványt fordítani, és ennek milyen következményei lesznek.

2./ Beágyazott rendszereknél, mikrokontrollereknél van egy többé-kevésbé hatékony C fordító (de pl. az optimalizálója erősen fizetős és drága), amelyik úgy nagyjából jót tud fordítani. De amikor időkritikus az egész ott jobb sokszor leszámolni az utasításokat. Pl. a PICnél lehet tudni, hogy mennyi egy utasítás végrehajtási "ideje" (órajel ciklusban). Ha az ember ügyes (esetleg pár plusz semmit nem csináló utasítással) szépen be lehet "játszani" akár azt is, hogy ha a program elágazik a két ág egyforma idő alatt fusson le /ez sokszor nagy követelmény tud lenni/. Volt olyan, hogy ezeket részeket a C fordító kioptimalizálta. Sok esetben (igaz sok-sok munkával és sok-sok tapasztalattal) képesek vagyunk jobban kioptamlizálni a kódot mitn amire a fordító képes. Volt egy ilyen munkánk, jött a megrendelő, hogy az adott vezérlő elektronikából kell neki 50 000 db. /valami sorozatban gyártott cuccba került/, és optimalizáljuk be a kódot, hogy egy 12 centtel olcsóbb mikrokontrollerbe beférjen, aminek az lett az eredménye, hogy pár más következménnyel együtt darabonként 16centet "nyertek rajta" 16 cent*50 000 db=8000 USD a különbség, 3500 USD-ből kioptimalizáltuk és így a cég nyert csak ezen 4500USD-t. És mindenki happy volt. Ők a nagy víz másik oldalán képesek még így számolni. Igaz ritka egy 50 000 db-os széria, kisebb széria esetén nem érné meg /pl. ha csak 20 000 db. készül akkor már nem érte volna ez meg/.

3./ Amikor (be)tanítjuk a hozzánk kerülő junior programozókat legalább fél évig /ez a betanulási időszak fele kb./ szinte csak assemblyben tanítjuk őket. Miután ez áll legközelebb a procihoz assemblyben ha már képes olyan programot alkotni ami lefut és többé kevésbé azt csinálja, amit szeretne akkor kb. kezdi megérteni, hogy hogyan is működik egy proci, és kb. mi történik ha lefuttat egy programot. UItána kerül az éles fejlesztésbe ahol C-assembly párosban fejlesztünk.

4./ Nyilván egy nagyobb alkalmazást nem fogok assemblyben megírni (pl. egy Gyakorikrdesek.hu-hoz hasonló web alkalmazást), de nem egy részét simán.

Alapvetően az a jó, ha olyan ember tanítja, aki aktívan használja is a nyelvet.

Nekem olyan ember tanította, aki elég mélyen benne van, de magam inkább C nyelven programozom.

Egyébként az Assembly (mármint Macro Assembly) is könnyen és gyorsan használható, miután az ember felépítette a saját kis moduljait.

Tény, hogy Assembly nyelven sokkal kisebb és jó programozó esetén optimálisabb kódot lehet írni mint C-ben, és bizonyos helyeken (főként mikrokontrollereken) van is létjogosultsága.

...ha viszont át kell térni egy másik platformra (pl. másik gyártó mikrokontrollerére), az csak nagyon nehezen oldható meg...

A C azért jó, mert univerzális kódot lehet írni benne, ha kell, tartalmazhat Assembly betétet, viszont másik mikrokontrollerre (vagy akár x86-ról ARM-ra) áttérni nem akkora mutatvány.

...és modernebb periféria kezelését (pl. USB, Ethernet) leprogramozni nem kis mutatvány lenne Assemblyben.

Assemblynél teljesen a te kezedben van a hardver (akármi is legyen az konkrétan), emiatt jól ki lehet használni azt, és olyan dolgot is meg lehet valósítani, amire más nem feltétlenül képes az adott hardveren.

C már egy magasabb szint, emiatt könnyebb hardvert is váltani alatta, de még elég hardver-közeli tud lenni.

Egy adott nyelv akkor lesz szerethető, ha elég jól beleássa magát az ember és ráérez az "ízére", a Macro Assembly pl. teljesen új utat tud nyitni a hagyományos Assembly programozáshoz képest.

7-hez (2022.06.15. 01:08) kiegészítésként: Igen nehezebb áttérni egyik rendszerről a másikra, maga a kód általában át sem vihető. De az alepvető módszerek igen. Nagyjából mindegy, hogy LD vagy MOV utasítás mozgatja két regiszter között az adatot. Az alapvető logikai modell nagyjából hasonló. Az igazi különbség a CISC és a RISC között van, a RISC egészen más megközelítéseket igényel. De két RISC proci között nincs annyira tolságosan nagy különbség, ugyanígy két CISC proci között sincs. A CISC és a RISC "család" között már ténylegesen van.

Az assembly esetén még sok esetben nehézkes (de ez sokszor a dokumentációk hiányossága is), hogy a syscall-ok sokkal bonyolultabbak mint pl. egy C esetén. Pl. egy totál egyszerű dolog, ami a C-ben megoldható egy malloc() fv. hívással (ő majd a háttérben elintézi a memória foglalást, feltöltést meg egy raksá mindent) itt egyenként végig kell menni a lépéseken, kérni az oprendszertől memóriát, azt feltölteni a kezdő értékkel stb. Ugyanígy egy fájl írás sem annyi, hogy fopen() és fprintf(). És itt sokszor doksi sincs rendes, hogy ezt hogyan implementáld az adott oprendszeren. C-hez megvannak a libek, meg a hozzá tarotzó manok de assemblyhez nagyon kevés.

"Sajnos ez így nem igaz. Inkább olyanok tanítják akiknek nem kéne."

Lényegtelen, a lényeg, hogy nem lehet megtanulni.