Какие методы вы применяете для структурирования средних (> 20 000 сток в исходнике) и больших проектов на ассемблере? Что вы делаете для того, чтобы структура программы была понятной? Как избегаете истощения пространства имён? Написание больших проектов на яву не предлагать, этот метод мне известен.
Я использую свои библиотеки, просто подлинковывая их. В итоге текст программы начинает напоминать ЯВУ, только eax и mov проскакивают А сама прога- из отдельных файлов, голова/основные процедуры/дополнительные. Ну и конечно данные отдельно от кода, а то в таких исходниках глаза свернешь.
Да кроме разбиения на логические модули, include и lib ничего и не использую по причине ненадобности. Правда у меня всего ~8000 строк.
Разделяю код на набор процедур, развожу их в разные файлы(inc,mac). Использую длинные осмасленные имена(10-15 символов).
Во-первых на WASM.RU есть парочка статей на тему, близкую твоему вопросу. По написанию больших проектов на асме и обсуждение, какой IDE удобнее для асма. А от себя скажу, что использую RadASM. В нём делаю проекты под masm. Это позволяет использовать макросы и некоторые высокоуровневые конструкции типа if else endif. При этом я не теряю контроль над каждым байтом кода. Система именования не очень отличается от C++. Я использую различные инклюды, где каждый похож на отдельный модуль: vmode.inc отвечает за обработку видеорежимов, opensave.inc - за открытие и сохранение файлов, gen.inc - набор функций разного назначения и т.п. Данные в отдельном инклюде, константы - в отдельном, прототипы и импорт - в отдельном. Кроме того, предварительно должно быть составлено тех-задание и разработан логический проект требуемой системы (приложения). А по нему уже можно и кодировать. Иногда помогает писать аналог функции на собственном псевдоязыке, а потом уже переводить это всё в ассемблер. Кроме того, всегда широко использовать комментарии. И последнее, блокнот и ручку ещё никто не отменял. Так удобно строить схему работы системы.
Что бы сократить кол-во строк, можно писАть несколько команд в строке. Иначе запаришся вверх-вниз листать экраны =) .LIB файлы по возможности не использую - это менталитет 70х! Имена меток порой до 50ти символов делаю - отсутствие namespace сказывается. Никогда не использовал блоксхемы, псевдоязыки и прочую дажу и как-то прочитал у Alen I. Holub: Воистину это так. Меняйте названия языков на какие хотите.
Похоже, что 1) по сути у всех один и тот же метод (у меня то же самое: включения, каждому логическому блоку - свой файл, длинные описания и т.п.) 2) проблема истощения пространства имён живёт и здравствует
> Что бы сократить кол-во строк, можно писАть несколько команд в строке. HLL + макросы - рулят, можно использовать конструкции вида: Код (Text): .IF ($invoke(GetProcAddress, $invoke(GetModuleHandle, OFFSET szKernel32), OFFSET szLoadLibrary)) ......... mov hInstance, $invoke(GetModuleHandle, NULL) А насчёт длинных имен.. Я не стремлюсь к длинным именам, но всегда при обозвании меток и процедур, учитываю что бы подумал другой среднестатистичекий программист прочитав моё название в исходнике и понял бы он смысловую нагрузку заложенную в названии. Я против больших неразумных отступов и применения tab'уляции Кстати, какой смысл разделять data и code по разным файлам, можно подумать что data никак не влияет на код, всегда удобно их иметь в одном файле, чтоб в случае чего можно было быстро посмотреть значение и размер того или иного буфера или переменной в data.
Иногда, особенно в сложных алгаритмах, когда находишся на стадии проектирования, очень полезным бывает сформулировать необходимые св-ва, функции и т.п. Я для этого использую обычный блокнот. При таком раскладе можно очень быстро сообразить где и что можно исправить, сделать лучше, и в процессе написания корректировки вводятся значительней быстрее и безболезненей, чем в еслибы это все хранилось в уме. Потому что все запомнить нельзя, рано или поздно что-то забудешь и т.д.
Я же не говрою что я храню всё в уме, у меня некоторые вещи записаны на бумаге =) И кваратики иногда рисую: "это один модуль", "это другой", "а эта стрелочка показывает зависимость (поток сообщений, ...) одного от другого". Я имею ввиду - псевдоязыки создают лишь псевдоясность алгоритма. Многим людям _проще_ понять смысл глядя на реальный код, поскольку язык для них знаком, а псевлокод - нет. А запись на нормальном человеческом языке - это "всего лишь" выражение мыслей, если нет возможности сделать эту запись, то видимо мысли "не совсем чёткие".
S_T_A_S_ .LIB файлы по возможности не использую В чем минусы? это менталитет 70х! Каков менталитет начала XXI века?
Минусы? Хотел бы я узнать хоть об одном плюсе Что лучше, откомпилированный "чёрный ящик" или открытые сорцы? Вообще-то, я не совсем корректно выразился - не только .lib, но и .obj - всё, что связано со словом "linker" Всё это возникло в эпоху, когда существовало ограничение на размер компилируемого исходника и приходилось учитывать не только скорость компиляции, но и время загрузки текста программы. Сейчас, конечно, скорость оптимизирующих компиляторов так же заставляет использовать линкер, но если говорить об ассемблере.. Впрочем, все современные ассемблеры умеют обходиться без линкера > Да такой же, как и полвека назад, поэтому совсем без линкера нельзя :-( Хотя некоторые продвижения есть - intel, например, постепенно отказывается от линкера в своём С++ compiler.
S_T_A_S_ "чёрный ящик" или открытые сорцы Разве в библиотеки нельзя собирать собственный код, при чем тут "чёрный ящик" ? Хотя могу прокомментировать и его. Разве тебе не приходится смириться (за редким исключением) с отсутствием сорцов ОС? Как можно писать программы, если не доверять чужим наработкам? Imho всех сорцев не проанализируешь и не напишешь. Foamplast Какие методы ... > 20 000 сток в исходнике Ни когда не делать исходный текст такого размера. Есть такое понятие как модульность, которую каждый язык реализует по-своему. проблема истощения пространства имён живёт и здравствует Если максимально использовать локальные идентификаторы, то проблема не актуальна. Идеальный вариант - реентерабельный код.
q_q > Можно. Но зачем ?! Больше действий - больше вероятность ошибок. Про (не)доверие чужим наработкам речи нет, нет сорцов чего-то - ну и пусть, но если есть сорцы, то в чём смысл компилировать их в промежуточную форму, кроме того, что "так принято испокон веков" ???
Понятное дело, что если проблем нет, то можно их создать искусственно Если развивать идею, то что будет, если нет необходимого линкера?
S_T_A_S_ Если развивать идею ... Тебя понял. Надо доставать исходные тексты всего и, если это необходимо, переписывать под имеющиеся компиляторы.
давно писаный код более 3-5 строк - почти такой же черный ящик, как и либ. для использования важно, чтобы было четкое описание каждой готовой процедуры: что она делает, что ей надо дать, и что она вернет и в каком случае. и, желательно, чтобы это соотв. действительности
q_q Нет, недопонял Я говорю о способе создания своих проектов. Например, несложно оформить некоторую процедуру так, что в случае однократного использования в проге она будет компилироваться inline, а в случае многократного - как обычно. Как этого достичь применяя LIB? shoo > Может быть (хотя я с этим не согласен), но lib - это чёрный ящик _и_ для компилятора ! _____________ У продвинутых компиляторов есть такая штука, как "interprocedural optimizations across files" - при этом используются обходные пути без генерации obj файлов для каждого .c Так что прогресс идёт Сейчас уже никого не удивляет, что зачастую препроцессоры не выполняют ввиде отдельных модулей, как раньше. Потомучто ничего, кроме замедления компиляции это не даёт.
