Компиляторы

Цитата Mokar @ 23.04.09, 12:27

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

Дожили, компилятор к редактору прикручиваем...

Наиболее удобный для меня - FASM, но и MASM тоже для меня на первом месте - больше распространен все-таки. Но фасм - круче!

почему мне нравится FASM?
1. Ему не нужны LIB файлы для статического импорта функций.
2. Чистый и удобный синтаксис, максимальный набор поддерживаемый команд. Отсутствие дирректив-рудиментов аля .386, .486, .386p и т.д. (они есть но уже идут как макросы) и так далее и тому подобное
3. Полный контроль над размещением данных в файле
4. Мощный макроссный движок, ничем не уступающий движку MASM, а в некоторых случаях его превосходящий.
5. При компиляции не создаются *.obj и другие файлы, которые постоянно замусоривают папку с исходником
6. Почти все параметры программы задаются в самом исходнике и не надо колдовать с параметрами командной строки.

Сообщение отредактировано: Ahilles - 30.06.09, 05:29

Цитата Ahilles @ 30.04.09, 04:29

почему мне нравится FASM?
1. Ему не нужны LIB файлы для статического импорта функций.
2. Чистый и удобный синтаксис, максимальный набор поддерживаемый команд. Отсутствие дирректив-рудиментов аля .386, .486, .386p и т.д. (они есть но уже идут как макросы) и так далее и тому подобное
3. Полный контроль над размещением данных в файле
4. Мощный макроссный движок, ничем не уступающий движку MASM, а в некоторых случаях его превосходящий.
5. При компиляции не создаются *.obj и другие файлы, которые постоянно замусоривают папку с исходником
6. Почти все параметры программы задаются в самом исходнике и не надо колдовать с параметрами командной строки.

Согласен! я тоже использую FASM уже месяц для написания ОСьки:
жалоб - 0,
лишних вопросов - 0,
неудобства компиляция-линкирование - 0.
Вывод:

Цитата Alex_I @ 11.01.10, 20:47

лишних вопросов - 0,

Ну тогда я задам
1. Для примера возьмем ДОС (хотя можно и под винду, но не важно). Нужно сделать небольшую игрушку, допустим 3D. Я возьму файл DDWARE.LIB, из пакета 3D-WARE и без напрягов использую не только 3D-движок, но и мышку, звук и прочие фичи этой игродельческой либы (написанной на чистом Cи). А как поступишь ты? Будешь все с нуля писать?
2. Чем макросы лучше директив?
3. А какой ассемблер не дает полного контроля?
4. А можно подробнее узнать, как ты пользуешься мощью макродвижка фасма? Теория не интересует, мне интересна именно практическая сторона
5. Есть сорс на ассемблере. Нужно его подключить к проекту на Watcom C++. Ваши действия?
6. А в других компиляторах не так?

Дополнение к первому вопросу, более актуальное. Есть такой пакет LIBJPG. Мультиплатформенный. На нем построено множество вьюнеров граф. файлов, в частности ACDSee. Я вот в досе его подключил к тасму (под 32-х битный защищенный режим) с пол-пинка. Твои действия на фасме?

Сообщение отредактировано: AndNot - 11.01.10, 22:22

Стоп!Стоп!Стоп!
Я не думал, что столько вопросов появится

Для мультимедийных целей, возможно, ФАСМ и никудышний компилятор, но для системного программирования достаточно прост и удобен. Вот представьте себе такую картину: на экране четыре окна - самодельная программа для записи boot сектора, блокнот с кодом асм-ской программы, командная строка ДОС для запуска компилятора и виртуалка. Мои действия: 1- редактирую код, 2- компилирую, 3- записываю на дискету, 4- проверяю. Процесс не слишком долгий, но когда допустил одну какую ерундовую ошибку и при проверке виртуал комп зависает начинаешь уже методом тыка проверять чуть ли не каждую строку. И в отличии от ТАСМА то, что я в ФАСМЕ одной командной строкой могу скомпилировать код немного, да ускоряет и упрощает работу.

А насчёт мультимедиа приложений, игр и пр. (именно средствами и на платформе Винды) я недалёк... И мало знаю о том какая ДЛЛ-ка для чего служит, я стараюсь своими силами достигать каких-либо результатов - во 1ых набираюсь опыта, и во 2ых своё-есть своё (просто и понятно), а когда используешь чужие библиотеки, движки обязательно в чем нибудь будешь расхлёбывать за чужие ошибки...

