Всем известно, что Ассемблер самый быстрый по некоторым вопросам, и по этой причине он чаще всего используется в ядрах различных операционных систем, и то же самое происходит в проектах реального времени, где используется передовая электроника. Проблема возникает позже, когда этот код нужно поддерживать, а его нет, и поэтому В случае ядра Linux разработчики решили перевести этот код Assembler на C.
C - наиболее представительный язык программирования Linux (собственно, из всех платформ * nix) он был разработан Деннис Ритчи и Кен Томпсон в 1972 году, он был создан в системе Unix PDP-11 и был частью Unix версии 2. Учитывая его высокую производительность и портативность, он начал все больше и больше использоваться при реализации операционных систем и, следовательно, Линус Торвальдс Он использовал его в своем проекте, когда еще в 1990 году искал бесплатную и открытую альтернативу Minix.
Конечно, несмотря на такие сильные стороны, Assembler имеет некоторые преимущества перед C, как мы упоминали в начале, поэтому это решение удивило, но судя по тому, что комментирует Энди Лутомирский в списках рассылки ядра ваша работа идет полным ходом и Ядро Linux 4.1 будет первым, кто включит этот исходный код Ассемблера, переписанный на C. В частности, все, что связано с выходом в пользовательский режим, который в настоящее время состоит из смеси кода этих двух языков программирования, но который, учитывая его низкие эксплуатационные расходы, становится все более сложным при обновлении.
Это код на Ассемблере Он давно не обновлялся, а это означает, что новые разработчики не совсем понимают его работу, и, что еще хуже, обновить его будет непросто. Таким образом, вместо попытки частичного изменения они решили начать изменять все эти процедуры Ассемблера на C, и лично я думаю, что хотя некоторая скорость выполнения может быть потеряна (что может быть минимальным, если код C new эффективен) новый и понятный код всегда предпочтительнее устаревшего и почти без возможности обновления потому что не совсем понятно, как это было реализовано.
Во-первых, это ENSAMBLADOR, по-испански.
Во-вторых, весь язык должен быть Скомпилирован (или интерпретирован), поэтому качество результата зависит от КОМПИЛЯТОРА (или интерпретатора).
Поскольку компилятор C значительно улучшился, а ассемблер - очень мало (потому что он уже был очень хорош), в настоящее время разница между скомпилированной программой, написанной на C, и той же, написанной на ассемблере, незначительна или отсутствует (до этого не было).
Даже разница между скомпилированными (C и другие) и интерпретируемыми (Java и другие) программами также была значительно сведена к минимуму.
Так как поддерживать C намного проще, чем ассемблер, это очень разумное решение вносить эти изменения в ядро при анализе рентабельности, слабых сторон, угроз, сильных сторон и возможностей или любого другого, что работает.
для принятия решений.
Мигелю Майолу Туру: Прежде всего, каждый программист, который утверждает, что он один, говорит на АССЕМБЛЕРЕ и понимает английский. Остальные используют Visual Basic и называют себя программистами. Какая жалость. А во-вторых Ассемблер НЕ СОБИРАЕТ. Программы, которые работают с этим, напрямую преобразуют мнемонику в байты. При программировании на Ассемблере машина обращается к машине на том же языке, но для упрощения работы вместо прямой записи соответствующих байтов используется мнемоника. Между набором байтов и инструкцией в Ассемблере существует взаимно однозначное соответствие. Но это, конечно, знает только настоящий программист, один из тех, кто говорит АССЕМБЛЕР. Следовательно, нет никаких улучшений в «конвертере» ассемблера в коды операций, потому что за это улучшение отвечает программист. Компиляторы C (и другие языки) переводят инструкции в заранее установленные макропредставления ассемблера (или машинного кода), и улучшения определяются тем, как эти преобразования.
Зачем использовать C? Потому что легче просматривать и поддерживать что-то более читаемое. Большинство людей не понимают непосредственно коды операций или мнемонику ассемблера. Просто как тот.
Я даже не буду говорить о Java, которая, хотя она и была введена в качестве стандарта очень давно, теперь ненавидима теми, кто понимает код.
Но не верьте мне, спросите Google, ложно ли то, что я сказал здесь.
привет
Привет, Чигуайр, мои глаза падают на лицо, думая, что вы не можете писать по-испански, не используя термины англосаксонского происхождения: это называется «ассемблер».
Конечно, в одном я с вами согласен, о java лучше не говорить, потому что, чтобы говорить чушь, лучше от нее отказаться. У меня был друг, который был похож на вас, но был плотником (а не опытным программистом), и он сказал, что лучше всего была ножовка и другие лучшие инструменты, не говоря уже о том, что он даже закрутил ею винты. Какой пример для подражания!
Английский язык всегда лежит в основе всех вычислительных терминов. Так оно и есть, даже если мы, говорящие по-испански, этого не хотим. Добавьте к этому, что есть термины, которые нельзя перевести как «бит», «байт», «unix», «linux», «DOS» и многие другие. И есть некоторые, которые МОЖНО перевести, но нет таких случаев, как "CMOS", "CSS", "RAM", потому что есть некоторые инициалы, которые не имеют ничего общего с технологиями, и в довершение всего их даже нет в Google. . Нет смысла переводить, если полученное сообщение нечитаемо. Вывод: из-за технических или вычислительных проблем желательно использовать технические термины на английском языке. По той же причине: я предпочитаю писать, что я использую «windows», чтобы сказать, что я использую «windows» операционной системы. И я предпочитаю говорить о CSS и о том, что я использую type = »text / css, чем пытаться сказать, что я использую« таблицы стилей с типом, равным диагональным таблицам стилей текста ». Здоровье.
Программы, написанные на ассемблере, всегда компилируются и никогда не интерпретируются. Однако нет ничего плохого в том, чтобы использовать испанский вместо спанглиша. Имена собственные никогда не переводятся, но используются технические термины, когда они не являются популярными сокращениями. В любом случае, каждый может говорить, что хочет, пока мы все еще понимаем.