Я основываю это в первую очередь на ассемблерах, которые я использовал - в первую очередь на MASM, NASM и (в меньшей степени) TASM. В некоторых более поздних версиях TASM были (есть?) Некоторые функции для поддержки ОО, но я не использовал их много, и я не пытаюсь комментировать их.
Во-первых: большинство языков перешло к структуре, которая по крайней мере несколько древовидна. Будь то объектно-ориентированный, объектно-ориентированный или что-то еще, в отношениях между различными частями системы определено немало. Существует также немало «защиты» одной части системы от случайного «вмешательства», но других частей (хотя защиту обычно можно обойти, если хотите). Напротив, язык ассемблера относительно «плоский» - большинство связей между кодом (и данными) в разных частях системы устанавливаются главным образом с помощью документации и в меньшей степени соглашений об именах.
Результатом этого является то, что часто гораздо проще связать код, чем было бы идеально. Требования, которые привели к выбору языка ассемблера для начала (более высокая производительность, меньший размер и т. Д.), Также часто вознаграждают это - обходя утвержденные интерфейсы, и таким образом вы часто можете получить код, который меньше и быстрее (хотя обычно не слишком много). лучше в любом измерении). Язык и инструменты сами по себе делают намного меньше, чтобы ограничить то, что вы делаете (хорошо или плохо), что накладывает гораздо большую нагрузку на менеджеров, чтобы предотвратить проблемы. Я бы не сказал, что это качественно отличается, но количественно это так - то есть, руководство должно работать, чтобы предотвратить проблемы в любом случае, но в случае языка ассемблера, как правило, требуются более (и часто более жесткие) рекомендации относительно того, что есть или нет ». т приемлемо.
Смягчение этого - в значительной степени вопрос более тщательных руководств, большего руководства от более опытного персонала и более конкретных, тщательно соблюдаемых соглашений об именах.
Кадровое обеспечение является проблемой. Проблемы, с которыми я столкнулся, однако, где не в первую очередь те, которые я ожидал. Найти парней с небольшой индивидуальностью, которые были бы рады перейти на код ассемблера, было довольно легко. Большинство проделали вполне разумную работу, несмотря на почти полное отсутствие опыта использования ассемблера.
Сложность, с которой я столкнулся, заключалась в поиске более старшего персонала - людей, которые могли бы контролировать проект, по крайней мере, с некоторой видимостью контроля, и не были полностью привыкли к языкам, которые обеспечивали (и в значительной степени обеспечивали) руководящие принципы, необходимые для разумного хранения кода ремонтопригоден и понятен.
Оглядываясь назад, я мог быть / вызвал некоторые из самых больших проблем в этом отношении. Я вижу два источника проблем с моей стороны. Во-первых, ко времени проекта, о котором я думаю, я довольно давно писал код преимущественно на высокоуровневых языках и использовал только ассемблер.в крайнем случае. Таким образом, когда я использовал его, почти все возможные приемы для повышения производительности были не только честной игрой, но и ожидаемой. Во-вторых, когда я работал над некоторыми системами, написанными полностью (или в основном) на ассемблере, он находился под руководством некоторых довольно железных менеджеров проектов. В то время я был относительно молод и совершенно откровенно обижался на то, как они управляют вещами, поэтому склонялся к обратному. Оглядываясь назад, то, что они делали, действительно было важно, и делалось не только потому, что они были старыми и негибкими (я уверен, что именно так я и видел в то время).