BG Development


Страници: (39) [1] 2 3 ... последна »  ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Портируеми програми на асемблер, да преборим митовете...
johnfound
Публикувано на: 28-04-2012, 20:34
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7189
Регистриран на: 27.05.04



В тази статия искам да подложа на съмнение една уж "аксиома", че асемблера не е портируем език.

Всъщност, портируемостта има различни лица. Трябва да се различава портируемост на ниво процесор/хардуер и портируемост на ниво "операционни системи".

Работата е там, че когато се говори за портируемост, в повечето случаи става въпрос за портируемост на ниво различни ОС. Портируемостта на ниво различни процесори е нужна доста по-рядко по няколко причини:

1. Системите с различни процесори често се различават изключително много по хардуерни възможности, което пречи на повечето сериозни програми да работят на друга платформа. Примерно, за смартфон със 4 инчов дисплей са нужни едни програми, а за настолна работна станция с два монитора по 40 инча и четириядрен процесор, съвсем други. И тук не става въпрос за това дали програмите могат да се портират, а дали ще има нужда от тях на дадената платформа.

2. Ако говорим за настолните компютри (PC) то огромната част от тях са на базата на процесорите x86 и архитектурата на IBM PC. Дори Apple се отказаха от различните процесори и архитектури. Причините за това са много и не са предмет на тази статия, но факта си е факт. Напоследък дори се говори за смартфони с процесори x86 (intel Atom).

Що се отнася до портируемостта на ниво "Операционна система", за нея също се смята, че е монопол на езиците от високо ниво.

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

Именно наличието на стандартната библиотека на C прави възможно да се портират програми от Windows в Linux и обратно.

Но и тука има особенности. Стандартната библиотека обикновенно поддържа много беден интерфейс с операционната система (за да е лесно портируема). Това е и причината повечето програми под Linux да имат конзолен интерфейс - просто стандартната библиотека не поддържа друг.

Разбира се, развиват се и библиотеки за графичен интерфейс - тъй наречените GUI toolkit - като GTK+, Qt, FLTK и др.под. които дават възможност да се пишат портируеми програми с графичен интерфейс.

При тях обаче има друг проблем. За да се постигне висока портируемост, тези библиотеки използват многослойна архитектура. На най-ниското ниво са функциите, които за ОС зависими, а на по-високите нива са ОС независимите функции и API достъпно за потребителските програми.
Многослойните библиотеки обаче имат недостатъка да са бавни. И то, колкото са по-бавни функциите на долните нива, толкова по-бавни стават целите библиотеки. Защото едно малко забавяне във функция, която се вика отвсякъде и често се превръща в голямо забавяне в цялата програма.
Факт е, че всички портируеми програми с графичен интерфейс са поне двойно по-бавни от подобни програми, писани само за една ОС.

Как стоят нещата при асемблера?
Първата наистина портируема програма, написана на асемблер, е компилаторът FASM. Това е забележителен компилатор, който е портиран на всички по-важни операционни системи. При това е написан на чист 100% асемблер. (всъщност FASM е написан на FASM).
Независимо, че доказва на 100% концепцията за портируем асемблер, FASM все още е конзолна програма. Наистина, има графична версия за Windows и ДОС (минималистично IDE около компилатора), но графичната част не е особенно добре портируема. Може би в бъдеще ще се появи и версия за Линукс.

Преди няколко години, аз самият започнах проекта Fresh който представлява мощна визуална среда за програмиране на асемблер. Средата Fresh беше базирана на Windows API и поради това е съвършенно непортируема (а не защото е написана на асемблер).
С развитието на проекта обаче, започнаха да се проявяват и недостатъците на този подход. Например FASM като компилатор може да компилира програми за Линукс. Fresh също може да компилира програми за Линукс, обаче каква полза, когато тези програми не могат да се тестват под Windows?

Беше намерено временно решение - andLinux, а може да се ползва и Wine под Линукс. Обаче всичко това са си кръпки и беше очевидно, че ако искам да мога да работя свободно и по един и същ начин в Линукс и Уиндоус, проекта ще трябва да се направи портируем.

