Почему программы не пишутся на ассемблере чаще?

Hellо, я компилятор.

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

P.S. О, кстати, вы не использовали половину кода, который вы написали. Я сделал вам одолжение и выбросил его.

Я написал shedloads ассемблера для чипов 6502, Z80, 6809 и 8086. Я прекратил делать это, как только компиляторы C стали доступны для платформ, на которые я обращался, и сразу же стали по меньшей мере в 10 раз более производительными. Большинство хороших программистов используют инструменты, которые они используют по разумным причинам.

Мне нравится программирование на ассемблере, но требуется больше кода, чтобы делать то же самое, что и на высоком уровне, и существует прямая корреляция между строками кода и ошибками. (Это объяснялось несколько десятилетий назад в The Mythical Man-Month.)

Можно подумать о том, что C - это "сборка высокого уровня", но сделайте несколько шагов выше этого, и вы находитесь в другом мире. В С# вы не думаете дважды писать это:

foreach (string s in listOfStrings) { /* do stuff */ }

Это будет десятки, может быть, сотни строк кода в сборке, каждый программист, реализующий его, будет придерживаться другого подхода, и следующий человек, который придет, должен будет понять это. Поэтому, если вы считаете (как это делают многие), что программы написаны в первую очередь для чтения другими людьми, сборка менее читаема, чем типичная HLL.

Изменить:. Я накопил личную библиотеку кода, используемую для общих задач, и макросы для реализации структур управления типа C. Но я попал в стену в 90-е годы, когда графические интерфейсы стали нормой. Слишком много времени тратили на то, что было обычным делом.

Последняя задача, с которой я столкнулась, была несколько лет назад, написав код для борьбы со вредоносными программами. Нет пользовательского интерфейса, так что это были все забавные части без раздувания.

В дополнение к другим людям ответы на удобочитаемость, ремонтопригодность, более короткий код и, следовательно, меньшее количество ошибок, и, что намного проще, я добавлю дополнительную причину:

скорость программы.

Да, в сборке вы можете настроить свой код, чтобы использовать каждый последний цикл и делать его так же быстро, как это физически возможно. Однако у кого есть время? Если вы напишете не совсем тупое C-программу, компилятор сделает действительно хорошую работу по оптимизации для вас. Вероятно, сделав по крайней мере 95% оптимизаций, которые вы сделали бы вручную, без необходимости беспокоиться об отслеживании любого из них. Там определенно существует правило 90/10, где последние 5% оптимизаций в конечном итоге занимают 95% вашего времени. Так зачем беспокоиться?

Если средняя производственная программа имеет 100k строк кода, а каждая строка составляет около 8-12 инструкций ассемблера, это будет 1 миллион инструкций ассемблера.

Даже если вы можете написать все это вручную с приличной скоростью (помните, что в 8 раз больше кода, который вы должны писать), что произойдет, если вы хотите изменить некоторые функции? Понимание того, что вы написали несколько недель назад из этих 1 миллионов инструкций, - это кошмар! Там нет модулей, нет классов, нет объектно-ориентированного дизайна, нет фреймворков, нет ничего. И количество похожих кодов, которые вы должны писать даже для самых простых вещей, в лучшем случае сложнее.

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

Хорошо, что я писал много сборок "в старые времена", и могу заверить, что я гораздо более продуктивен, когда пишу программы на языке высокого уровня.

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

При этом этот ассемблерный код завернут так, что его можно вызывать из кода C и обрабатывается как библиотека. Мы не пишем всю программу в сборке по многим причинам. Прежде всего, переносимость; наша база кода используется для нескольких продуктов, использующих разные архитектуры, и мы хотим максимизировать объем кода, который может быть разделен между ними. Во-вторых, знакомство с разработчиками. Проще говоря, школы не учат сбору, как раньше, а наши разработчики намного более продуктивны в C, чем в сборке. Кроме того, у нас есть широкий спектр "дополнительных" (таких, как библиотеки, отладчики, инструменты статического анализа и т.д.), Доступные для нашего кода на C, которые недоступны для кода языка ассемблера. Даже если бы мы хотели написать программу с чистой сборкой, мы бы не смогли, потому что несколько критических аппаратных библиотек доступны только как C lib. В некотором смысле это проблема с курицей/яйцом. Люди убираются из сборки, потому что для него доступно не так много библиотек и средств разработки/отладки, но libs/tools не существует, потому что недостаточно людей используют сборку, чтобы оправдать усилия по их созданию.

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

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

