Объясните, зачем использовать ASM, когда есть BASM ?

Просьба к админам удалять флудорестичесике топики

 

Оффтоп
Интересно, а данный топик является флудорестическим?

 

Потому что ты не открыл им эту тайну ...

 

DevilDevil

Я в основном пишу на Дельфи, в т.ч. с ассемблерными вставками. Но если писать что-то крупное и целиком на асме (как вариант -- большой модуль, все процедуры которого на асме), то удобнее, скорей всего, будет отдельный ассемблер. В частности, встроенные ассемблеры не имеют макросредств, не поддерживают условную трансляцию, не всегда имеют полный набор машинных инструкций, не позволяют вручную управлять сегментацией (хотя использование плоской модели памяти в Винде сводит необходимость в ней к минимуму)... В общем, полно ограничений.

 

DevilDevil
S_Alex, посмотри [6] ... и ответь на 4)
Можно я отвечу на вопрос "4) а что кроме геморроя дают "масм, фасм, тасм, насм....."?
Дает ощущение, что ты управляешь работой процессора (или через порты в/в другим железом, например, видео, аудио и т.п.), т.е. не компилятор/интерпретатор сгенерировал код, а ты сам изловчился, а если это получится компактно, быстро и надежно, то вообще кайф.

 

Мне к примеру никакого гемора они не дают.
Когда пишешь на АСМе то используй макросредства. Количество, как ты сказал геморроя, уменьшиться.

У многих программистов есть набор своих библиотек и макросов, которые используются и очень успешно.

Код (Text):

1. $INCLUDE(..\..\Inc_SA\macros.inc)
2.  
3.  
4. $INCLUDE(..\..\Inc_SA\INT_VT_H.inc)
5. ; -------------------------------------------------------------------------
6. UseKBD
7. UseLCD
8. UseLED
9. UseUART
10. UseDAC
11. UseTimer
12. ; -------------------------------------------------------------------------
13. $INCLUDE(..\..\Inc_SA\Header.inc)
14.  ; Global  TC2H
15.  ; Global  TC2L
16.  ; Global  TC1H
17.  ; Global  TC1L
18.  ; TickCount   equ TC1L
19.  
20.  
21.  
22. ReadTimeOut set 2
23. Global  vTimeOutLeft
24. Flag    fReceive
25.  
26. XVAR    ReceiveDATA,32
27.  
28. Global  vNSZ        ;Зона нечувствительности релейного регулятора
29. Global  vSet        ;Задание регулятора
30. Global  vCurVal     ;Текущее значение измеряемой величины
31.  
32. Reset:
33.     mov     SP,#30h ;Установка "вершины" стека
34.                     ;Стек растет вверх! ???
35.                    
36.                    
37.    
38.    
39.    mWAITmsn   100
40.  
41.     mInitUART 9600  ;Настройка порта на скорость передачи 9600 бод
42.                     ;используется Т/С 1.
43.     mInitTimer0 100 ;Настройка таймера для работы часов реального времени
44.     mInitRTC        ;Сброс часов реального времени
45.     call    CLRTickCount
46.     setb    EA      ;Разрешить все прерывания
47.     mUARTIntOn      ;Разрешить прерывание от UART
48.     mInitBuffer UART_IN_Buffer
49.     mInitBuffer UART_OUT_Buffer
50.  
51.     mInitLCD
52.  
53.     mInit5x7
54.  
55.     call    InitDinam
56.  
57.     call    Init_ST
58.  
59.     mCODEPAGE
60.  
61. ;    mStop
62. Idle:
63.     clr     EA
64.      
65.     call    Fresh
66.     setb    EA
67.     jmp     Idle

Можно сказать что это написано на АСМе, ну так с первого взгляда.
Многие программисты (С, Pascal, Delphi) смотрят и не могут поверить, что на АСМе можно так писать, да еще и на МК.
Если есть подборка хороших макросов и библиотек, то писать на АСМе куда приятнее.

 

q_q
+1

GOD MODE

 

SII, внимание! Первый толковый ответ!

> В общем, полно ограничений...
что есть - да, но у меня не создалось впечатление, что полно.

