Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.144.248.24] |
|
Страницы: (3) 1 [2] 3 все ( Перейти к последнему сообщению ) |
Сообщ.
#16
,
|
|
|
Цитата Mokar @ я хочу скачать компилятор для того чтобы запускать через программу Scite, не знаю каккой мне нужен. может посоветуете кто работал в Scite? Дожили, компилятор к редактору прикручиваем... Наиболее удобный для меня - FASM, но и MASM тоже для меня на первом месте - больше распространен все-таки. Но фасм - круче! |
Сообщ.
#17
,
|
|
|
почему мне нравится FASM?
1. Ему не нужны LIB файлы для статического импорта функций. 2. Чистый и удобный синтаксис, максимальный набор поддерживаемый команд. Отсутствие дирректив-рудиментов аля .386, .486, .386p и т.д. (они есть но уже идут как макросы) и так далее и тому подобное 3. Полный контроль над размещением данных в файле 4. Мощный макроссный движок, ничем не уступающий движку MASM, а в некоторых случаях его превосходящий. 5. При компиляции не создаются *.obj и другие файлы, которые постоянно замусоривают папку с исходником 6. Почти все параметры программы задаются в самом исходнике и не надо колдовать с параметрами командной строки. |
Сообщ.
#18
,
|
|
|
Цитата Ahilles @ почему мне нравится FASM? 1. Ему не нужны LIB файлы для статического импорта функций. 2. Чистый и удобный синтаксис, максимальный набор поддерживаемый команд. Отсутствие дирректив-рудиментов аля .386, .486, .386p и т.д. (они есть но уже идут как макросы) и так далее и тому подобное 3. Полный контроль над размещением данных в файле 4. Мощный макроссный движок, ничем не уступающий движку MASM, а в некоторых случаях его превосходящий. 5. При компиляции не создаются *.obj и другие файлы, которые постоянно замусоривают папку с исходником 6. Почти все параметры программы задаются в самом исходнике и не надо колдовать с параметрами командной строки. Согласен! я тоже использую FASM уже месяц для написания ОСьки: жалоб - 0, лишних вопросов - 0, неудобства компиляция-линкирование - 0. Вывод: |
Сообщ.
#19
,
|
|
|
Цитата Alex_I @ Ну тогда я задам лишних вопросов - 0, 1. Для примера возьмем ДОС (хотя можно и под винду, но не важно). Нужно сделать небольшую игрушку, допустим 3D. Я возьму файл DDWARE.LIB, из пакета 3D-WARE и без напрягов использую не только 3D-движок, но и мышку, звук и прочие фичи этой игродельческой либы (написанной на чистом Cи). А как поступишь ты? Будешь все с нуля писать? 2. Чем макросы лучше директив? 3. А какой ассемблер не дает полного контроля? 4. А можно подробнее узнать, как ты пользуешься мощью макродвижка фасма? Теория не интересует, мне интересна именно практическая сторона 5. Есть сорс на ассемблере. Нужно его подключить к проекту на Watcom C++. Ваши действия? 6. А в других компиляторах не так? Дополнение к первому вопросу, более актуальное. Есть такой пакет LIBJPG. Мультиплатформенный. На нем построено множество вьюнеров граф. файлов, в частности ACDSee. Я вот в досе его подключил к тасму (под 32-х битный защищенный режим) с пол-пинка. Твои действия на фасме? |
Сообщ.
#20
,
|
|
|
Стоп!Стоп!Стоп!
Я не думал, что столько вопросов появится Для мультимедийных целей, возможно, ФАСМ и никудышний компилятор, но для системного программирования достаточно прост и удобен. Вот представьте себе такую картину: на экране четыре окна - самодельная программа для записи boot сектора, блокнот с кодом асм-ской программы, командная строка ДОС для запуска компилятора и виртуалка. Мои действия: 1- редактирую код, 2- компилирую, 3- записываю на дискету, 4- проверяю. Процесс не слишком долгий, но когда допустил одну какую ерундовую ошибку и при проверке виртуал комп зависает начинаешь уже методом тыка проверять чуть ли не каждую строку. И в отличии от ТАСМА то, что я в ФАСМЕ одной командной строкой могу скомпилировать код немного, да ускоряет и упрощает работу. А насчёт мультимедиа приложений, игр и пр. (именно средствами и на платформе Винды) я недалёк... И мало знаю о том какая ДЛЛ-ка для чего служит, я стараюсь своими силами достигать каких-либо результатов - во 1ых набираюсь опыта, и во 2ых своё-есть своё (просто и понятно), а когда используешь чужие библиотеки, движки обязательно в чем нибудь будешь расхлёбывать за чужие ошибки... Выше сказанное-имхо... |
Сообщ.
#21
,
|
|
|
Цитата Alex_I @ Я не тороплю, подумай прежде чем ответить Я не думал, что столько вопросов появится Цитата Alex_I @ Мсье никогда не слышал о средствах повышающих удобство работы? Ну тогда для начала держи парочку.И в отличии от ТАСМА то, что я в ФАСМЕ одной командной строкой могу скомпилировать код немного, да ускоряет и упрощает работу. 1) bat-файлы. Хороши для простеньких проектов с небольшим количеством файлов. Позволяют по ходу их выполнения менять логику компиляции (редко, но использую). Универсальны. Просты в создании. 2) makefile. Самая мощная фича, созданная именно для экономии времени компиляции. Одним вызовом make.exe перекомпилирует весь проект. Но, главное достоинство в том, что перекомпилируется только то, во что вносились изменения с момента последней компиляции. Т.е. существенно экономит время (в этом и преимущества obj-файлов - что было скомпилировано один раз, то больше не нужно заново перекомпилировать). 3) В любой оболочке (VC, NC, DN, FM) есть пользовательское меню, где можно задать последовательность команд и вызывать ее с помощью горячих клавиш. Это вообще самый быстрый вариант, поскольку в командной строке вообще ничего не нужно писать - навел курсор на файл, нажал кнопочку и получил результат. Огромный плюс еще и в том, что в том же FM встроенный редактор, с настраиваемой подсветкой синтаксиса (для всех языков). Поэтому все действия выполняются не выходя из редактора. Цитата Alex_I @ Во первых, мультимедиа здесь не причем. Возьмем другой пример. Математические операции по обработке сигналов датчиков. Допустим нужно провести очень много вычислений. На асме такого нет. Зато есть на фортране. Твои действия? А во вторых, не нужно путать DLL и LIB-файлы, это совершенно разные вещи А насчёт мультимедиа приложений, игр и пр. (именно средствами и на платформе Винды) я недалёк... И мало знаю о том какая ДЛЛ-ка для чего служит, я стараюсь своими силами достигать каких-либо результатов Ну так как, ответ на все эти шесть вопросов получим? Можешь даже за помощью профи сбегать, на форум фанов фасма Добавлено Цитата Alex_I @ Это ты просто еще не брался за действительно сложные задачи Попробуй-ка самостоятельно закодить вьюнер jpg-файлов, не пользуясь сторонними либами Уверяю тебя, быстро надоест и начнеш искать чью-нибудь либу, пускай и рискуя нарваться на чужие ошибки. а когда используешь чужие библиотеки, движки обязательно в чем нибудь будешь расхлёбывать за чужие ошибки... |
Сообщ.
#22
,
|
|
|
Цитата AndNot @ Это ты просто еще не брался за действительно сложные задачи. Попробуй-ка самостоятельно закодить вьюнер jpg-файлов, не пользуясь сторонними либами какой дурак будет писать такой сложный проект на ассемблере? (всякие психи-одиночки-энтузиасты не в счёт) на ассемблере пишут участки кода критически важные ко времени выполнения или размеру, да и то не всегда, т.е. по сути ассемблерные вставки. единственный более-менее пригодный к жизни вариант использования ассемблера, в котором модуль будет полностью на асме, это написание драйвера режима ядра или DLL, от которых требуется высокая скорость и минимальный размер. И вот тут я выберу именно FASM. Добавлено Цитата AndNot @ 3. А какой ассемблер не дает полного контроля? в FASM можно создать любое количество секций в PE-файле, можно указать их имена и любые атрибуты Добавлено Цитата AndNot @ 2. Чем макросы лучше директив? в FASM они сделаны в виде макросов и получается что некоторые программы написанные для MASM можно скомпилить на FASM. а так мне макросы типа .386 в FASM вообще не нужны Добавлено Цитата AndNot @ 4. А можно подробнее узнать, как ты пользуешься мощью макродвижка фасма? Теория не интересует, мне интересна именно практическая сторона я бы не сказал что пишу много макросов на FASM, просто набор макросов поставляемых вместе с FASM намного шире и удобнее чем в MASM. Например, для макроса invoke в MASM нужны эти дебильные прототипы. Вопрос: почему нельзя преобразовать одну строку вызова функции в несколько команд push и одну call без прототипов? зачем нужны лишние проверки типов, если в 99,99% API функций принимают в качестве параметров DWORD или указатель, что в ассемблере одно и тоже Добавлено Цитата AndNot @ 1. Для примера возьмем ДОС (хотя можно и под винду, но не важно). Нужно сделать небольшую игрушку, допустим 3D. Я возьму файл DDWARE.LIB, из пакета 3D-WARE и без напрягов использую не только 3D-движок, но и мышку, звук и прочие фичи этой игродельческой либы (написанной на чистом Cи). А как поступишь ты? Будешь все с нуля писать? я извиняюсь конечно, если кого-то обижу. я не псих чтобы писать такую прогу на ассемблере .Если при написании какого-либо проекта на языке высокого уровня мне действительно пригодится ассемблер то воспользуюсь ассемблерными вставками, а если они меня не устроят, то напишу DLL с критическими функциями на асме и в проге заюзаю эту DLL. |
Сообщ.
#23
,
|
|
|
Ahilles, ты понимаешь, что своим постом обижаешь уйму народу?
Цитата Ahilles @ какой дурак будет писать такой сложный проект на ассемблере? (всякие психи-одиночки-энтузиасты не в счёт) Цитата Ahilles @ Я знал человека, который на асме писал с моей скоростью на 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 // Сигнализация 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. Посмотри ещё в сторону эзотерического программирования. Получается, эти люди ещё опаснее психов, по-твоему? |
Сообщ.
#24
,
|
|
|
Я не отрицаю многие драйвера для Win3xx и Win9x писались на ассемблере. Но Win3xx и Win9x это прошлый век и с этим не поспоришь. Я сказал что есть более-менее пригодные к жизни варианты использования ассемблера в современных условиях, это написание драйвера режима ядра или DLL. И вопрос был какой ассемблер лучше при таких вариантах использования.
Цитата Qraizer @ Подредактируй, пост, плз. Если ты не используешь макросы и поэтому не пишешь больших проектов на ассемблере, это не значит, что те, кто этим занимаются, заслуживают унижения. я говорю что в современных условиях писать большие проекты полностью на асме это мазохизм! согласись это так! Разговор вроде был про ассемблеры FASM и MASM, поэтому не будем отступать от темы. В начале я юзал MASM, но потом я перешёл на FASM, по однйо простой причине : надо было написать несколько взаимосвязанных DLL файлов, в MASM надо скомпилить DLL'ку, притом чтобы задать имена экспортируемых функций надо создать def-файл. После компиляции сделать LIB-файл и только после этого становится возможным скомпилить следующую DLL. в FASM всё элементарно: есть макросы library и import для создания таблицы импорта, т.е. я могу скомпилить файл без наличия DLL из которой импортируются функции, нет гемора с LIB файлами. Есть маркос export для создания таблицы экспорта, не нужен DEF-файл. В результате у нас только файл исходника, в котором есть всё для компиляции. |
Сообщ.
#25
,
|
|
|
Куски VxD тут приведены не более чем для примера грамотного использования макросов. Используя подобную соответствующую задаче библиотеку, можно писать очень быстро и безошибочно. DDKшная вот ориентирована на Win9x raw kernel API. Несложно представить себе библиотеку для Win32 API, или ввода/вывода, или ещё чего. Да хоть STLных контейнеров. Так что "современные большие проекты" не только мазохисты могут писать. Достаточно любить ассемблер.
Мне рассказывали об игромане, который в стратегии реального времени играл джойстиком зачастую не хуже, чем его оппоненты мышкой+клавой. Мазохист? |
Сообщ.
#26
,
|
|
|
ладно. не буду дальше холиварить
|
Сообщ.
#27
,
|
|
|
Народ,всем привет ,а как установить этот MASM подскажите ?
|
Сообщ.
#28
,
|
|
|
Наверху раздела есть прибитая тема. Вон та ссылка подойдёт?
|
Сообщ.
#29
,
|
|
|
а я пишу свой собственный ассемблер.
теперь он стал уже многопроходным. Прикреплённый файлАссемблер.RAR (22,23 Кбайт, скачиваний: 300) |
Сообщ.
#30
,
|
|
|
Если бы у Nasm было IDE, наверное он был бы как Fasm.
Думаю, что это очень важно когда проект современен, развивется и имеет поддержку. Это само собой побуждает людей вносить свои вклады в развитие кампилятора. Наверное, кроме nasm/fasm/yasm всё на сегоднешний день заброшенно. Нарпример, я видел на форуме fasm кто-то придумал движёк прикрутить регулярные выражения к fasm. Да и ошибки исправляются, и поддержка x64 налаживается. Одно плохо, программирование это трудно всётаки |