Итак, в основном вы говорите, что при умелом использовании сложного ассемблера вы можете сделать свой код ASM ближе и ближе к C (или, как ни странно, к другому языку низкого уровня на вашем собственном изобретении), до тех пор, пока в конце концов вы так же продуктивны, как программист на C.

Отвечает ли это на ваш вопрос?; -)

Я не говорю это idly: я запрограммировал использование именно такого ассемблера и системы. Еще лучше, что ассемблер может ориентироваться на виртуальный процессор, а отдельный транслятор скомпилировал вывод ассемблера для целевой платформы. Как это происходит с LLVM IF, но в ранних формах он датируется примерно 10 годами. Таким образом, была мобильность, а также возможность писать процедуры для конкретного целевого asssembler, где это необходимо для эффективности.

Запись с использованием этого ассемблера была примерно такой же продуктивной, как и C, и по сравнению с GCC-3 (который был вокруг к тому времени, когда я был вовлечен), ассемблер/переводчик произвел код, который был примерно таким же быстрым и обычно меньшим. Размер был действительно важен, и у компании было мало программистов, и он был готов обучать новых сотрудников новому языку, прежде чем они могли бы сделать что-нибудь полезное. И у нас была резервная копия того, что люди, которые не знали ассемблера (например, клиентов), могли написать C и скомпилировать его для того же самого виртуального процессора, используя тот же вызов и т.д., Чтобы он аккуратно соединялся. Поэтому он чувствовал себя как маргинальная победа.

Это было с несколькими человеко-годами работы в сумке, развивающей технологию ассемблера, библиотеки и т.д. По общему признанию, многие из них превратили его в переносимое, если бы он когда-либо был нацелен на одну архитектуру, тогда всеобщий ассемблер всех танцев был бы намного проще.

Вкратце: вам может не понравиться C, но это не означает, что усилие использования C больше, чем попытка придумать что-то лучшее.

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

Однако, что касается написания большого количества кода в ассемблере, есть несколько причин, по которым это не так много.

• Просто нет (почти) необходимости. За исключением чего-то вроде очень ранней инициализации системы и, возможно, нескольких фрагментов ассемблера, скрытых в C-функциях или макросах, все очень низкоуровневые коды, которые когда-то были написаны на ассемблере, могут быть записаны на C или С++ без труда.

• Код на языках более высокого уровня (даже C и С++) конденсирует функциональность в гораздо меньшем количестве строк, и есть значительные исследования, показывающие, что количество ошибок коррелирует с количеством строк исходного кода. То есть, одна и та же проблема, решаемая в ассемблере и C, будет иметь больше ошибок в ассемблере просто потому, что ее дольше. Тот же аргумент мотивирует переход на языки более высокого уровня, такие как Perl, Python и т.д.

• Написание в ассемблере, вы должны иметь дело с каждым аспектом проблемы, от подробного макета памяти, выбора команды, выбора алгоритма, управления стеками и т.д. Языки более высокого уровня отнимают все это от вас, что почему они настолько плотнее с точки зрения LOC.

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

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

Технология приходит и упрощает и облегчает доступ.

EDIT - чтобы прекратить оскорблять людей, я удалил определенные слова.

Сборка не переносима между различными микропроцессорами.

Почему? Простой.

