Почему C ближе к аппаратному обеспечению?

#c

#c

Вопрос:

Одним из преимуществ C является то, что он ближе к аппаратному обеспечению. Но я не понимаю, что это на самом деле значит. Было бы очень полезно, если бы кто-нибудь мог уточнить.

Комментарии:

1. Вы имеете в виду по сравнению с Java?

2. Даже этот ответ подойдет, если он поможет мне понять 🙂

3. Он должен быть ближе к аппаратному обеспечению, чем что-то еще . C не ближе к аппаратному обеспечению по сравнению с ассемблером, наоборот, он далек от аппаратного обеспечения. Так что ваш вопрос не имеет никакого смысла. Даже если бы это было так, оно слишком широкое для переполнения стека. Можно легко написать книгу обо всех вещах на C, которые делают его ближе к аппаратному обеспечению, чем, например, Java.

Ответ №1:

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

Другая причина — дизайн самого языка. Когда Керниган и Ричи разрабатывали C для аппаратного обеспечения DEC, они очень хорошо помнили о реальных аппаратных функциях, таких как регистры, сдвиг битов и т. Д. Между их мышлением и машиной, для которой они писали язык, не было уровня абстракции.

Комментарии:

1. Операторы в C обычно близки к отображению 1-1 с соответствующими инструкциями по сборке во многих архитектурах. Например, разыменование одного указателя (или индексация массива в целом, если на то пошло) часто преобразуется в одну инструкцию.

Ответ №2:

Если сравнивать C с java , C ближе к аппаратному обеспечению, потому что java напрямую не работает в системе. Java выполняется на виртуальной машине Java, которая затем работает в системе.

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

Комментарии:

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

Ответ №3:

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

Ответ №4:

Окончательный ответ:

BCPL, B и C прочно вписываются в традиционное процедурное семейство, типичным примером которого являются Fortran и Algol 60…Они «близки к машине» в том смысле, что вводимые ими абстракции легко основаны на конкретных типах данных и операциях, предоставляемых обычными компьютерами, и они полагаются на библиотечные процедуры для ввода-вывода и других взаимодействий с операционной системой. С меньшим успехом они также используют библиотечные процедуры для указания интересных управляющих конструкций, таких как сопрограммы и закрытия процедур. В то же время их абстракции находятся на достаточно высоком уровне, что при осторожности может быть достигнута переносимость между машинами.

Для конкретного примера C int , скорее всего, будет отображаться на объект с собственным размером слова (16-, 32-, 64-, или 128-битный), и операции над этим int объектом будут выполняться с использованием собственных кодов операций (ADD, MUL и т.д.).

Сравните это с такими языками, как Lisp или Haskell, которые используют арифметику произвольной точности; целые числа на этих языках часто представлены массивами цифр, и операции над ними выполняются почти исключительно в программном обеспечении.

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

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