32 битов Асемблер.

Има ли фенове на т'ва жи'отно? SoftIce (DriverStudio)? IDA 4.x?
Ето един интересен форум:

[линк]

Опитайте и тук:

[линк] - един от най-добрите асемблери за x86 (Windows, Linux, DOS) Безплатен, отворен код.

и тук:
[линк] - същият асемблер със визуална среда (е не е завършена още. )

Напоследък асемблера от незаслужено пренебрегван език се възражда малко по малко. Познавам хора, които пишат дори счетоводни програми на асемблер. Резултатите са забележителни. Дори среден до голям проект (като функционалност) се събира на дискетка, зарежда се светкавично и работи бързо дори на стари компютри. А това че разработка била много бавна е повече мит, отколкото реалност.

В отговор на:

---

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

---

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

--
Екстремно програмиране на български.
[линк]

В отговор на:

---

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

---

Специално за счетоводен продукт, последно четох за такъв в един руски форум, че се пише в момента. Каква ще му е цената нямам понятие. Както казах, асемблера се възражда едва напоследък и няма кой знае колко големи проекти завършени докрай. Специално аз съм писал програми за вътрешна употреба във фирмата в която работя с използване на MS SQL Server. По скоро малък проект, общо взето ми отне 2..3 дни, след пускането имаше само един бъг за оправяне и вече 5..6 месеца се работи денонощно с тази програма.

А предимствата на програмите писани на асемблер можеш да го усетиш само като го видиш. Напоследък се занимавам в свободното си време с проекта Fresh - [линк]
Това е (ще бъде) напълно визуална RAD среда със средства за бърза разработка именно на комерсиални приложения.
Та този Fresh в момента е 170 кбайта, може да компилира всичко (себе си също) и мисля че към края ще е около 300кбайта напълно завършен. Зарежда се и работи като notepad.

Ето и някои други изцяло асемблерни проекти:

[линк] - редактор за векторни изображения. swg, wmf, emf (експорт в gif и jpeg) - един от първите подобни проекти. 74 кбайта. Комерсиален, има безплатна версия. Затворен сорс.

[линк] - ICQ клиент изцяло на асемблер. В процес на разработка. Около 30кбайта. Отворен сорс. Това е форум. За да сваляте файловете, трябва да сте регистрирани.

[линк] - Операционна система. 1.44Мбайта. Пълнофункционален "true color" GUI.

[линк] - Toolbar Paint - Редактор на изображения за тулбарове. 54кбайта компресиран. Безплатен. Затворен сорс.

Ей стига глупости, това са ентусиасти на които им се пише на АСМ. Не виждам чак толкова големи предимства на АСМ пред С. А да се пишат счетоводни програми на АСМ и да се правят изчисления на АСМ - си е пълна глупост ако не се прави за фън.

Е, както вече казах, трябва да го изпиташ сам за да разбереш. Аз съм писал професионално на почти всичко, Ц, Ц++, Паскал, Делфи, Форт, Пърл, обаче откакто се заех по-сериозно с асемблер за Windows, всичко друго започна да бледнее. :)
Има много митове създадени за асемблера. Повечето от тях са просто митове.
Ето тук съм се опитал да изложа проблема малко по-широко:
[линк] - статията "Защо асемблер?"

А между другото най-елегантните изчислителни алгоритми съм ги виждал реализирани именно на асемблер, където имаш контрол буквално върху всеки бит от данните.

Всъщност изобщо не искам да започвам flame-war на темата Asm vs HLL. Който иска, да си пише чудовищните многомегабайтови програми и да казва на потребителите си че им трябва нов компютър за всяка следваща версия. А и в повечето случаи езика се определя от шефовете, според модните за момента думички.

[линк]

Браво, абсолютно точно го каза:

"А и в повечето случаи езика се определя от шефовете, според модните за момента думички."

Обаче е пулно с "хентелегентни" програмисти, дето не могат да се усетят, че точно шефовете им ги водят в грешна посока. Даже започват да си самовнушават, че еди-коя си нова "модерна" дума е наистина по-добра.
Примерно тука някой разправяше, че .NET бил по-бърз от C.... Какво да си говорим повече....
Аз лично не бих писал на ASM, освен ако наистина не ми се налага за някоя и друга функция или алгоритъм. По-добро от C++ насам, за сега няма според мен.