Бяха проучени различните GUI toolkit варианти и за съжаление, нито един от тях не отговаряше на изискванията на асемблерното програмиране. Наистина - не може да се използва примерно един Qt който изисква няколко десетки мегабайта библиотеки за да осигури работата на програма, която макар и с огромна функционалност, заема един файл с размер 235kB.
Да не говорим, че програмите базирани на такива библиотеки са направо тромави в сравнение с програмите базирани директно на API-то на операционната система.
А за една среда написана на асемблер, да е бавна не е опция.

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

Така беше започнат проектът FreshLib. Предположението, че библиотеката ще може да държи нивата на абстракция на възможният минимум се оправдаха напълно.

Въобще библиотеката има само 2 нива: ОС-зависим слой, който е изключително малък (за по-лесно портиране) и ОС-независим слой, който осигурява API-то за приложните програми.

От своя страна, ОС-зависимият слой е базиран на възможно най-ниското възможно ниво. Във Windows - на Win32 API функциите, а във Линукс, директно на XLib.

Това прави програмите базирани на FreshLib малки и бързи.
Наистина, леко увеличаване на размера се наблюдава, спрямо програми директно базирани на съответната ОС, обаче това увеличение е няколко килобайта, а не десетки мегабайти.

Ето тука и един снимка от екрана, на която е показана една и съща програма (текстов редактор) компилирана за Windows и Linux (съответно .exe и ELF файл). В единият случай, програмата е изпълнена във Windows XP, а в другият на Ubuntu Linux.
Компилира един и същ сорс файл. Единствено, на компилатора се задава опция за каква ОС да се компилира:

user posted image

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

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


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
Mihail121
Публикувано на: 28-04-2012, 20:39
Quote Post



Име:
Група: Потребител
Ранг: Редовен член

Мнения: 417
Регистриран на: 10.03.07



Остава да се разбере и кого точно го интересува icon_confused.gif
PMEmail Poster
Top
BIGBUGEX
Публикувано на: 28-04-2012, 23:36
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1553
Регистриран на: 30.11.04



Всичко това щеше да е вярно, ако не беше се пръкнало амд64. Асемблер + "С" е оптималното решение ако ще се поддържат 32 и 64 битови версии. За текстов редактор не е проблем да няма 64 битова версия. Но за image-processing функционалност е грубо да не се възползваш от двойно по-големите регистрови файлове.
[off] Единственото нещо което ме дразнеше във фреша, беше странната идентация и липсата на таб знак. Добре е да има таб знак. [/off]
PMEmail Poster
Top
johnfound
Публикувано на: 29-04-2012, 00:24
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7189
Регистриран на: 27.05.04



Относно 64 битовите програми, аз лично имам малко по-специално мнение:
1. Ако програмата работи добре в 32 битов режим, то едва ли и трябва 64 битов.
2. Ако и трябва 64 битов режим - просто трябва да се напише като 64 битова и толкова.
3. Въпреки, че 64 битовите процесори са на пазара от много време, нещо не се забелязва изчезване на 32 битовите. Защо ли? Впрочем обработката на изображения не печели чак толкова от 64 битовият режим, колкото се очакваше.
4. Ако нещо е чак толкова критично, нищо не коства да се направи програмата да съдържа различни модули и да се компилира в два варианта. И изобщо намесването на C в случая нито помага нито пречи.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
Stilgar
Публикувано на: 29-04-2012, 02:14
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 12411
Регистриран на: 13.05.08



Не съм прочел дългите писания, но подозирам че "портируемостта" на български език се нарича "преносимост"


--------------------
Опитахме се да го направим както трябва, но стана както винаги.
PMEmail PosterUsers Website
Top
dvader
Публикувано на: 29-04-2012, 06:03
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 4355
Регистриран на: 12.07.05



Всички изложени тези важат за всички програмни езици, особено в частта, отнасяще се за конкретните OS. Мисля, че ако препишем същата библиотека на С (че и на С++) и запазим архитектурата и нивото на абстракция, ще получим почти същите резултати, където "почти" ще се различава много много малко.

