Tooprogram.ru

Компьютерный справочник
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Ассемблер или си

Связь ассемблера с языками высокого уровня

Существуют следующие формы комбинирования программ на языках высокого уровня с ассемблером:

  • Использование ассемблерных вставок (встроенный ассемблер, режим inline ). Ассемблерные коды в виде команд ассемблера вставляются в текст программы на языке высокого уровня. Компилятор языка распознает их как команды ассемблера и без изменений включает в формируемый им объектный код. Эта форма удобна, если надо вставить небольшой фрагмент.
  • Использование внешних процедур и функций. Это более универсальная форма комбинирования. У нее есть ряд преимуществ:
    — написание и отладку программ можно производить независимо;
    — написанные подпрограммы можно использовать в других проектах;
    — облегчаются модификация и сопровождение подпрограмм.
Встроенный ассемблер

При написании ассемблерных вставок используется следующий синтаксис:

КодОперации задает команду ассемблера,
операнды – это операнды команды.
В конце записывается ;, как и в любой команде языка Си.
Комментарии записываются в той форме, которая принята для языка Си.
Если требуется в текст программы на языке Си вставить несколько идущих подряд команд ассемблера, то их объединяют в блок:

Внутри блока текст программы пишется с использованием синтаксиса ассемблера, при необходимости можно использовать метки и идентификаторы. Комментарии в этом случае можно записывать как после ;, так и после //.

Пример Даны целые числа а и b. Вычислить выражение a+5b.
Для вывода приглашений Введите a: и Введите b: используем функцию CharToOem(_T(«Введите «),s) ,
где s – указатель на строку, которая перекодирует русскоязычные сообщения.

Для компоновки и запуска программы создаем проект как описано в разделе Создание консольных приложений .
Проект будет содержать 1 файл исходного кода с расширением cpp.
Результат выполнения программы:

Использование внешних процедур

Для связи посредством внешних процедур создается многофайловая программа. При этом в общем случае возможны два варианта вызова:

  • программа на языке высокого уровня вызывает процедуру на языке ассемблера;
  • программа на языке ассемблера вызывает процедуру на языке высокого уровня.

Рассмотрим более подробно первый вариант.
В таблице ниже представлены основные соглашения по передаче параметров в процедуру.
В программах, написанных на языке ассемблера, используется соглашение передачи параметров stdcall . Однако по сути получение и передача параметров в языке ассемблера производится явно, без помощи транслятора.
При связи процедуры, написанной на языке ассемблера, с языком высокого уровня, необходимо учитывать соглашение по передаче параметров.

СоглашениеПараметрыОчистка стекаРегистры
Pascal (конвенция языка Паскаль)Слева направоПроцедураНет
C (конвенция С)Справа налевоВызывающая программаНет
Fastcall (быстрый или регистровый вызов)Слева направоПроцедураЗадействованы три регистра (EAX,EDX,ECX), далее стек
Stdcall (стандартный вызов)Справа налевоПроцедураНет

Конвенция Pascal заключается в том, что параметры из программы на языке высокого уровня передаются в стеке и возвращаются в регистре АХ/ЕАХ, — это способ, принятый в языке PASCAL (а также в BASIC, FORTRAN, ADA, OBERON, MODULA2), — просто поместить параметры в стек в естественном порядке. В этом случае запись

Процедура some_proc , во-первых, должна очистить стек по окончании работы (например, командой ret 16 ) и, во-вторых, параметры, переданные ей, находятся в стеке в обратном порядке:

Этот код в точности соответствует полной форме директивы proc .
Однако можно использовать упрощенную форму, которую поддерживают все современные ассемблеры:

Главный недостаток этого подхода — сложность создания функции с изменяемым числом параметров, аналогичных функции языка С printf . Чтобы определить число параметров, переданных printf , процедура должна сначала прочитать первый параметр, но она не знает его расположения в стеке. Эту проблему решает подход, используемый в С, где параметры передаются в обратном порядке.