Выше сказанное-имхо...

Цитата Alex_I @ 12.01.10, 17:49

Я не думал, что столько вопросов появится

Я не тороплю, подумай прежде чем ответить

Цитата Alex_I @ 12.01.10, 17:49

И в отличии от ТАСМА то, что я в ФАСМЕ одной командной строкой могу скомпилировать код немного, да ускоряет и упрощает работу.

Мсье никогда не слышал о средствах повышающих удобство работы? Ну тогда для начала держи парочку.
1) bat-файлы. Хороши для простеньких проектов с небольшим количеством файлов. Позволяют по ходу их выполнения менять логику компиляции (редко, но использую). Универсальны. Просты в создании.
2) makefile. Самая мощная фича, созданная именно для экономии времени компиляции. Одним вызовом make.exe перекомпилирует весь проект. Но, главное достоинство в том, что перекомпилируется только то, во что вносились изменения с момента последней компиляции. Т.е. существенно экономит время (в этом и преимущества obj-файлов - что было скомпилировано один раз, то больше не нужно заново перекомпилировать).
3) В любой оболочке (VC, NC, DN, FM) есть пользовательское меню, где можно задать последовательность команд и вызывать ее с помощью горячих клавиш. Это вообще самый быстрый вариант, поскольку в командной строке вообще ничего не нужно писать - навел курсор на файл, нажал кнопочку и получил результат. Огромный плюс еще и в том, что в том же FM встроенный редактор, с настраиваемой подсветкой синтаксиса (для всех языков). Поэтому все действия выполняются не выходя из редактора.

Цитата Alex_I @ 12.01.10, 17:49

А насчёт мультимедиа приложений, игр и пр. (именно средствами и на платформе Винды) я недалёк... И мало знаю о том какая ДЛЛ-ка для чего служит, я стараюсь своими силами достигать каких-либо результатов

Во первых, мультимедиа здесь не причем. Возьмем другой пример. Математические операции по обработке сигналов датчиков. Допустим нужно провести очень много вычислений. На асме такого нет. Зато есть на фортране. Твои действия? А во вторых, не нужно путать DLL и LIB-файлы, это совершенно разные вещи

Ну так как, ответ на все эти шесть вопросов получим? Можешь даже за помощью профи сбегать, на форум фанов фасма

Добавлено 12.01.10, 20:42

Цитата Alex_I @ 12.01.10, 17:49

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

Это ты просто еще не брался за действительно сложные задачи Попробуй-ка самостоятельно закодить вьюнер jpg-файлов, не пользуясь сторонними либами Уверяю тебя, быстро надоест и начнеш искать чью-нибудь либу, пускай и рискуя нарваться на чужие ошибки.

Цитата AndNot @ 12.01.10, 20:40

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

какой дурак будет писать такой сложный проект на ассемблере? (всякие психи-одиночки-энтузиасты не в счёт)
на ассемблере пишут участки кода критически важные ко времени выполнения или размеру, да и то не всегда, т.е. по сути ассемблерные вставки. единственный более-менее пригодный к жизни вариант использования ассемблера, в котором модуль будет полностью на асме, это написание драйвера режима ядра или DLL, от которых требуется высокая скорость и минимальный размер. И вот тут я выберу именно FASM.

Добавлено 07.02.10, 18:28

Цитата AndNot @ 11.01.10, 22:16

3. А какой ассемблер не дает полного контроля?

в FASM можно создать любое количество секций в PE-файле, можно указать их имена и любые атрибуты

Добавлено 07.02.10, 18:31

Цитата AndNot @ 11.01.10, 22:16

2. Чем макросы лучше директив?

в FASM они сделаны в виде макросов и получается что некоторые программы написанные для MASM можно скомпилить на FASM. а так мне макросы типа .386 в FASM вообще не нужны

Добавлено 07.02.10, 18:38

Цитата AndNot @ 11.01.10, 22:16

4. А можно подробнее узнать, как ты пользуешься мощью макродвижка фасма? Теория не интересует, мне интересна именно практическая сторона

