И така, защо асемблер?

Много от професионалните програмисти, както и много от авторите на книги за програмиране твърдят за асемблера, че не става за приложно програмиране. Възраженията обикновенно са:

Много е труден за учене и е много далече от човешкото мислене.

Програмите са много нечетливи.

Сорс файловете стават много големи.

Трябва да се мисли за ненужни неща, като регистри и флагове, вместо да се мисли върху алгоритъма на програмата.

Прекалено машинно ориентиран е и програмите, написани на него се пренасят трудно или въобще не се пренасят на други платформи.

В тази статия, ще се опитам да опровергая тези твърдения, както и да дам някои други доводи, защо писането на приложения на асемблер е похвална тенденция.

1. "Много е труден за учене и е много далече от човешкото мислене"- и двете твърдения са изключително некомпетентни.

Разбира се за да станеш асемблер-гуру, трябва много труд и четене, но това може да се каже и за всеки друг език за програмиране. А за да се научи базата, достатъчна за да се пишат прости програмки, са достатъчни само няколко часа. Трябват само подходящи справочници, някои малък пример и компютър, защото асемблера, за разлика от много други езици е практически език и най-добре се учи, докато човек си играе с някоя примерна програмка. Разбира се, някой приятел, когото да попиташ е още по-добре, но за това ще поговорим другаде на този сайт.

Oтносно твърдението, че "асемблера е далеч от човешкото мислене", мога да кажа: "Точно обратното!". Асемблерът е много близко до човешкото мислене, за разлика от някои други aлгоритмични езици като "C" и "C++". Това е така, защото повечето езици от високо ниво са "математически" и "абстрактни" езици. Измисляни са от хора с математическо образование и начина им на изразяване е много далече от нормалната човешка логика. Достатъчно е да си припомним, колко трудности имат децата с алгебрата в училище, за да видим, че формули от вида: a = (b+c)/d изискват специално обучение за да бъдат разбрани. Асемблера от своя страна, е практически и алгоритмичен и може да се сравни с начина по който мисли човек. В него няма абстрактни формули, а конкретни стъпки, които трябва да се направят, за да се реши задачата. Горната формула, записана по този начин ще изглежда така: "събери b и c", "раздели на d", "запиши в a". Може би не е по-кратко, но за сметка на това е пределно разбираемо.

2. "Програмите са много нечетливи и трудно се документират." - Какво да кажа за тава твърдение. Ако някой ви каже така, просто го попитайте, колко асемблерски програми е написал през живота си.

Митовете за нечетливостта на асемблера са чиста измислица! Разбира се на всеки език може да се напише нечетлива програма. За това много талант не се иска. Има една дзен поговорка: "Всеки глупак, може да напише програма, която компютърът да разбере. Изкуството е, да напишеш програма, която човек да може да разбере!"

Защо програмите на асемблер са по-лесни за документиране и четене, от тези написани на "C" например. На първо място начинът на записване на програмата на асемблер е строго формализиран - една инструкция на ред във вида:

Както виждате, пределно просто! Няма ги десетките вложени скоби, няма дълги редове, които трябва да се разглеждат половин час за да се разбере че нищо не правят. Повече от половината ред остава за коментар. Въобще, коментарите в асемблерските програми играят важна роля. Добрите програмисти, винаги коментират кода си. Виждал съм програми в които коментарите са повече от командите. Това естествено води до пределна разбираемост на идеите на автора.

3. "Сорс файловете са огромни! За 2KB exe, пишеш 20кбайта сорс." - Да, обаче всъщност , сорсовете на "C" ще бъдат същите или само малко по-малки (например 15кбайта), а изпълнимият файл ще бъде 200 кбайта при същата функционалност на програмата. (А, ако си говорим честно, на Delphi например, не може да се напише програма за Windows по-малка от няколко стотин килобайта, ако човек не е наистина експерт в езика) Освен това, при пределната формализация на командите на асемблер, писането става изкючително бързо. И освен това, голяма част от програмата (ако е написана малко или много грамотно) са коментари, които четем с благодарност, когато се опитваме по-късно да усъвършенствуваме програмата.

4. "Трябва да се мисли за ненужни неща, като регистри и флагове, вместо да се мисли върху алгоритъма на програмата." - В отговор на това мога да кажа - В езиците от високо ниво е същото, трябва да мислим за "излишни неща" - променливи, обекти, файлове, вместо да се съсредоточим върху това което алгоритъмът трябва да прави. Забелязвате ли приликата. Регистрите и флаговете в асемблера, са това, което са променливите в езиците от високо ниво. Нищо не ви пречи да си пишете алгоритъма, не "мъчейки се със", а "използвайки" същите тези регистри и флагове. Както се оказва, всичко е въпрос на нагласа и предубеденост.