Хаиде да не бъдем голословни и да разкажеш как се пишат елегантни изчислителни алгоритми на АСМ ? Няма да започваме flame-war на тази тема, просто искам да разясниш като човек които се занимава с това. Аз също съм писал на АСМ за Windows но не мога да се съглася с теб че получаваш кой знае каква мощ. Можеш да пипаш стека директно, регистрите, регистъра с флагове и още някои други специални архитектурни особености. Лесно ти се вижда защото викаш мощни Win32 функции, но пробвай да направиш една хештаблица на АСМ, като искам да ползвам произволен тип за key и value. Предполагам ще ползваш нетипизирани указатели, които ще ги алокираш в хийпа и т.н. Както казва един гуру - "комилатора е пръв приател на програмиста", с чиято помощ си открива грешките рано, и не се налага да помни обременяваща информация, спестява си писане и т.н. Какво прави АСМ компилатора в това отношение ?

Ами добре, хайде да опитаме. С хеширане няма да се занимаваме сега, тези техники във всеки език са за напреднали. Обаче можеш да отидеш на fresh.flatassembler.net , да си изтеглиш пакета (500к е и сорса е вътре) и да погледнеш във файла LabelsList.asm Там широко се работи с големи масиви от стрингови данни (етикетите на компилираният текст) и се използва хеширане и дървета за ускоряване на работата. Тук ще покажа две мои малки функцийки, които конвертират dword число в стринг в произволна бройна система от 2 до 16.
Двете функции (със знак и без знак) заедно са 35 байта. Можеш да се опиташ да го направиш на някой друг език:

;| NumToStr:

;|   Converts signed integer value to string.

;| NumToStrU:

;|   Converts unsigned integer value to string.

;|

;| EDI - pointer to string buffer

;| EAX - Number to convert

;| ECX - radix from 2 to 10h



NumToStr:

        test    eax,eax

        jns     NumToStrU

        neg     eax

        mov     byte [edi],'-'

        inc     edi



NumToStrU:

        cmp     eax,ecx

        jb      .less



        xor     edx,edx

        div     ecx

        push    edx

        call    NumToStrU

        pop     eax



.less:

        cmp     al,$0a

        sbb     al,$69

        das



        mov     [edi],ax

        inc     edi

        ret

[линк]<P ID=&quot;edit&quot;><FONT class=&quot;small&quot;><EM>Редактирано от JohnFound на 27.05.04 18:38.</em></font></p>

В отговор на:

---

Algoritmite v obshtia sluchaj ne zavisqt ot ezika, a ako e taka - znachi neshto ne naret s kompilatorite za dadenata arhitektura.

---

А в частните случаи? А всъщност повечето случаи са частни. В пределите на една програма някои от случаите могат и обикновенно се обобщават до един по-общ случай, за да могат да се обработват от едни и същи подпрограми. Компилаторите обаче обобщават в пределите на ВСИЧКИ програми, така че получаваш неща които нито ти трябват, нито си ги искал. Освен това има алгоритми които действително се реализират по лесно и естествено на асемблер: опитай някой път нещо с интензивна манипулация на битове и тогава ще говорим.

В отговор на:

---

Mnogo rqdko, ama naistina mnogo radko daden kod moje da e po-byrz ako e na ASM. Zaslujava si samo na bottle neck mestata, no maj i tova ne si stuva mnogo, shtoto se gubi portability ...

---

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

В отговор на:

---

Za size-a - da verno che kompilatorite harchat poveche pament, no k'vo pyk, tq e evtina veche.

---

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

В отговор на:

---

Inache ASM e naj-polezno za :( GNIREENIGNE EVISREVER ...

---

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

[линк]

Не пиши на асемблер.

--
Increasing performance by lowering expectations.

Така ли пише в книжките: "Стани Гуру за 24 часа" ?

[линк]

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

Искам да направя един анализ на статията "Защо асемблер"...

В отговор на:

---

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

---

Започваш с фактологическа грешка. Като човек, познаващ малко или много 3 асемблерни езика ще ти кажа, че езикът изобщо не е един. Дори има две големи секти: RISC и CISC в проектирането на машинни езици и асемблери.

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

Без лоши чувства. Аз съм просто един уеб дебелопер дето е видял лесното. Между другото, продължавам да се чудя дали има някаква бизнес стойност в писането на асемблер за уиндоус.

--
Екстремно програмиране на български.
[линк]

Е, работи само с полож. числа и със radix <= 10 и е 80-тина байта, което си е 2 пъти повече от твоята.:0
Но пък е (малко) по-четлива:)
----------------------------------------------------------------------
void __fastcall DoItoa(int num, char** str, int radix)
{
if(num)
{
DoItoa(num/radix, str, radix);
*(*str)++ = num % radix + '0';
}
}
void __fastcall Itoa(int num, char* str, int radix)
{
DoItoa(num, &str, radix);
*str = 0;
}