Конвенция С используется, в первую очередь, в языках С и C++, а также в PROLOG и других. Параметры помещаются в стек в обратном порядке, и, в противоположность PASCAL-конвенции, удаление параметров из стека выполняет вызывающая процедура.
Запись some_proc(a,b,c,d)
будет выглядеть как

Вызванная таким образом процедура может инициализироваться так:

Трансляторы ассемблера поддерживают и такой формат вызова при помощи полной формы директивы proc с указанием языка С:

Регистр EВР используется для хранения параметров, и его нельзя изменять программно при использовании упрощенной формы директивы proc .
Преимущество по сравнению с PASCAL-конвенцией заключается в том, что освобождение стека от параметров в конвенции С возлагается на вызывающую процедуру, что позволяет лучше оптимизировать код программы. Например, если необходимо вызвать несколько функций, принимающих одни и те же параметры подряд, можно не заполнять стек каждый раз заново, и это — одна из причин, по которой компиляторы с языка С создают более компактный и быстрый код по сравнению с компиляторами с других языков.

Смешанные конвенции
Существует конвенция передачи параметров STDCALL , отличающаяся и от C , и от PASCAL -конвенций, которая применяется для всех системных функций Win32 API. Здесь параметры помещаются в стек в обратном порядке, как в С, но процедуры должны очищать стек сами, как в PASCAL.
Еще одно отличие от С-конвенции – это быстрое или регистровое соглашение FASTCALL . В этом случае параметры в функции также передаются по возможности через регистры. Например, при вызове функции с шестью параметрами

первые три параметра передаются соответственно в ЕАХ , EDX , ЕСХ , а только начиная с четвертого, параметры помещают в стек в обычном обратном порядке:

В случае если стек был задействован, освобождение его возлагается на вызываемую процедуру.
В случае быстрого вызова транслятор Си добавляет к имени значок @ спереди, что искажает имена при обращении к ним в ассемблерном модуле.

Возврат результата из процедуры

Чтобы возвратить результат в программу на С из процедуры на ассемблере, перед возвратом управления в вызываемой процедуре (на языке ассемблера) необходимо поместить результат в соответствующий регистр:

Тип возвращаемого значенияРегистр
unsigned charal
charal
unsigned shortax
shortax
unsigned inteax
inteax
unsigned long intedx:eax
long intedx:eax

Пример Умножить на 2 первый элемент массива (нумерация элементов ведется с 0).

Чтобы построить проект в Microsoft Visual Studio Express 2010, совместив в нем файлы, написанные на разных языках программирования, выполняем следующие действия.

Создание проекта начинается с выбора меню Файл -> Создать -> Проект.

Аналогично проекту, содержащему 1 язык программирования, создаем пустой проект консольного приложения и задаем имя проекта.




Добавляем в дерево проекта два файла исходного кода:

  • вызывающая процедура на языке C++;
  • вызываемая процедура на языке ассемблера.

Для этого выбираем по правой кнопке мыши Файлы исходного кода -> Добавить -> Создать элемент и задаем имя файла программы на языке С++.

Второй добавляемый файл исходного кода будет иметь расширение .asm, которое необходимо указать явно.

Важно, чтобы файлы программ на C++ и ассемблере имели не только разные расширения, но и имена. В случае совпадающих имен файлов возникнет ошибка при компоновке проекта, поскольку оба файла будут иметь одно и то же имя объектного файла.

Набираем код программы для файлов вызывающей и вызываемой процедур соответственно на C++ и ассемблере.


Подключаем инструмент Microsoft Macro Assembler. По правой кнопке мыши для проекта выбираем Настройки построения.

В появившемся окне ставим галочку в строке masm.


Выбираем меню Свойства для файла на языке ассемблера по правой кнопке мыши и выбираем для этого файла инструмент Microsoft Macro Assembler.


Выполняем построение проекта, выбрав меню Отладка -> Построить решение.


Результат построения отображается в нижней части окна проекта.


Запуск проекта на выполнение осуществляется через меню Отладка -> Начать отладку.

Результат выполнения программы