5. "Прекалено машинно ориентиран е и програмите, написани на него се пренасят трудно или въобще не се пренасят на други платформи." - Въобще въпросът за преносимост на програмите на други платформи е много спорен и далеч не толкова ясен, колкото се опитват да го изкарат някои автори. На първо място преносимостта има две страни:

1. Преносимост на друга операционна система, при същият процесор.

2. Преносимост на друг процесор.

Oтносно първият вид преносимост, асемблера не е по лош от всеки друг език. Проблемите при този вид пренасяне са свързани с особенностите на различните операционни системи и за да може една програма да се пренесе тя трябва да е замислена, като преносима, още от самото начало. Можете да сте сигурни, че повечето програми писани на "C" всъщност не могат да се пренасят на други ОС без да се пренапише по-голямата част от кода.

От друга страна има програми писани на асемблер, които са пренесени и работят под много платформи без всякакви проблеми. Например превъзходният компилатор FASM, който освен че умее да компилира сам себе си, държи своеобразен рекорд в портирането на други платформи: той работи засега под 4 различни операционни системи: "DOS", "Win32", "Linux" и "Menuet" и не е никакъв проблем да се прехвърли на която и да е нова операционна система за 2..3 дни. Нещо с което не всяка "C" програма (освен може би "Hello world!") може да се похвали.

Що се отнася до вторият вид портиране, то тук нещата са малко по-сложни. Макар, че съм срещал програми за конвертиране на асемблер между intel и motorola процесори, те не са получили голямо разпростреанение и очевидно на никого не са нужни. Просто тук нещата трябва да се разглеждат от малко по-друг ъгъл.

Проблеми с подобен род портиране имат не само асемблерните програми, но и повечето от програмите писани на езици от високо ниво.

На второ място, следва да се зададе въпроса, на кого е нужно да пренася програми от една платформа на друга? Това е изключително рядък случай (бих казал направо хипотетичен). Вярно е, че големите фирми пускат един и същ продукт например за Apple и PC, обаче, съдейки по различната функционалност, факта, че различни екипи от програмисти се занимават с версиите за различни компютри и принципно различните бъгове в двете версии, може да се твърди, че те не портират един и същ код, а го пренаписват, като се запаза само функционалността.

Разбира се същият подход спокойно може да се използва и при асемблера. Още повече, че огромна част от асемблерните алгоритми се превеждат изключително лесно "по смисъл" а не "буквално" на асемблер за други процесори.

И така, след като оборих (е някои от вас няма да се съгласят с мене) митовете, които се разказват за асемблера, задължително трябва да посоча и някои плюсове на този език:

1. Програмите написани на асемблер стават малки. Ама наистина малки. Съвременният програмист и потребител дори не могат да си представят мащаба на това понятие. Например пълноценно приложение за векторна графика: "EVE 3.54" е само 75кбайта! На една дискета 1.44 мбайта могат да се съберат 19 такива програми и ще остане място!

Дори такова огромно приложение като средата за визуално програмиране на асемблер Fresh IDE, има размер 235KB в които влиза огромна функционалност, за улеснение на писането на програми на асемблер.

Енджина на този сайт (също написан на асемблер) има в момента размер около 10KB. Предишната система, която използвах, беше написана на PHP и при подобна функционалност имаше размер 17KB без да броим огромният PHP интерпретатор, който се стартираше за да се изпълни скрипта.

2. Да казвам, че програмите написани на асемблер са бързи, не е нужно. Това всеки го знае. И това дори не е заради ръчната оптимизации. Човек никога не може да оптимизира една програма изцяло за съвременните процесори.

Компилаторите се справят с това значително по-добре. Работата обаче е там, че на асемблер се реализират по съвършенно естествен начин много алгоритми, които на езиците от високо ниво е много трудно да се напишат точно по този начин.

Това, което на C++ се брои за последен стадии на оптимизацията и което тотално срива четимостта на програмата и затова се прилага в краен случай и само за ограничени участъци от кода, на асемблер - поради различният синтаксис, се реализира изключително чисто и четливо и обикновенно е първото нещо, за което програмиста се сеща при писане на програмата.

Освен това пишейки на асемблер, човек държи под контрол цялостното поведение на програмата на много ниско ниво. Винаги се знае, точно къде е тясното място на алгоритъма и се оптимизира точно там. Ефекта е, че програмите се получават по-бързи и по-малки от еквивалентните програми, писани на езици от високо ниво.

Ето и един пример - компилатора FASM е написан наистина без никакви специфични оптимизации за даден процесор. Ако въобще може да се говори за оптимизация, то тя е за процесори 80386. Въпреки това, FASM е най-бързият асемблер (при сравнима функционалност разбира се) и изпреварва конкурентите си написани на C в пъти.