я бы не сказал что пишу много макросов на FASM, просто набор макросов поставляемых вместе с FASM намного шире и удобнее чем в MASM. Например, для макроса invoke в MASM нужны эти дебильные прототипы. Вопрос: почему нельзя преобразовать одну строку вызова функции в несколько команд push и одну call без прототипов? зачем нужны лишние проверки типов, если в 99,99% API функций принимают в качестве параметров DWORD или указатель, что в ассемблере одно и тоже

Добавлено 07.02.10, 18:45

Цитата AndNot @ 11.01.10, 22:16

1. Для примера возьмем ДОС (хотя можно и под винду, но не важно). Нужно сделать небольшую игрушку, допустим 3D. Я возьму файл DDWARE.LIB, из пакета 3D-WARE и без напрягов использую не только 3D-движок, но и мышку, звук и прочие фичи этой игродельческой либы (написанной на чистом Cи). А как поступишь ты? Будешь все с нуля писать?

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

Сообщение отредактировано: Ahilles - 07.02.10, 18:49

Ahilles, ты понимаешь, что своим постом обижаешь уйму народу?

Цитата Ahilles @ 07.02.10, 18:25

какой дурак будет писать такой сложный проект на ассемблере? (всякие психи-одиночки-энтузиасты не в счёт)

Цитата Ahilles @ 07.02.10, 18:25

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

Я знал человека, который на асме писал с моей скоростью на C. Как раз за счёт наработанных макросов, не только своих, естественно. Его сырцы больше asm++ напоминали. Ты писал виртуальные драйверы для Win3xx и Win9x? Во времена VC5 и выше их уже можно было писать на С и даже местами С++. Так же на них неплохо пишутся WDM. Но до тех пор основным инструментом был ассемблер. Если посмотреть в DDK тех времён, VxD-драйверы тогда выглядели скорее как Сшные сырцы, ибо наборы макросов в DDK позволяли поднять "умность" компилятора на уровень ЯВУ. И зачастую макросы при компиляции отлавливали такие ошибки, как неверное использование стека, несогласованность вызова функции, "порчу" регистров итп. (Кстати, объявление сущности до её использования - это не только требование многих ЯВУ, это и просто признак хорошего тона и программиста-мастера, который думает о себе и коллегах. Так что наличие прототипов мною только приветствуется.) Но гораздо важнее были их способности к универсальности. Параметризация поведения по скорости или по количеству используемых им регистров, например. Всё это было очень важным, ибо ядерная отладка в те времена была вещью очень муторной.
В то время мне лично писать на асме было куда прикольней. Зацени, к примеру, этот фрагмент, который по IRQ от устройства вызывает каллбак в юзермоде (который Win16; если клиент Win32, там проще):

        EXTERN C signal16:near32        ;функция сигнализации в Win16-приложение
        EXTERN C mtxWin16:dword         ;мьютекс критической секции
 
; callback функция для сигнализации в Win16-приложение
; C-функция, публичная, кадр стека адресуется через ESP, блокирована в памяти
BeginProc LCODE_signal2win16, CCALL, PUBLIC, ESP, LOCKED
        LocalVar npxData, 108           ; контекс FPU
        EnterProc                       ; пролог
        SaveReg <edx, ebp>              ; сохранение регистров
        VMMCall _EnterMutex, <mtxWin16, BLOCK_THREAD_IDLE> ; захват мьютекса
        RestoreReg <ebp, edx>           ; восстановление регистров
        Push_Client_State               ; сохранить клиентские регистры
        fnsave [npxData]                ; сохранить контекст FPU
        cCall signal16, <EDX, EBP>      ; вызвать C-функцию (сырец ниже)
        frstor [npxData]                ; восстановить контекст FPU
        Pop_Client_State                ; восстановить клиентские регистры
        VMMCall _LeaveMutex, <mtxWin16> ; освободить мьютекс
        LeaveProc                       ; эпилог
        Return                          ; возврат
EndProc LCODE_signal2win16

и сравни с Сшной signal16():