Перед вызовом процедуры всегда нужно сохранять содержимое регистров ebp , esp , а перед выходом из процедуры – восстанавливать содержимое этих регистров. Это делается компилятором языка Си. Остальные регистры нужно сохранять при необходимости (если содержимое регистра подвергается изменению в вызванной процедуре, а далее может использоваться в вызывающей программе) Это может быть сделано с помощью команды pusha .
Передача аргументов в процедуру на ассемблере из программы на Си осуществляется через стек. При этом вызывающая программа записывает передаваемые параметры в стек, а вызываемая программа извлекает их из стека.

Работа с аргументами вещественного типа

При вызове функции с аргументами вещественного типа конфигурация проекта ничем не отличается от описанной выше. Для передачи аргументов необходимо указать их тип.

тип СиКоличество байтТип аргумента ассемблера
float4dword
double8qword

Возвращаемое вещественное значение по умолчанию располагается в вершине стека сопроцессора st(0).

Assembler или C++

Подскажите, завязался тут такой «спор».

В блоге, программист из Латвии, который пишет свою ОС, привёл два примера работы на C/C++ и Assembler:

Called from assembly:

Но некоторые программисты пишут, что нужно на assembler.

Так как быть и на чём начать писать и в какой стороне двигаться — С++ или Assembler, для ядра, хотя бы.

Assembler
09.06.2013, 22:05

Что быстрее assembler или c++
Вопрос от новичка. Что будет быстрее по скорости выполнения и на сколько: 1) сложить a+b на C++.

Assembler & Delphi (или С)
Такое задание. Запускаю програмку на языке высокого уровня(Delphi или С), ввожу в ней строку.

Ошибка в Assembler или, возможно, DOS/
Писал программу на Assembler, для заполнения матрицы по спирали. Exe файл работает правильно, а с.

09.06.2013, 23:162

Это смотря на каком уровне вы владеете этими языками. Ядро бы я лично писал бы на асме.

Добавлено через 29 секунд
а модули, на чистом С. Без ++)

10.06.2013, 00:083

зачем изобретать велосипед?

10.06.2013, 00:114
10.06.2013, 00:195
10.06.2013, 08:456

Примеры демонстрируют совершенно разные вещи — пример на Си показывает функцию, а на асме — вызов этой функции. В связи с этим вопрос — в чем собственно вопрос?

Добавлено через 1 минуту

Если имеется ввиду ядро ОС, то тот же линух на Си написан. Там есть ассемблер, но его ничтожно мало по сравнению с объемом Си кода.

Добавлено через 2 минуты

Assembler

поэтому утверждение, что на ассемблере лучше довольно спорно.

Добавлено через 12 минут
Вот проверил в MinGW. Из такого кода

Assembler
Assembler
Assembler
10.06.2013, 11:247

Решение

* Ассемблер жестко привязан к платформе.
Написав программу под одну платформу, вы делаете ее почти непортируемой на другие.
Даже между «родственными» платформами, такими как, например, IA-32 и AMD64, существует
много принципиальных различий — разные размеры указателей, разные наборы регистров,
разные соглашения о передаче параметров и т.д. Это значит, что для поддержки 32-битной и
64-битной версий программы придется иметь две кодовые базы.

С++ эта проблема тоже затрагивает, но не в такой степени, и многие программы, написанные
на C++, могут быть успешно портированы на другие платформы простой перекомпиляцией кода.

* Ассемблер практически не развивается как отдельный язык и лишен библиотечной поддержки.
Сталкиваясь с некоторыми, пусть даже и типовыми задачами, вам с большой вероятностью
придется писать свое решение с нуля, а это может оказаться очень и очень затратным.

Для С++, напротив, имеется огромное количество библиотек на все случаи жизни,
используя которые, вы экономите значительное количество времени и сил.

* Ассемблер, по своей натуре, имеет очень слабую поддержку языка в плане обеспечения
корректности и безопасности кода. Фактически, все что есть — это макросы, да и
то не везде. Все остальное необходимо будет изобретать самому.