- вопрос сегментации ИМХО не актуален.
- набор инструкций... Delphi давно SSE2 поддерживает. Кроме того, чего греха таить, большинство пишет на Си, где давным давно ASM-64 и остальные расширения поддерживаются.
- макросы кстати тоже поддерживаются Си-шными компиляторами.
- а что такое "условная трансляция" ? Условная компиляция в ЯВУ поддерживается.

 

S_Alex, мда.....

- ЯВУ полюбому поудобннее будет
- к ЯВУ обычно неплохие IDE прилагаются, где комментарии поудобнее помечаются; но это лирика.

В общем, я всё понял!
- есть ряд задач, с которыми BASM просто не справится. Для остального есть BASM
- есть такая парода людей, которая вечно усложняет себе жизнь, разбавляя её ИЗЛИШНЕЙ рутиной.

Всех участников благодарю.

 

сишные макросы не сравнимы с макросредствами того же масма или фасма

 

DevilDevil
Не я конечно понимаю, что Delphi рулез и всё такое. Тем более что Rem на нём писал, или пишет. Но по мне допустим какую-нибудь прогу перехватчик проще писать на Masm, чем на Basm. Так как в основном там код нетривиальный, на ассемблере его писать проще, а окошки там не нужны. То есть помимо вирусов и другие проги на ассемблере писать проще.

 

20000 лет живу, а про BASM как таковой только что увидел.
если имеется в виду возможность компиляции ассемблерного кода компилятором языка программирования (например C или Delphi), то компании, производящие данное программное обеспечение не всегда успевали добавлять новые инструкции процессоров, в то время как выходили всё новые и новые процессоры.
ИМХО компиляторы устаревают быстрее, чем процессоры обновляются.

 

Почти дословная цитата из руководства по Дельфи : "Вот энтот компонент лучше использовать - вот такойто - такойто фирмы, а не системный. Он ненамного увеличит размер экзешника - всего на 900 килобайт, и стоит всего 30 долларов, но зато программа будет работать лучшее".

 

DevilDevil

Потому что Вам, надо полагать, не приходилось писать достаточно крупные программы на ассемблере. Например, поползновения MASM с его Invoke отчасти направлены на упрощение программирования системных вызовов, хотя лично мне было бы куда приятнее иметь нормальные макросредства (у MASM они не дотягивают до уровня мэйнфреймов), где системные вызовы кодировать было попроще (в частности, не требовалось помнить, что в каком порядке передаётся -- для этого служили так называемые ключевые параметры макрокоманд, что-нибудь вида RUN TASK=MYTASK,PRIORITY=100 и т.д. (этот макровызов мною выдуман, просто он иллюстрирует идею)).

Смотря что писать. При "рядовом" программировании под Вин32 -- действительно неактуален. А вот, например, загрузчик ОС с диска ты без сегментации (в том или ином виде) не напишешь, поскольку там используется код и реального, и защищённого режима.

Есть ещё всякие хитрые инструкции, коих может и не быть в Си, хотя лично я не проверял. А вот отсутствие SSE3/4 и т.д. в Дельфи может и раздражать, если они тебе нужны (у меня реальной нужды не было, так что я лишь обозначил принципиально возможную проблему).

Макросредства Си, как и сам Си -- просто кю. Если б Винда была написана на Аде, она только за счёт этого работала бы куда надёжнее

Она и есть. Но, опять-таки, возможности ЯВУ более ограниченны, чем у хорошего макроассемблера.

Смотря для чего. Например, в своё время я от неча делать написал на Паскале драйвер принтера для RSX-11. Всё работало, всё было нормально, но попотеть пришлось -- кошмар. В то время как на асме он писался в 10 раз быстрее (и был заметно короче, естесно).

Вот это как раз не лирика: отсутствие IDE весьма сильно мешает по-настоящему продуктивной работе с асмом. Правда, на IA32 (x86) этому ещё больше мешает идиотская система команд...

Стопудово

А вот это не всегда верно. Например, написание ядра ОС на ассемблере приведёт к увеличению его эффективности (при условии, конечно, что там не понаделают ошибок выше крыши, но это уже другой вопрос) по сравнению с ядром, написанным на ЯВУ, а это скажется на производительности всей системы в целом. А вот писать какую-нибудь команду dir или copy на ассемблере никакого смысла нет: прирост скорости будет незначительным и явно несопоставимым с объёмом геморроя, связанного с таким программированием.