При чтении документа ядра ARM я получил это сомнение. Как ЦП дифференцирует данные чтения из шины данных, выполнить ли его как инструкцию или как данные, на которые это может работать?
Обратитесь к выборке из документа -
"Данные вводят ядро процессора через Шину данных. Данные могут быть инструкцией выполниться или элемент данных".
Заранее спасибо за просвещение меня! / MS
Каждый опкод будет состоять из инструкции N байт, которая затем ожидает, что последующие M байт будут данными (указатели памяти и т.д.). Таким образом, процессор использует каждый опкод для определения количества следующих байт данных.
Разумеется, для старых процессоров (например, старых 8-битных типов, таких как 6502 и т.п.) разграничения не существовало. Обычно счетчик программы указывал на начало программы в памяти, и это ссылалось на данные из другого места в памяти, но программа/данные хранились в виде простых 8-битных значений. Сам процессор не мог различать их.
Вполне можно было направить счетчик программы на то, что считалось данными, и на самом деле я помню старое учебное пособие в колледже, где мой профессор делал именно это, и нам пришлось указать ему на ошибку. Его ответом было: "Но это же данные! Он не может это выполнить! Может ли это?", и в этот момент я заполнил наши данные действительными опкодами, чтобы доказать, что, действительно, может.
Простой ответ - нет. Инструкции машинного кода - это просто двоичные числа, как и данные. Более сложный ответ - ваш процессор может обеспечить (а может и не обеспечить) сегментацию памяти, то есть попытка выполнить то, что было указано в качестве данных, приводит к какой-то ловушке. Это одно из значений "ошибки сегментации" - процессор пытался выполнить то, что не было помечено как исполняемый код
.Я думаю, что все дело в том, где хранятся данные в программе и поддержке операционной системы для информирования CPU, является ли это код или данные.
Весь код размещается в разных сегментах изображения (вместе со статическими данными вроде константных символьных строк) по сравнению с хранением для переменных. Операционная система (и блок управления памятью) должны знать это, потому что они могут выкачивать код из памяти, просто отбрасывая его и перезагружая из исходного дискового файла (по крайней мере, так поступает Windows).
Итак, я думаю, что процессор "знает", является ли память данными или кодом. Несомненно, современные конвейерные CPU, которые мы имеем сейчас, также имеют инструкции по чтению этой памяти по-другому, чтобы помочь процессору обрабатывать ее как можно быстрее (например, код может не быть кэширован, данные всегда будут доступны случайным образом, а не в потоке)
Еще можно указать счетчик вашей программы на данные, но операционная система может сказать процессору, чтобы он этого не делал - смотрите NX bit и настройки Windows' "Data Execution Protection" (панель управления системой)
.Каждый прочитанный процессором, как известно, является получением данных или инструкция. Все процессоры старые и новые знают свои инструкции из привлечений данных. С снаружи вы можете или не сможете сказать, обычно не за исключением процессоров архитектуры Гарварда, конечно, что руку нет. Я работаю с MPCORE (ARM11) в последнее время, и на внешнем интерфейсе есть биты, которые рассказывают вам немного о том, какой прочитанный это, в основном, для того, чтобы подключить внешний кэш, объединить, что со знанием, если у вас есть MMU И L1 кэш дальше, и вы можете рассказать данные из инструкции, но это исключение из правила. С точки зрения автобуса памяти это просто биты данных, которые вы не знаете данные из инструкции, но логика, которая инициировала этот цикл памяти и ждет результата, прежде чем он начал цикл, что это было и что это будет делать с этими данными, когда он получает.
Оригинальный дизайн ARM имеет трехступенчатый трубопровод для выполнения инструкций:
Внутренняя логика CPU гарантирует, что она знает, является ли он получать данные на этапе 1 (то есть. ИНКУДЕНИЕ) или на этапе 3 (I.e. Привлечение данных из-за «нагрузки» инструкции).
Современные процессоры ARM имеют отдельную шину для получения инструкций (поэтому трубопровод не стойл во время получения данных), а также более длительный трубопровод (чтобы позволить более быстрое тактовые частоты), но общая идея все еще такая же.