С++, в противовес, имеет встроенные языковые средства, с помощью которых можно
контролировать надежность кода и обеспечивать различные гарантии.

* Вопреки распостраненному мнению, использование ассемблера в 99% не сделает вашу
программу быстрее. Современные компиляторы достаточно умны и умеют оптимизировать
код значительно лучше человека, не говоря уже о том, что делают они это намного
быстрее и точнее. Некоторые компиляторы, такие как Intel C++ Compiler, умеют
оптимизировать код под конкретную модель процессора, существует также двухпроходная
оптимизация (Profile-Guided Optimization), рассчитанная на сбор информации о
конкретных сценариях использования программы и улучшения по максимуму критических
участков кода, а еще масса различных инструментов профилирования и т.п., доступных
только для C, C++ и других языков высокого уровня.

Все это говорит отнюдь не в пользу ассемблера.
И многим программистам, деятельность которых сводится к сборке программ из готовых
библиотечных компонентов, от знания ассемблера ни жарко, ни холодно.

С другой стороны, в некоторых прикладных областях знание ассемблера не просто прихоть, а
жизненно важная необходимость, я могу сходу назвать, как минимум, три такие области:
системное программирование, обработка цифровых сигналов, встраиваемые системы.

Также существует мнение, что школу ассемблера, или другого низкоуровневого языка, в
любом случае нужно пройти. Человек, который это сделал, лучше понимает происходящее
«за кадром», да и вообще ему потом «сам черт не страшен». Я с этим полностью согласен.

На чем лучше программировать микроконтроллеры?. Ассемблер или Си или .

#1 VIGOR

Думаю, не ошибусь, если скажу, что многим было бы интересно узнать мнения своих коллег по программированию микроконтроллеров использующих тот или иной язык.
Существует много разных и противоречивых мнений по этому поводу.
Например, на Си, программа пишется в несколько раз быстрее и проще, чем на Асме. Знаю, что на Ассемблере, я могу просчитать каждый шаг контроллера по микросекундам, а как на Си, например? Слышал, что на Си, HEX, при той же задаче, получается в несколько раз больше, чем на Асме, а значит и работать будет медленней? И т. д.
А что делать, если в микроконтроллере всего 128 ячеек ОЗУ, — которые я с трудом распределяю для какой-либо задачи на Ассемблере, как в этом случае поведет себя Си?
Есть и еще среда, где программа вводится в виде алгоритма с древовидными ветвлениями и отображается на плоскости, в двух измерениях. – Как насчет ее?
Лично я, программы для контроллеров пишу на ассемблере, т. к. они должны быть шустрыми, да и другое я не пробовал, но, хотелось бы знать мнения других, может, стоит остановиться в целях повышения квалификации и подучить другие языки программирования?
Мое впечатление такое, что программы, типа каких-то драйверов на контроллерах, следует писать все же на Ассемблере, а простые (не особо скоростные) можно и на языках более высокого уровня.
Сейчас, пытаюсь связать свои девайсы с компьютером. Вот тут уже для меня совсем другое дело, — зачем я буду думать о том, когда и в какой регистр процессора и что прописывается, чтоб на мониторе всплыла какая-то буква? Естественно, пользуюсь (ну, пытаюсь пользоваться ) уже языком более высокого уровня — С++. Конечно, быстро (когда все знаешь), удобно, и памяти не мерянно (для простых программ) и скорости вроде хватает.
Не прошу споров, но прошу Ваших мнений (с примерами желательно ).

#2 DOCK

Я при знакомстве к микроконтроллерами выбрал для себя ассемблер. Вернее мне его порекомендовали более опытные коллеги, мотивируя это тем, что в этои случае мне будет понятнее «железо» и HEX получится компактнее, а программа быстрее.
Думаю, что нужно владеть парой АСМ + С.

#3 Kern