Сравните это:

        for (var i = 1; i <= 100; i++)
        {
            if (i % 3 == 0)
                Console.Write("Fizz");
            if (i % 5 == 0)
                Console.Write("Buzz");
            if (i % 3 != 0 && i % 5 != 0)
                Console.Write(i);
            Console.WriteLine();
        }

с

.locals init (
    [0] int32 i)
L_0000: ldc.i4.1 
L_0001: stloc.0 
L_0002: br.s L_003b
L_0004: ldloc.0 
L_0005: ldc.i4.3 
L_0006: rem 
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0 
L_0014: ldc.i4.5 
L_0015: rem 
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0 
L_0023: ldc.i4.3 
L_0024: rem 
L_0025: brfalse.s L_0032
L_0027: ldloc.0 
L_0028: ldc.i4.5 
L_0029: rem 
L_002a: brfalse.s L_0032
L_002c: ldloc.0 
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0 
L_0038: ldc.i4.1 
L_0039: add 
L_003a: stloc.0 
L_003b: ldloc.0 
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret 

Они идентичны по функциональности. Второй - даже не ассемблер, а .NET IL (язык посредников, похожий на байт-код Java). Вторая компиляция преобразует IL в собственный код (т.е. Почти ассемблер), делая его еще более загадочным.

Я бы предположил, что ASM даже для x86 (_64) имеет смысл в тех случаях, когда вы выигрываете много, используя команды, которые трудно оптимизировать для компилятора. x264, например, использует много asm для его кодирования, а прирост скорости огромен.

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

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

С учетом сказанного реальное преимущество компиляторов заключается в том, что компилятор может понимать шаблоны и отношения, а затем автоматически кодировать их в соответствующих местах источника. Одним из популярных примеров являются виртуальные функции на С++, которые требуют, чтобы компилятор оптимально отображал указатели на функции. Однако компилятор ограничивается тем, что делает компилятор создателем компилятора. Это приводит к тому, что программистам иногда приходится прибегать к причудливым вещам с их кодом, добавляя время кодирования, когда их можно было бы сделать тривиально с помощью сборки.

Лично я думаю, что рынок сильно поддерживает языки высокого уровня. Если бы язык ассемблера был единственным языком, существовавшим сегодня, то их было бы на 70% меньше людей программировать и кто знает, где будет наш мир, возможно, еще в 90-х годах. Языки более высокого уровня обращаются к более широкому кругу людей. Это позволяет увеличить предложение программистов для создания необходимой инфраструктуры нашего мира. Развивающиеся страны, такие как Китай и Индия, в значительной степени выигрывают от таких языков, как Java. Эти страны быстро развивают свою ИТ-инфраструктуру, и люди станут более взаимосвязанными. Поэтому я хочу сказать, что языки высокого уровня популярны не потому, что они создают превосходный код, а потому, что они помогают удовлетворить спрос на мировых рынках.

Был вызван порочный круг, поскольку сборка стала менее распространенной: по мере того, как языки более высокого уровня созревали, наборы инструкций для ассемблера были построены меньше для удобства программистов и больше для удобства компиляторов.

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

Наши проблемы также сейчас совершенно разные. В 1986 году я пытался выяснить, как получить немного большую скорость из небольших программ, которые включают в себя несколько сотен пикселей на экране; Я хотел, чтобы анимация была менее резкой. Яркий пример для ассемблера. Теперь я пытаюсь понять, как представлять абстракции вокруг языка контрактов и политики обслуживания для ипотечных кредитов, и я предпочел бы прочитать что-то, что близко к языку, на котором говорят деловые люди. В отличие от макросов LISP, макросы Assembly не обеспечивают строгого соблюдения правил, поэтому, хотя вы можете получить что-то достаточно близко к DSL в хорошем ассемблере, оно будет подвержено всевозможным причудам, которые не вызовет у меня проблем, если я написал тот же код в Ruby, Boo, Lisp, С# или даже F #.

Если ваши проблемы легче выразить на эффективном языке ассемблера, тем больше возможностей для вас.

