mert nem látja az ember, mi van ott
No, ugye.
Pont ezért kellett az assume direktíva, hogy ne kelljen banksel-t írnod, hogy tájékoztasd a fordítót arról, hogy az egyébként is BSR-ben levő érték érvényes. Ráadásul kódot sem generál. A harmadik előnye, hogy áttekinthetőbbé teszi a kódot.
Ha most megtekintenéd a példa kódot kicsit feljebb, akkor beláthatod:
- Kicsit hosszabb PName esetén nem öröm beverni egy egész oldal "dw bötű,0" zagyvaságot, hogy egy stringet leírjál.
- Nem fogod eltéveszteni.
- Ha az egyszer jól megírt makró készen van, akkor egyetlen sorral tudsz usb decriptort definiálni.
- Ha csak ennyit látsz: "mkDescriptor Product, USB_STRING_DESCRIPTOR_TYPE, PName", akkor sokkal áttekinthetőbb a kód, mint egy oldalnyi dw esetén.
Rendesen megírt makrókkal könnyen olvasható kódot lehet előállítani akár kommentelés nélkül.
A Microchip fejlesztőitől kezdve, a sok kiváló C++ programozó soha nem dolgozott macro assemblerben. Valószínűleg Te sem, mert akkor nem kevernéd össze egy "gépelést könnyítő fícsörrel". Pedig a makró pont olyan feladtokat tud megoldani, amit a C makrókkal lehetetlen leírni. Próbálj meg elszakadni a rövidke, egy emberes hobbiprojekttől! Képzeld el, hogy egy nagyobb programot 5-6 ember tervez és programoz egyszerre. Gyakran volt olyan, hogy egyes algoritmusokhoz vagy matematikai leíráshoz értő kolléga tervezte a program egyes részeit. Majd kezébe adva a forrást, leelenőrizte a megvalósítást. Közben sem az adott processzorhoz, sem ahhoz az assemblerhez nem értett, komment meg alig volt. Csak elolvasta.
Ha egyszer a fejedben lakik a bitvadász (már pedig ezt tudjuk :), akkor egy műveletet jól meg tudsz fogalmazni az utasítások sorozatával. Erre rá lehet húzni még az algoritmust, folyamatábrát és kicsit cifrázni. Ekkor már régen nem a gépies behelyettesítést végzi a marózás. A végeredmény olyasmi, mit a yacc, csak még flexibilisebb.
De az igazi bézbólütő: Te sem C-ben programozol, pedig biztosan úgy is le tudnád írni ugyanazt. :-D