VIGOR
Выбор языка программирования сильно зависит от самого контроллера.
Например писать программу на С для семейства PIC16xxx нецелесообрзано — получается очень громозкий код, и лекго выйти за пределы внутреннего стека (всего 8 уровней вложений, из них пользователю на С доступно только 5 или 6. )
А вот писать программу на С для PIC18ххх уже можно — в процессоре есть встренные средсва поддержки этого языка (в основном это работа со стеком)
А слова по поводу того что процессор на С будет не успевать обрабатывать сильно преувеличенны. Редко когда необходимо работать на процессоре на пределе его возможностей. К тому же критичную часть кода можно написать вставками на асме.
Нельзя забывать и про правило, что 95% выполняется 5% времени.

А по поводу нехватки ячеек памяти — 128 байт, скажем — это тоже для С не проблема — выделяйте на переменные ровно столько ячеек памяти, сколько нужно. — их количество будет одинаковым и под С и под АСМ

ИМХО удобнее работать в С на PIC18Fxxx.
Но в городе, к сожалению, достать что либо иное кроме PIC16Fxx достаточно сложно.

Если хочется создать большой, сложный проект, а не просто железку для связи чего-то с чем-то, то лучше писать на языке высокого уровня. иногда включае некоторые вставки в особо критичных местах.
Зацикливаться на одном ассемблере не нужно — код на ассемблере в достаточно больших и сложных проектах становится сложно управляем и сложно модифицируем, то бишь громозким.

#4 Гость_Sunrain_*

Моё мнение такое:
Выбор языка в первую очередь зависит от типа контроллера, если для него нормальный компилятор. Например для PIC10-17 — ассемблер (хотя для PIC16-17 есть компиляторы), а для PIC18 — Си.

Если контроллер больше 8ми бит и для него есть компилятор, то однозначно Си (зачем лишний геморой).

Плюсы и минус:
Насчёт скорости и компактности кода, это зависит от программиста, и на ассемблере можно код раздуть и тормазнутый написать и на Си можно написать что всё будет компактно и шустро.
Да и очень большие скорости очень редко нужны в реальных проектах, для чего например? для пантов? (Например скорость работы с дисплеем обычно ограничевается самим дисплеем, так же и с различными интерфейсами и переферийными устройствами).
Там где нужна большая скорость (например частые прерывания), то там возможно оптимизировать вставляя асемблеровские процедуры, хотя проще и лучше просто оптимизировать Си код (рассматривая какой ассемблер сделал компилятор).

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

Вообщем я не вижу ни какой необходимости писать на Ассемблере, только лишнии трудности. Ведь под PC уже даже и не думают писать на асме, потому что овчинка выделки не стоит

#5 Гость_Sunrain_*

#6 Гость_Sunrain_*

Сейчас, пытаюсь связать свои девайсы с компьютером. Вот тут уже для меня совсем другое дело, — зачем я буду думать о том, когда и в какой регистр процессора и что прописывается, чтоб на мониторе всплыла какая-то буква?

Оформляешь это всё это в отдельном файле, потом include заголовка этого файла (*.h) и всё, работаешь и больше не вспоминаешь об UART’е 😛
Это по простому, можно сделать навороченее, с буферами и прерываниями, если нужно, конечно.
Обычно с этого начинаю работу с новым контроллером (типо как поморгать светодиодом).

Сообщение отредактировал Sunrain: 11 Сентябрь 2006 — 21:24

#7 MIl

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

теперь если я работаю как минимум на 8 разных типов контроллеров я для них должен держать весь инструментарий?
как быть с отладкой он чип?

имхо — среда разработки — матлаб с эмуляторами ядер (проверить можно практически в реал тайм) + библиотека стандартных штучек + оптимизатор для сокращения стековых переходов.

ориентироваться на контроллеры смысла нет надо ориентироваться на задачи.

#8 Гость_Sunrain_*

как определить нормальный компилятор или нет?

и если выяснится что компиляторов нормальных для этих прцессоров нет?

ориентироваться на контроллеры смысла нет надо ориентироваться на задачи.

Если не секрет, что за контроллеры?

Интересно почему вообще существуют компиляторы? и стоят больших денег (например IAR для ARM’ов стоит почти 5000$ )