То же самое, что говорили другие.

В старые добрые времена, прежде чем C был изобретен, когда единственными языками высокого уровня были такие вещи, как COBOL и FORTRAN, было много вещей, которые просто невозможно было сделать, не прибегая к ассемблеру. Это был единственный способ получить полную гибкость, иметь доступ ко всем устройствам и т.д. Но тогда был изобретен C, и почти все, что было возможно в сборке, было возможно в C. Я написал очень мало сборок, поскольку затем.

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

Одно из ранних открытий (вы найдете его в "Мифическом человеке-месяце" Брукса, который из опыта 1960-х годов) заключался в том, что люди были более или менее продуктивны на одном языке, как другие, в отлаженных строках кода в день. Это, очевидно, не является общепринятым и может ломаться, когда задвигается слишком далеко, но в целом это относится к языкам высокого уровня времени Брукса.

Таким образом, самым быстрым способом получить производительность было бы использование языков, где одна отдельная строка кода делала больше, и действительно, это работает, по крайней мере, для языков сложности, таких как FORTRAN и COBOL, или для получения более современного примера C.

Переносимость - это всегда проблема, если не сейчас, по крайней мере, в конце концов. Вся индустрия программирования ежегодно тратит миллиарды долларов на перенос старого программного обеспечения, которое в то время, когда оно было написано, "явно" не имело проблем с переносимостью.

Я уверен, что есть много причин, но две быстрых причины, о которых я могу думать,

• Сборочный код определенно труднее читать (я уверен, что его больше времени также нужно писать)
• Когда у вас есть огромная команда разработчиков, работающих над продуктом, полезно, чтобы ваш код был разделен на логические блоки и защищен интерфейсами.

Люди, похоже, забывают, что есть и другое направление.

Почему вы пишете в ассемблере в первую очередь? Почему бы не написать программу на действительно низком уровне?

Вместо

mov eax, 0x123
add eax, 0x456
push eax
call printInt

вы могли бы просто написать

B823010000
0556040000
50 
FF15.....

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

И причина, по которой вы все еще предпочитаете ассемблер, это причина, по которой другие люди предпочитают C...

C - макроассемблер! И это лучший!

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

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

Что C имеет над хорошим ассемблером макросов - это язык C. Проверка типа. Контуры Loop. Автоматическое управление стеками. (Почти) автоматическое управление переменной. Динамические методы памяти в ассемблере - это огромная боль в прикладе. Выполнение связанного списка правильно - это просто страшно, по сравнению с C или лучше, но список foo.insert(). И отладка - ну, нет конкурса на то, что легче отлаживать. HLLs выигрывают там руки.

Я закодировал почти половину своей карьеры в ассемблере, что очень облегчает мне думать в assmebler. это помогает мне увидеть, что делает компилятор C, который снова помогает мне написать код, который компилятор C может эффективно обрабатывать. Хорошо продуманная рутина, написанная на C, может быть записана для вывода именно того, что вы хотите на ассемблере с небольшой работой, - и это портативно! Мне уже пришлось переписать несколько более старых подпрограмм asm на C по причинам, связанным с платформой, и это не забавно.

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

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

Тем не менее, я действительно думаю, что все еще используются для сборки. Например, у меня есть несколько довольно оптимизированных сборочных процедур для обработки больших объемов данных, используя SIMD и следуя параноику "каждый бит является священным" [quote V.Stob]. (Но обратите внимание, что наивные сборные реализации часто намного хуже, чем то, что создавал бы для вас компилятор.)

Я изучаю сборку в comp org прямо сейчас, и, хотя это интересно, также очень неэффективно писать. Вам нужно держать в деталях больше деталей, чтобы заставить все работать, а также медленнее писать те же вещи. Например, простая строка 6 для цикла в С++ может равняться 18 строкам или более сборки.

Лично, его много удовольствия изучают, как все работает на аппаратном уровне, и это дает мне большую оценку того, как работает компьютер.

