BG Development


Страници: (2) [1] 2   ( Първото ново мнение ) Reply to this topicStart new topicStart Poll

> Нова статия в asm32.info, По желание на трудещите се.
johnfound
Публикувано на: 13-12-2014, 10:12
Quote Post


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

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



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

Статията разглежда конструкциите if-then-else, switch/case, цикли от всички видове, подпрограми/процедури/функции предаване на параметри.

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

Пишете коментари: Какво не ви харесва? Какво трябва да се добави (в смисъл по темата на статията)? Какво не е обяснено достатъчно ясно?

Коментарите може да пишете под статията, може и тук, в тази тема.

Ето и връзка към статията: Глава 7. Общи конструкции



--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
farmdve
Публикувано на: 13-12-2014, 10:18
Quote Post



Име:
Група: Потребител
Ранг: Новопостъпил

Мнения: 45
Регистриран на: 16.07.07



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

Това мнение е било редактирано от farmdve на 13-12-2014, 10:19
PMEmail Poster
Top
johnfound
Публикувано на: 13-12-2014, 10:28
Quote Post


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

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



QUOTE (farmdve @ 13-12-2014, 11:18)
...само дето шрифта на сайта е прекалено голям и създава дискомфорт при четенето, особено при много текст.

Отдавна се канех да го намаля малко. Добре, че ми напомни. Натисни F5 icon_smile.gif


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



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

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



Много благодаря, точно това имах предвид icon_smile.gif
Чета я внимателно и после ще постна тук идеи, питанки, коментари и т.н.
PMEmail PosterUsers Website
Top
BIGBUGEX
Публикувано на: 13-12-2014, 16:04
Quote Post



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

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



QUOTE
В x86 архитектурата има специално разработени механизми за предаване на параметри чрез стека. Най-важния от тях е това, че инструкцията за връщане от подпрограма ret допуска числова константа, която указва колко байта от стека трябва да се извадят освен адреса за връщане. По този начин, подпрограмата може сама да почисти от стека изпратените ѝ аргументи, при това лесно и бързо. Този начин на предаване на параметри се нарича STDCALL. Процесорите нямащи тези възможности, са принудени да използват т.н. CCALL конвенция, където стека се почиства от викащата програма. Тази конвенция определено не е подходяща за програмиране на асемблер, защото замърсява сорса и вреди на четимостта.

Липсва информация кои регистри се запазват, кои се презаписват, и в кои се връщат стойности. Всъщност ccall има същественото предимство пред stdcall извиканият да не пипа стека. Лесно се поддържа подравнен до по-висок разред думи. Примерно 16 байтови. За справка 64 битовите конвенции на линукс и прозореца са дечица на cdecl и fastcall. Тактиката за избягване на чистенето е аргументите да са част от локалните данни.
PMEmail Poster
Top
johnfound
Публикувано на: 13-12-2014, 16:29
Quote Post


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

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



QUOTE (BIGBUGEX @ 13-12-2014, 17:04)
Липсва информация кои регистри се запазват, кои се презаписват, и в кои се връщат стойности. Всъщност ccall има същественото предимство пред stdcall извиканият да не пипа стека. Лесно се поддържа подравнен до по-висок разред думи. Примерно 16 байтови. За справка 64 битовите конвенции на линукс и прозореца са дечица на cdecl и fastcall. Тактиката за избягване на чистенето е аргументите да са част от локалните данни.

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

П.П. И да, CDECL, а не CCALL - все ги бъркам, трябва да го оправя.


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
BIGBUGEX
Публикувано на: 13-12-2014, 16:58
Quote Post



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

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



Нали трябва да извикаш някаква функция на операционната система на определен етап. Тва няма как да стане ако не знаеш от къде какво да очакваш. Подравняванията са важни за sse/avx код. Което е основното приложение на асемблера.
PMEmail Poster
Top
johnfound
Публикувано на: 13-12-2014, 17:22
Quote Post


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

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



QUOTE (BIGBUGEX @ 13-12-2014, 17:58)
Нали трябва да извикаш някаква функция на операционната система на определен етап. Тва няма как да стане ако не знаеш от къде какво да очакваш. Подравняванията са важни за sse/avx код. Което е основното приложение на асемблера.

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

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

Разбира се, аз лично смятам, че за всяка конкретна задача си има най-подходящ език за програмиране и името му е асемблер. icon_razz.gif

Това мнение е било редактирано от johnfound на 13-12-2014, 17:24


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



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

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



Статията наистина е супер.
Мисля, че идеологията на Assembler e, че няма строго определени конструкции всичко се реализира с инструкции и може в повече от един вариант
В каква посока най-вече са принципните разлики между fasm, nasm, gas и другите видове assembler-и ? Като синтаксис ли само ? Когато ги сравняваме за една архитектура, разбира се.

PMEmail PosterUsers Website
Top
johnfound
Публикувано на: 14-12-2014, 10:25
Quote Post


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

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



QUOTE (GigaByte @ 14-12-2014, 10:54)
В каква посока най-вече са принципните разлики между fasm, nasm, gas  и другите видове assembler-и ?  Като синтаксис ли само ? Когато ги сравняваме за една архитектура, разбира се.

Разликите между различните асемблери са значителни. Могат да се класифицират в две големи групи:

I. Разлики в синтаксиса на инструкциите. Тук има три вида синтаксис:

1. TASM IDEAL MODE: mov eax, [variable]
2. MASM: mov eax, variable
3. AT&T: movl variable, %eax

Последният е грозно извращение, което е замислено за изцяло машинна обработка, тоест C компилатора да генерира сорс в AT&T синтаксис, който после да се асемблира до бинарен код. Целта е била да е лесен за парсване, а не за четене от хора.

II. Разлики в макроезика и директивите за дефиниране на данни.

Тъй като тук стандарт няма, всеки асемблер си прави каквото си иска.

Аз лично съм фен на FASM - той използва първия синтаксис TASM IDEAL MODE и има много добре обмислен макро-език и директиви за деклариране на данни.

Това мнение е било редактирано от johnfound на 14-12-2014, 10:26


--------------------
asm32 - Приложно програмиране на асемблер.
Tox: 2B446ADCEC7E180CD4C59391D81D4CAB3E99CA7AE767DB3AB45AF976F8A2050FF071DDB733F1
PMEmail PosterUsers Website
Top
0 потребители преглеждат тази тема в момента (0 гости, 0 анонимни потребители)
Потребители, преглеждащи темата в момента:

Topic Options Страници: (2) [1] 2  Reply to this topicStart new topicStart Poll

 


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