// Сигнализация Win16-приложению
void signal16(PIR_LIST curNode, PCRS clientReg)
{
 // Указатель на структуру связи, подготовленную библиотеками
 PVOID synk= (PVOID )curNode->pOverlap.linAddr;
 // handle IRQ
 DWORD hIrq=*(PDWORD)((PBYTE)synk + 1 + sizeof(OVERLAPPED) + sizeof(DWORD)*6);
 // Адрес FAR-функции в Win16-приложении
 DWORD func=*(PDWORD)((PBYTE)synk + 1 + sizeof(OVERLAPPED) + sizeof(DWORD)*2);
 // Параметр для FAR-функции в Win16-приложении
 DWORD stat=*(PDWORD)curNode->outBuffer.linAddr;
 
 Begin_Nest_Exec();                     // Начать вложенное исполнение в VM
 Simulate_Push(stat>>16);               // Поместить в стек клиента 32-битный
 Simulate_Push((WORD)stat);             //  параметр для Win16-функции
 Simulate_Push(hIrq>>16);               // Поместить в стек клиента 32-битный
 Simulate_Push((WORD)hIrq);             //  handle IRQ
 VMMCall(Disable_VM_Ints);              // Запрет прерываний в VM
 // Установить для Win16-клиента его регистр DS
 clientReg->Client_DS=*(PWORD)((PBYTE)synk+1+sizeof(OVERLAPPED)+sizeof(DWORD)*3);
 // "Вызвать" на стеке Win16-функцию как FAR PASCAL
 Simulate_Far_Call((WORD)(func>>16), (WORD)func);
 // Возобновить исполнение в VM (с изменённым конекстом)
 Resume_Exec();
 // Функция клиента отработала
 End_Nest_Exec();                       // Закончить вложенное исполнение в VM
}

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

P.S. Посмотри ещё в сторону эзотерического программирования. Получается, эти люди ещё опаснее психов, по-твоему?

Я не отрицаю многие драйвера для Win3xx и Win9x писались на ассемблере. Но Win3xx и Win9x это прошлый век и с этим не поспоришь. Я сказал что есть более-менее пригодные к жизни варианты использования ассемблера в современных условиях, это написание драйвера режима ядра или DLL. И вопрос был какой ассемблер лучше при таких вариантах использования.

Цитата Qraizer @ 07.02.10, 23:02

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

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

Разговор вроде был про ассемблеры FASM и MASM, поэтому не будем отступать от темы. В начале я юзал MASM, но потом я перешёл на FASM, по однйо простой причине : надо было написать несколько взаимосвязанных DLL файлов, в MASM надо скомпилить DLL'ку, притом чтобы задать имена экспортируемых функций надо создать def-файл. После компиляции сделать LIB-файл и только после этого становится возможным скомпилить следующую DLL. в FASM всё элементарно: есть макросы library и import для создания таблицы импорта, т.е. я могу скомпилить файл без наличия DLL из которой импортируются функции, нет гемора с LIB файлами. Есть маркос export для создания таблицы экспорта, не нужен DEF-файл. В результате у нас только файл исходника, в котором есть всё для компиляции.

Куски VxD тут приведены не более чем для примера грамотного использования макросов. Используя подобную соответствующую задаче библиотеку, можно писать очень быстро и безошибочно. DDKшная вот ориентирована на Win9x raw kernel API. Несложно представить себе библиотеку для Win32 API, или ввода/вывода, или ещё чего. Да хоть STLных контейнеров. Так что "современные большие проекты" не только мазохисты могут писать. Достаточно любить ассемблер.
Мне рассказывали об игромане, который в стратегии реального времени играл джойстиком зачастую не хуже, чем его оппоненты мышкой+клавой. Мазохист?

ладно. не буду дальше холиварить

Народ,всем привет ,а как установить этот MASM подскажите ?

Наверху раздела есть прибитая тема. Вон та ссылка подойдёт?

а я пишу свой собственный ассемблер.
теперь он стал уже многопроходным.

Прикреплённый файлАссемблер.RAR (22,23 Кбайт, скачиваний: 299)

Сообщение отредактировано: Aleksandr__ - 24.07.10, 21:19

Если бы у Nasm было IDE, наверное он был бы как Fasm.
Думаю, что это очень важно когда проект современен, развивется и имеет поддержку.
Это само собой побуждает людей вносить свои вклады в развитие кампилятора.
Наверное, кроме nasm/fasm/yasm всё на сегоднешний день заброшенно.
Нарпример, я видел на форуме fasm кто-то придумал движёк прикрутить регулярные выражения к fasm.
Да и ошибки исправляются, и поддержка x64 налаживается.
Одно плохо, программирование это трудно всётаки