Дешев, за съжаление си започнал да четеш грешна статия. Сайта е с фреймове и трябва да кликнеш отляво на навигацията "Защо асемблер?" А това което цитираш е въведението в сайта и е написано в художествена форма. (все пак да се четат само сухи наръчници не е добре за душевното здраве) Освен това целият сайт е замислен като за съвсем начинаещи, така че известно опростяване на материята може само да е полезно. Не мислиш ли?

Относно комерсиалното приложение на асемблерни програми мога да кажа следното: Ако имаме две аналогични по функционалност програми, например на Delphi и асемблер, тази на асемблер ще бъде при всички случаи значително по-малка (вероятно 1/5 до 1/10 от размера на делфийската) и значително по-бърза (от 2 то 10 и повече пъти, зависи от много неща) Времето за разработка на асемблерната, вероятно ще е по-голямо, но максимум с 50%. (В това отношение нещата се подобряват от ден на ден с появата на нови инструменти)

[линк]

В отговор на:

---

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

---

Бъгове разбира се има, колкото във всеки друг език. Разбира се, бъговете не са същите като тези от езиците от високо ниво, но са същите като количество. Нещата обаче не са чак толкова страшни. Забиването на компютъра е много рядко явление - аз работя под Win98 и не си рестартирам компютъра по цели дни. Освен това при дебъгването има едно много удобно нещо, че дизасемблираният код в дебъгера е много, много близко до това което си писал в сорсовете. А има и дебъгери на ниво сорс код и всеки ден се появяват нови инструменти. Определено моето впечатление е, че програмите на асемблер са по-стабилни от тези написани на езици от високо ниво.

В отговор на:

---

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

---

В днешно време да се говори за програмиране на каквото и да е без библиотеки и повторно използване на кода е смешно. Всичко това го има и в асемблера, разбира се. Между другото един интересен пример - мислиш ли че на Ц++ например ще се пише много лесно без библиотеки?

[линк]

В отговор на:

---

Е, работи само с полож. числа и със radix <= 10 и е 80-тина байта, което си е 2 пъти повече от твоята.:0
Но пък е (малко) по-четлива:)

---

Ако обобщим - два пъти по-малко функционалност при 2 пъти по голям обем. А за четливостта - зависи главно какво си свикнал да четеш.

[линк]

В отговор на:

---

целият сайт е замислен като за съвсем начинаещи, така че известно опростяване на материята може само да е полезно. Не мислиш ли?

---

Точно като за начинаещи ми изглежда подвеждащо. Заради такива книги и статии съм убил предостатъчно време да се правя на "истински мъж" и да дялкам асемблеризми с примитивни средства. Е никой не ми е виновен, грешката си е моя, но защо и други да я правят?

В отговор на:

---

Ако имаме две аналогични по функционалност програми, например на Delphi и асемблер

---

Ще се опитам да засегна темата за езиците от по-високо ниво. За мен обектите са жизнено важно нещо. Те са най-лесният начин, който познавам за изграждане на абстракцията в една система. Може би трябва да отделя повече време за научаване на функционално и логическо програмиране, но за аргумента тук и обектното ще свърши работа. Ако почна да пиша на асемблер сигурно първото нещо, което ще си направя ще е библиотека за пакетиране на данни и функции, които работят с тях в един "модул". Второто сигурно ще е възможност да променям някои от функциите и да добавям данни. Е това в другите езици се нарича дефиниция на клас, наследяване и виртуален метод. За какво, бога ми, да го пиша по-бавно и по-зле от кода, който ще ми генерират вече готовите компилатори?

И не съм съгласен, нито за същото количество дефекти нито за само 50%-ото увеличение на сроковете. А дори и да съм съгласен -- 50% са ужасно много. Все едно конкуренцията да извади 2 пъти повече функционалност само защото аз дялкам с брадва, а те имат моторни резачки.

--
Екстремно програмиране на български.
[линк]