Имаше време, когато и аз мислех, че ASM е уберезика и даже си бях написал (под ДОС) GUI система за 16/32 borland/symantec/watcom, докато един ден не погледнах какво генерира компилатора ми и установих, че случаите, в които мога да напиша по-добър код са много малко. В днешно време бих казал, че само ползването на SIMD/MMX инструкции е една област, в която компилаторите все още са назад. В ортодоксалното програмиране предимствата, които дава чистия ASM са важни само за много inner loop-ове.

Edit:
Бих добавил, че понятието "преносимост" може би трябва да се подоуточни. На който език и да пишем имаме слой, който е OS-зависим и е *различен* за различните OS. В случая с ASM ще имаме различни имплементации на едно и също за всеки процесор. Кое е преносимото тогава?

Това мнение е било редактирано от dvader на 29-04-2012, 06:05


--------------------
I find your lack of faith disturbing
PM
Top
johnfound
Публикувано на: 29-04-2012, 06:48
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7189
Регистриран на: 27.05.04



dvader, има един много хубав разказ "Краткият път на госпожа Тод". Та там имаше един израз "Ако спестиш достатъчно разстояние, в крайна сметка ще спестиш време." (дори да караш по черните пътища)
Същото става и с програмите писани на асемблер.
По принцип има истина в това, че съвременните компилатори генерират добър код. Но забележи - като правило програмите написани на асемблер са в пъти по-малки и като резултат по-бързи.

Веднага мога да дам и примери:
FASM е най-бързият компилатор за асемблер в момента. При това дори не е правен опит да се оптимизира кода. Размера на последната версия е 99k.

Операционната система KolibriOS се събира на дискета 1.44МБ, и се стартира за 3 (три) секунди с пълноценен графичен интерфейс.

Тези размери са абсолютно непостижими за език от високо ниво. Парадокса се обяснява с това, че когато една програма се пише на асемблер, програмиста просто мисли в други категории и използва такива конструкции, които не би използвал в програма на език от високо ниво.

Сега относно преносимостта: Преносимостта винаги съдържа непреносим код, специално написан за всяка операционна система. Разбира се, че е така, но това важи за всеки език за програмиране. Няма преносимост "просто така".
В случая с FreshLib преносими са програмите написани с използване на библиотеката - те не съдържат ОС-зависим код съвсем.
Библиотеката разбира се съдържа такъв код, но на абсолютният минимум, така че да може да се портира лесно на нови системи.

Това мнение е било редактирано от johnfound на 29-04-2012, 10:02


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
GigaByte
Публикувано на: 29-04-2012, 09:07
Quote Post



Име: ГБ
Група: Потребител
Ранг: Редовен член

Мнения: 533
Регистриран на: 19.08.09



Преносимост означава и лесна поддръжка за програмистите.
Това означава лесно писане, четене и редактиране на обемен код.
За не малка част от програмистите обемен код от език на високо ниво
е по-лесен за разбиране от същия обем код на език като асемблер.

PMEmail PosterUsers Website
Top
johnfound
Публикувано на: 29-04-2012, 10:00
Quote Post


Group Icon
Име:
Група: VIP
Ранг: Почетен член

Мнения: 7189
Регистриран на: 27.05.04



GigaByte, лесната поддръжка и разбирането на сорс кода няма нищо общо с езика за програмиране. (на мене например програмите на C винаги са ми изглеждали като каша от фигурни скоби.)
Това зависи само от знаенето на езика от конкретните програмисти и от качествената организация на проекта.
Понятия като структурно програмиране, коментари, модулност са общовалидни при програмирането на асемблер, както при всеки друг език.
При това, асемблера, поради строгият синтаксис има една крачка предимство пред езиците в които програмиста има свободата да си подрежда кода както си иска.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
BIGBUGEX
Публикувано на: 29-04-2012, 11:52
Quote Post



Име:
Група: Потребител
Ранг: Почетен член

Мнения: 1553
Регистриран на: 30.11.04



Мен ми е по-интересно какво смяташ за таба? Идето е най-доброто за фасм, респект за което. За това и ми се струва важен казус.
PMEmail Poster
Top
0 потребители преглеждат тази тема в момента (0 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (39) [1] 2 3 ... последна » Reply to this topicStart new topicStart Poll

 


Copyright © 2003-2019 | BG Development | All Rights Reserved
RSS 2.0