Давай сначала определимся что сделует считать "большими" проектами. 1) Большой проект пишется группой программистов. 2) Для больших проектов черезвычайно важна скорость разработки (желательно не в ущерб качеству) 3) Очень важна поддержка проекта, тоесть постоянные доделки, модификации и.т.д. 4) Часто важна переносимость кода на другие аппаратные платформы. Этии требованиям в комплексе лучше всего удовлетворяет си. А на ассемблере врядли можно писать большой проект целиком без ущерба для скорости или качества разработки. О переносимости на другие аппаратные платформы тут и говорить нечего, слишком тяжким трудом это дается.
Мужики, какие могут быть споры? в реально больших проектах (управление производством, аэропортом и т.п.) рулит только HLL. причем highest HLL вроде жабы и с#. потому как если список подзадач для решение настоящей проблемы будет включать проблемы ручной оптимизации кода (не алгоритма), банальной работы со строками, рациональными числами, то работа не будет выполнена в течение положенного срока, т.е. вообще не будет выполнена. у асма другие приложения. ну вы сами про это знаете
Можно, можно, все можно. Не спорю, для каких-то проектов и ВБ и Делфи и С будут рулить... А скорость и качество от языка очень слабо зависят, поверь. Единственный минус для ассемблера, что (относительно) мало уже готового кода и все, и то для ряда случаев это абсолютно неважно. Если тебе кто-то сказал о необыкновенной переносимости сишного кода - не верь, все что сложнее хелло ворд тоже требует нехилого напильника при переносе как правило. Кроме того меня лично кроссплатфоменность мало интересует
Имеется интересный проект. Когда закончу - выставлю на свой сайт. Там весь упор на скорость разработки и code reuse.
masquer Ага, вот все про кроссплатформенность кричат и радуются, что Цэ самый в этом плане рульный. Вот смотрю я на свой курсовик старый и думаю: "Ну и кто сможет скомпилить его под никсами, если 80% кода - вызовы WinAPI?" Можно, конечно, все вызовы апишек вынести в отдельное место и сделать для них обертки, чтобы можно было один раз в одном месте заменить апишки на вызов нужных функций и горя не знать, но это можно сделать и на асме Вышесказанное относится только к переносу на другую ось, для переноса на другую платформу (не x86) в асме средств, вроде как, нет. Правда, сомневаюсь, что это кому-то надо А по поводу скорости написания кода на том или ином языке и единственного фактора, на нее влияющего, я уже говорил не раз - это опыт. Нет опыта - и на ВБ будешь хеловорлд два дня писать. Только никто в это утверждение не верит, сейчас начнут с пеной у рта доказывать, что я не прав
masquer Теперь уже и я не удержусь. Вроде бы как Ms Rem не из wasm team, поэтому, если эмоционально, то я бы должен быть на твоей стороне, ан-нет, с логикой у тебя хреновее. Аргументы неубедительные. Ms Rem ввел 4 требования. Изначальные условия. С этими посылками я, как человек, имеющий некоторый опыт, согласен полностью. Далее ставится вопрос (твой же): Ну, давай, почему тебе кажется что писать большие проекты на ассемблере нецелесообразно? И что потом? Что это за перлы: 1. требует нехилого напильника при переносе как правило 2. меня лично кроссплатфоменность мало интересует Бррр... Ф топку masquer, ответь мне пожалуйста (только без этих перлов, типа "мало интересует" и все такое прочее) на ряд вопросов: 1. черезвычайно важна скорость разработки - я, положим, пишу программу POS. Нужен модуль - аналог Crystal Reports. Откуда его взять на ассемблере? Или, допустим, пишу программу-криптовалку. Нужен модуль эллиптики. Откуда взять? Нужен hash_map, откуда взять? Думаю, тенденцию ты понял. 2. Часто важна переносимость кода - пожалуйста, объясни, как мне средствами асма (только не надо петь о С - сейчас разговор совсем не о нем) перепортировать прогу из-под Win в Linux. Вызовы API - ф топку. Допустим, опять таки, требуется спортировать библу эллиптики. Положим, там нет ни одного вызова WinAPI. Твои действия?
Ну так, что же они не сделали свой собственный линкер. А так от ненавистной м$ с ихнего треклятого масма надо брать. Сразу такие преимущества как 'отсутствие потребности в линкере' и 'низкоуровневое управление секциями ' начинают блекнуть... Ну а разработчики вышеупомянутого Award BIOS'а на фасм всё равно не перейдут -- для DOS, afaik, модули/линковка не поддерживается фасмом вовсе.
Если она написана на фасме, то нужно всего-лишь поменять "format PE GUI" на "format ELF executable" и перекомпилить. Любителям масма придется громко матерясь переписывать либу на фасм, насм или на какой-нить другой компилер подходящий для этой задачи.
Зачем же с масма. Есть прекрасный линкер UniLink который покруче линкера от мелкомягких будет. Ясно что не перейдут, так как у них уйма кода написана на масме и переносить его - это ненужная работа.
* Мой друг немного исправил fasm и теперь он генерит отладочную информацию для отладки MenuetOS/KolibriOS в Bochs, что сильно облегчает отладку. Сомневаюсь, что этого можно было бы добиться от других компиляторов ассемблера. * Стандартные макросы fasm'a я не использую, поэтому он мне нравится * Есть несколько примеров программ на асме (free pascal'e и асме (без линковки!)), которые отлично работают и в MenuetOS/Kolibri и в Windows. Правда, программы изначально писались с учетом того, что они будут работать в обеих ОС и они не навороченные. * Пишу на Delphi. Откуда взять hash_map?? Пишу на С откуда взять AVL_tree? (вывод - оба языка полнейший отстой ) К сожалению, Delphi не умеет генерить ассемблерный листинг. Для всего остального можно скомпилить в ассемблерный листинг и сказать вот вам Crystal Reports на асме. (А потом можно немного пооптимайзить ) Был бы спрос компаний на ассемблерные модули, было бы предложение.
Большой проект необязательно должен писаться толпой и в рекордно короткие сроки. И (не)переносимость на другие платформы тоже мало зависит от размера проекта.
Ну дык тогда можно скомпилить любую программу в ассемблерный листинг и сказать что она написана на асме. Теперь я начинаю понимать что такое "большие проекты на ассемблере"
_BC_ А зачем им линковка? BIOS что долго компилится? KolibriOS размером в 83Kb компилится fasm'ом 1 секунду в первый раз и 0.1-0.2 секунды в следующий раз (разница за счет кэша диска и.т.д.). Для BIOS'a соотвественно будет 0.5 секунды. Скорее они не перейдут, поскольку им не охота переписывать весь существующий код, внося при этом кучу ошибок.
Ms Rem Проекты при этом получаются действительно "большими" . Тем не менее это не плохой способ использования высокоуровневых библиотек в низкоуровневой программе. Нужно только написать небольшую программу, которая сконвертит сгенерированный компилятором tasm/masm листинг в fasm листинг.
Зависит от предназначения этого проекта. В большинстве случаев, если проект будет писать один программист на ассемблере (при этом оптимизируя каждый байт и радуясь как хорошо получается), то заказчик скорее всего предпочтет найти другого программиста, который будет чуток порасторопнее. Возьмем в качетсве примера биллинговую систему Net UP UTM. Она конечно по своим масштабам не из самых крупных проектов, но поддерживает следующие ос: » Linux » FreeBSD » Windows NT4.0/2000/XP » Sun solaris Более сложные системы этой категории имеют гораздо более впечатляющий список поддерживаемых ОС/аппаратных платформ.
ну, есть же у нас демократия какая-никакая? Во-первых у нас путаница с большими проектами - их много и они могут быть очень разными, кроме того я не говорил что асм является универсальныс решением для ВСЕХ проектов, а лишь оспорил аргумент, что он является нецелесообразным. Во-вторых я никого и не призываю писать что-то объемное на асме, просто не очень хочется, чтоб асм априори считался языком вирусов и пр. Идем дальше Про скорость разработки. Сам по себе код на асме пишется как минимум в 2 раза быстрее из-за меньшей избыточности, но как ты заметил, под асм ес-но меньше уже готового к использованию кода и из-за этого считается что скорость разработки меньше... Тогда надо определиться в чем мерять Для проектов, в которых достаточно накидать готового, как конструктор лего, ес-но такая скорость будет выше, но никто и не заставляет юзать асм для таких проектов. Кстати с крипто у тебя уже мимо кассы - всяких хешей и криптоалгоритмов на асме - море Вот если взять гипотетический проект, для которого заведомо нет общедоступного готового решения или большей его части - то очень большой вопрос, что заработает быстрее ты так спрашиваешь, как будто я кричу о том, что асм найлепший язык для портирования Как минимум часть кода переписывать надо будет скорее всего, я вот скоро буду часть своих проектов на покет переписывать, вот тогда и расскажу В любом случае плохая портабельность асма, не аргумент, остальные языки тоже имеют с этим проблемы. Кстати тут фасм должен рулить, но это уже не ко мне вопрос.
я хотя не оптимизирую каждый байт (я бы даже сказал что наоборот), но у меня есть заказчики, которые вполне готовы несколько месяцев ждать и спонсировать разработку своего решения в первую очередь, так что не факт
почитал, что вы тут понаписывали... если послушать мнение сторонников "разработки агромаднейших проектов" на hll, то появляеться мнение, что ООП зачем-то нужен, а все остальное так, баловство и должно идти ф топку. скорость разработки с нуля,как правильно заметили, на асме в любом случае не уступает более чем на 10%, а в некотрых случаях может и обогнать... кроме случаев,как кто-то опять правильно заметил, когда сразу, так сказать на лету идёт полная оптимизация, без раздумий, что в будущем код надо будет модернизировать. потом, как правильно заметили, из многих прог можно легко вытащить что тебе надо, с помощью дизасма и откомпилить. вот тебе и интеграция высокоуровневых штучек в асм. следующее, переносимость. в С переносимость будет работать только в том случае когда используються функции языка С, а на них ничего серьёзного не сделаеш. конечно остаёться только один минус, на С можно переносить на другие типы процов, но это не такой уж и большой минус, как мне кажеться. а что до высокоуровневости фасма, так там высокоуровневость в основном достигаеться с помощью макросов, а вас их никто использовать не заставляет, так что пишите хоть в опкодах
Опять таки, большие проекты не обязательно должны быть платными. Вы немного отвлеклись, речь вроде шла о (не)пригодности фасма к большим проектам (которые можно с успехом и на ассемблере писать). На чистом ANSI C, без использования сервисов ОС и платформно-зависимого кода, большой проект вряд ли можно написать, хотя бы потому что вывод на экран/работа с графикой и др. нужные в больших программах функции очень специфичны от ОС... Ну а истинно переносимый код на С будет переносим и на ассемблере, по крайней мере в пределах х86. Возвращаясь к фасму... Кто-нибудь писал целиком на фасме программу, разделенную на модули? Что-то я сильно сомневаюсь... Фасм не умеет создавать главный .obj-модуль (format coff), т.е. содержащий entrypoint, со всеми вытекающими последствиями...
LOL! Достаточно экспортировать любую функцию из .obj и затем назначить ее как entrypoint в командной строке линкера.
