Какими способами вы можете управлять крупномасштабными проектами на ассемблере?

Question

В моем университете класс Programming Assembly (x86 и MIP) подходит к концу.

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

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

Тем не менее, в школе самая длинная программа по сборке, которую я написал, была длиной в 2-3 страницы.

Я недавно читал о том, что магнат Roller Coaster написан одним разработчиком, в сборке.

_{(источник: com.com )}

Мне сложно представить, как кто-то может поддерживать такой большой проект в сборке.

Прямо сейчас я изо всех сил пытаюсь сделать скачок от программ сборки на 2-3 страницы к чему-то немного более масштабному. Даже на моем калькуляторе Ti-83 люди написали клоны Mario / Zelda в сборке, которые должны быть чрезвычайно сложными!

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

Кто они?

Answer 1

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

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

В любом случае, знание того, как все работает в сборке, в конечном итоге сделает вас лучшим программистом.

Answer 2

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

Один активный член сообщества ассемблеров - Стив Гибсон, у него есть целая куча ссылок на хорошие ресурсы для программирования на ассемблере здесь:

http://www.grc.com/smgassembly.htm

Answer 3

Помимо того, что уже упоминалось, я должен упомянуть грамотное программирование ; Я написал приложение порядка 20KLOC сборки ARM (не очень большое, но и не незначительное), и мне показалось, что структурирование кода с помощью noweb чрезвычайно полезно.

Это позволило мне разбить код на небольшие концептуальные части, даже когда несколько частей фактически пришлось объединить / развернуть / и так далее по соображениям производительности. Кроме того, другим программистам стало намного легче понимать то, что я написал, особенно причины, по которым я принял определенные тонкие решения (например, решение, какой операнд должен идти первым в умножении на основе ожидаемого размера операндов).

Answer 4

Единственный современный проект, полностью написанный на ассемблере, который я знаю, если это FASM (мой любимый ассемблер).

Некоторые ассемблеры поддерживают высокоуровневые конструкции, и, если механизм макросов хорош, вы можете написать свой собственный. Я лично считаю это бесполезным; если я хочу высокоуровневые конструкции и понимаю, что я делаю, я использую C или C ++. (Хотя я не думаю, что они являются хорошими языками для управления большими проектами).

Я просто использую ассемблер при необходимости или для обучения.

Если вы хотите написать проект на ассемблере, имейте в виду, что:

• Вероятно, не будет много людей, которые захотят помочь вам с вашим проектом, даже если они найдут его интересным. Мало кто любит сборку, и ваш код должен быть очень хорошо прокомментирован, если вы ожидаете, что кто-то поймет его.
• Сборка не переносимая. Даже для перехода с 32-битного ПК на 64-битный вам придется переписать все.
• Аргумент "сборка быстрее" больше не поддерживается.

Answer 5

Вот документ Питера Лэнгстона , описывающий инструменты и рассуждения, которые они использовали для написания Ballblazer и Rescue from Fractalus, который охватывает организацию и т. Д.

Answer 6

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

При этом все инструменты и методы управления проектом на любом другом языке в равной степени применимы к языку ассемблера. Управление исходным кодом, TDD, спецификации проекта, значимые имена для идентификаторов, разделение задач, шаблоны объектно-ориентированного проектирования (вы можете иметь объектно-ориентированное проектирование без объектно-ориентированного языка) - все они в равной степени применимы к языку ассемблера, как и к C # или PHP

Answer 7

Я знаю людей, которые работают с ассемблером (не Intel). Они создали обширную библиотеку макросов, поэтому они могут использовать ее почти так, как если бы это был язык высокого уровня.

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

Answer 8

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