Как упоминалось ранее, причина существования любого инструмента заключается в том, насколько эффективно он может работать. Поскольку HLL могут выполнять те же самые работы, что и многие строки кода asm, я предполагаю, что это естественно для сборки, которая будет заменена другими языками. И для скейтбординга, связанного с оборудованием, - встроенная сборка в C и другие варианты по языку. Доктор Пол Картер в разделе Язык сборки ПК

"... лучшее понимание того, как компьютеры действительно работают на более низком уровне чем в языках программирования, таких как Паскаль. Получая глубже понимание того, как работают компьютеры, читатель часто может быть намного больше продуктивного программного обеспечения в языки более высокого уровня, такие как C и С++. Обучение программированию в сборке язык - отличный способ достичь этой цели".

У нас есть введение в сборку в моих курсах колледжа. Это поможет очистить концепции. Однако я сомневаюсь, что любой из нас напишет 90% кода в сборке. Насколько актуальным является сегодняшнее знание сборки?

Преимущество HLL еще больше, когда вы сравниваете сборку с языком более высокого уровня, чем C, например. Java или Python или Ruby. Например, на этих языках есть сборка мусора: не нужно беспокоиться о том, когда нужно освободить кусок памяти, а также утечек памяти или ошибок из-за освобождения слишком рано.

Потому что всегда так: прохождение времени и хорошие вещи тоже исчезают: (

Но когда вы пишете код asm, это совершенно другое чувство, чем когда вы кодируете высокоуровневые языки, хотя вы знаете, что это намного менее продуктивно. Это похоже на то, что вы художник: вы можете рисовать все, что вам нравится, так, как вам нравится, без каких-либо ограничений (ну, только по функциям процессора)... Вот почему мне это нравится. Жаль, что этот язык уходит. Но пока кто-то все еще помнит об этом и кодирует его, он никогда не умрет!

$$$

Компания нанимает разработчика, чтобы помочь превратить код в $$$. Чем быстрее будет создан полезный код, тем быстрее компания сможет превратить этот код в $$$.

Языки более высокого уровня, как правило, лучше сбивают большие объемы полезного кода. Это не означает, что сборка не имеет своего места, потому что бывают времена и места, где ничего не будет делать.

Перелистывая эти ответы, я бы поставил на то, что 9/10 респондентов никогда не работали с сборкой.

Это старый вопрос, который возникает каждый раз так часто, и вы получаете то же самое, в основном дезинформированные ответы. Если бы не переносимость, я бы все сделал сам в сборке. Даже тогда я код на C почти так же, как я сделал в сборке.

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

О, хай, я система потока данных. Это приложение, в котором я работаю, полон редких компонентов. Это распределенное приложение, и оно находится на 3 компьютерах, на мощных x86 и двух меньших ARM. Большинство компонентов написаны на С++, но есть критический, написанный в ASM для x86. Кроме того, большинство компонентов имеют несколько вариантов: скомпилированы для разных процессоров, а также некоторые компоненты имеют специальные версии графического процессора. Позор или нет, у меня есть компонент script (компонент оболочки вызывает script), который печатает отчет, но только один раз в год. Это даже не больно, что это всего лишь script, медленный script.

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

Я уверен, что в тот же день появится еще несколько архитектур, которые также касаются оптимизации (и о других вещах упрощают программирование и т.д.), и они смогут охватить все другие области, которые я, поток данных не может.

Итак, тема "C vs ASM" не является реальной дилеммой. Это похоже на то, что лучше использовать цифровые или аналоговые синтезаторы (как я уже упоминал, меня объединяют синтезаторы). Я советую, делаю хорошую музыку. Или слушай. Без разницы. C не соответствует ASM. Во всяком случае, я никогда не видел программу на C, атакующую ASM, или наоборот.

Извините за плохой английский, несмотря на то, что я не новая технология, я не широко известен, я ребенок. Многообещающий. Приходите, посмотрите мой профиль!