P.S. А вообще всё имхо, у меня мало опыта и знаний, чтобы однозначно ответить. (но нужно стремится к будущему, прогресивному, а будущее за языками высокого уровня, в частности Си ).

Сообщение отредактировал Sunrain: 11 Сентябрь 2006 — 21:26

#9 MIl

не понял про Матлаб, не работал с ним, на сколько я знаю это среда для решения математических задач

и стоят больших денег (например IAR для ARM’ов стоит почти 5000$ )

#10 Гость_Sunrain_*

это средство инженерного проектирования — по результатам работы моделей генерируется как си так и асм код для DSP и IPCores (генератор встроен в инженерную версию).

IPCores программы вообще лучше писать на Javа J2EE

#11 MIl

а в качестве языка используется какой нить скриптовый язык?

#12 MIl

#13 Гость_Sunrain_*

3.1 What design language do you use?
There is no preferred language and each designer uses their language of choice. Keep in mind that a core written in a seldom used language will not be very useful. Most designers use either VHDL or Verilog.

adam/uip/
вообще проект по созданию TCP/IP стэка (веб сервера) на 8битном контроллере. Кстати, этот проект написан на Си

uIP is open source software written in the C programming language and the documentation and source code is free

Спасибо, всегда интересно узнать чтото новое.

Сообщение отредактировал Sunrain: 11 Сентябрь 2006 — 23:21

#14 MIl

Sunrain
коресы можно описывать и на с тоже не только верилоговские

но компиляторы на m-files на асм работают лучше чем на СИ

в принципе наверно всеж дело в привычке..

#15 Kern

MIl
Вы утверждаете, что лучше всё писать на ассемблере (с макросами и др наворотами). Мне кажется, что Вы не правы: большие проекты лучше писать на языках более высокого уровня (Java, C и т.п.).
Но мне кажется, что делая большой проект на асме есть определенные минусы:
1) Сам проект при прочих равных условиях больше (громозче). То есть поддерживать его сложнее.
2) Используется только человеческая оптимизация кода. Нет автоматической оптимизации как в компиляторах С. Часто бывает что компилятор С раскручивает сложный цикл лучше чем человек на асме его оптимизирует.
3) Нет проверки ошибок на этапе «компиляции». В асме работа идет только с числами и нет практически никаких проверок. В С есть разнообразные типы данных, в том числе и составные. В нормально составленной программе контроль типов данных позволяет избежть изрядного количества ошибок.
4) Не спорю, на асме можно написать всё, но вот какой ценой? Иначе бы не придумали бы языки высокого уровня, всякие ООП и т.п. Сколько времени уйдет на разработку сложно-функциональной системы на асме и на С?
5) Команды на асме менее читаемы чем на С. В С больше винмания уделяется алгоритму а не реализации алгоритма как в асме.
6) Почти полное отсутствие переносимости на другие процессоры. Если в пределах семейства переносимость еще осуществима, то переход на процессор от другой фирмы невозможен без переписи бОльшей части кода. На С переписывается только часть работы с железом (часто менее 1% от всего кода), при чем в заранее известных файлах. Часто эта работа уже проделанна производителем в виде стандартных библиотек. Я говорю именно про перенос проекта на другую платформу, когда есть исходники. Не следует здесь путать понятия с Java — переносом, когда переносится уже откомпилированный байт-код. Например подменяя некоторые файлы работы с железом я легко могу сэмулировать (формально даже без знания архитектуры проца) поведение сложной программы на простом компьютере, воспользовавшись либо C++Builder либо Visual Studio. На асме мне бы пришлось искать настоящий эмулятор процессора, такие не всегда бывают. А программируя на С я могу отладить программу в обычной, привычной среде разработки, и прогнать огромное число _логических_ тестов даже не включая процессор. Это очень ускоряет разработку.

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

сам писал как на С так и на асме для 8, 16 и 32 битных процессоров.

Сейчас обычно делаю так — пишу все на С, потом самые критически важные по времени куски кода проверяю по листингу в какие асемблеровские конструкции они преобразуются, корректирую в соответствии с этим С код, чтобы преобразование в особо важных местах было таким, каким мне нужно и больше не парюсь

Из наблюдений — обычно все С-шные команды транслируются в те же машинные конструкции, ктороые применил бы человек для реализации того же действия, уже для 16-битных процессоров в большинстве случаев 1 команда на С равна одной команде на асме.
Про С для PIC16Fxx молчу — процессор не приспособлен для языка Си, хотя если задача не критична по времени и есть свободные ресурсы — то можно писать и на С .

Вывод: По возможности лучше использовать язык С. А асм просто знать и иногда проверять компилятор на критических участках

Почему Ассемблер лучше

Assembler — это произведение искусства. Ниже ассемблера только машинные коды. Ассемблер создан как замена двоичному коду, который понимает процессор. При написании программы на ассемблере вы просто пишете команды процессора, которые процессор последовательно выполняет. Пример команды:

В машинных кодах это будет 8BC3 (шестнадцатеричный код, теперь всё будет шестнадцатеричным, ПРИВЫКАЙТЕ). Процессор смотрит на эти циферки и делает то, что они обозначают. Любая программа, написанная на языке высокого уровня (исключая .NET), преобразовывается в ассемблерный код. А почему же ассемблер лучше, чем С++ и др.. Дело в том, что программу, написанную на языке высокого уровня надо перевести на ассемблер, а это очень трудно, потом надо его оптимизировать, современные компиляторы очень плохо с этим справляются. Я провел эксперимент, написал программу (обычное окно с одной кнопкой в центре, которая закрывает его) на разных языках высокого уровня и после компиляции получил вот такие размеры этой самой программы:

C++ Builder 4 — 22 kb
Delphi 5 — 291 kb
Delphi 5 + библиотека KOL — 26 kb
Ассемблер MASM — около 3 kb

Так, что смотрите и делайте выводы, что лучше использовать.
Есть другое различие с некоторыми языками высокого уровня, это использование runtime DLL библиотек для их функций. Visual Basic даже не преобразовывает свой язык в ассемблер (хотя версия 5 и выше делают это частично, но не полностью), это сильно зависит от msvbvm50.dll, виртуальной машины Visual Basic. Exe файл, который создан VB, состоит из простых частей кода и многих вызовов этой DLL. Вот почему VB очень медленный. Ассемблер это и есть самый быстрый язык. Он использует только системные DLL: kernel32.dll, user32.dll, и т.д.
Теперь приступим к тому, где именно мы будем писать наши программы на ассмеблере. Компиляция состоит из 2 стадий:

  1. Проверка синтаксиса, создание объектного файла и файла листинга
  2. Линковка, т.е. компоновка.

Вы, наверное, все привыкли к тому, что запускаете Microsoft Visual C++, пишете программу, нажимаете на F7 и всё готово. На ассемблере вам придётся всё делать всё вручную. У ассемблера нет такой среды разработки. Вам придётся писать программу в блокноте, сохранять его в *.asm файл. И из командной строки вызывать ассемблер и линковщик. Потом я вам всё объясню.

Теперь смотрим инструменты.

Связки ассемблер-линковщик:
MASM32 v9.0 (ml.exe, link.exe)
TASM32 v5.0 (tasm32.exe, tlink32.exe)
Также можно FASM, но он только для спецов, примечателен тем, что у него есть своя оболочка не надо никаких объектных файлов т.д., нажимаешь F9 и всё готово.

Текстовые редакторы
EmEditor Professional Version 4.13 (вне конкуренции)
UltraEdit v*.*.*.* (тоже хороший не я им не пользуюсь)

Блокнот : (классика).
Также пригодится справочник по API функциям. Желательно из комплекта MS SDK. Полная версия весит 24 MB (почти все апи), есть урезанные версии весом 12 МВ. Русские версии весом

Читать еще:  Язык си работа с файлами
Ссылка на основную публикацию
Adblock
detector