Читаю книгу «Код.Тайный язык информатики». Возник такой вопрос. В главе 17 автор показывает простую схему компьютера, и принципы его работы. Так вот в том примере процессор получал команду, например (загрузить/сложить /сохранить) в двоичном виде. Как я понял, примерно так работал intel 8080.
Я не могу понять как процессор понимает, команду загрузить(к примеру 0000001), то есть как он понимает, что ему нужно конкретно сделать? Эти команды заданы физически и потом как-то сравниваются?
- Вопрос задан более года назад
- 296 просмотров
Комментировать
Решения вопроса 1
Ну если просто, то углубившись в рассматривание микропроцессора мы увидим что на самом «дне» находится так называемые » Элементы цифровой логики» «И, ИЛИ, НЕ».
Это кубики «ЛЕГО» из которых все собрано. Это атомы всей цифровой техники.
Как научиться шарить в компах | Гайд для чайников
Так вот если мы скажем поставим параллельно 8 элементов и подадим на них скажем 8 сигналов (с какими то логическим уровнем 0 или 1 — «00101001» то на выходе мы получим 8 ответных сигналов (в зависимости какой элемент находится в данной позиции «101011100») .
Ну вот эта последовательность кубиков ЛЕГО и определяет систему команд процессора. (например х86, или ARM. ) и ЭТА система команд ЖЕСТКО зашита в конкретный процессор.
Ну а дальше все как катушка с нитками, размещаем соединения всякие штуки для памяти и учитывая что в процессоре миллионы транзисторов, а скажем элемент «НЕ» содержит 2 транзистора, то понятно сколько там этих «кубиков» в процессоре.
P.S. Но если честно то углубляться в эти дебри рационального смысла не имеет так как на Ассемблере 1 команда ну например в 32х разрядном процессоре это скажем 3 слова по 4 байта то есть 12 байт, а скажем программа на С++ после компиляции занимает 200 килобайт то написать код в 16000 строк это задача для истинного мазохиста. такие задачи делает коллектив и каждый все равно пишет по 1-2 тысяче строк потом это сливают в общий проект и потом мы получаем ОС Win10 которая занимает 4 гигабайта кода ну в общем невообразимый объем работы.
Ответ написан более года назад
Комментировать
Нравится 2 Комментировать
Ответы на вопрос 2
у админа три руки
predecoder, предекодер — предварительный декодер, разделяющий несколько CISC-команд из порции на отдельные элементы (см. x86), используя информацию от длиномера. Подготовка команд может происходить наперёд их дальнейшей обработки декодером, если до него есть буфер.
ILD (instruction length decoder: декодер длин команд), длиномер — определитель длин CISC-команд. В x86-ЦП анализирует их префиксы, опкоды и байты modR/M. В ЦП Intel длиномер является частью предекодера, измеряя длины «на лету». В большинстве ЦП AMD он работает с командами при их загрузке из L2 в L1I, сохраняя разметку байтов команд в дополнительных битах в L1I, считываемых предекодером при загрузке порции.
Врубаемся в программирование железа
ID (instruction decoder: декодер команд), decoder (декодер) — набор блоков, преобразующих команды в мопы. В x86-ЦП состоит из нескольких трансляторов и одного микросеквенсера (генератора последовательности мопов) с ПЗУ для микрокода. Осуществляет микрослияние и макрослияние.
translator («переводчик»), транслятор — часть декодера, обрабатывающая простые и частые команды без использования микрокода. В x86-ЦП Intel есть 1–3 простых транслятора (на 1 меньше числа путей конвейера), каждый из которых переводит команду в 1 моп за такт, и 1 сложный транслятор, переводящий команду в 1–4 мопа/такт. Как правило, число генерируемых трансляторами мопов не больше числа путей. Большинство ЦП AMD имеют 3–4 транслятора, каждый из которых переводит команду в 1–2 мопа/такт. Макросливаемые команды обрабатываются парами любым транслятором, но не более одной пары за такт.
.
Ответ написан более года назад
Комментировать
Нравится 2 Комментировать
в общих чертах: так и понимает, как описано в системе команд.
процессор не получил команду, он ее прочитал из первого байта памяти.
если байт(или несколько) соответствуют команде — выполнит и т.д.
если команда предполагает некие данные, то следующие за командой байты считаются данными, а не командой
логика и набор команд зависит от процессора.
Ответ написан более года назад
Комментировать
Нравится 1 Комментировать
Ваш ответ на вопрос
Войдите, чтобы написать ответ
- Процессоры
L3 кеш как сильно бустит производительность игровому серверу?
- 1 подписчик
- вчера
- 83 просмотра
Источник: qna.habr.com
«Железо» для начинающих
Когда заставляешь работать свою первую программу для микроконтроллера (МК), испытываешь удивительное воодушевление. Это может быть простое мигание светодиодами, но ты всегда узнаешь что-то новое, начиная понимать, как все работает. Когда я добился этого в первый раз, то расценил как приглашение в игру. Я всегда считал и продолжаю считать, что работа с МК приносит удовольствие. Это особенно справедливо при непосредственном управлении регистрами внутренней периферии МК, известном также, как «программирование голого железа» (bare metal).
Я испытал большое удовольствие, обучаясь ассемблеру из книг по МК. Да-да, я сказал именно «удовольствие». При изучении программ по аппаратным руководствам, у тебя развивается понимание, как именно из «0» и «1» организуются машинные коды и операнды.
Ты можешь почувствовать, как счетчик команд проходит по памяти, как указатель стека контролирует адрес возврата из подпрограмм и функций обработчиков прерываний. Это создает отчетливое представление о том, как твой код выполняется «железом» машины – аппаратурой. Но так ты не узнаешь ничего об архитектуре программ. Мне этот опыт дался многолетней практикой.
Существует много различных стилей программирования. Но я буду ссылаться только на один – мой стиль, который использую сейчас для написания программ. Сегодня мой стиль программирования не тот, что был 10 лет назад, и 20 лет назад, и 30 лет назад. Надеюсь, что он будет развиваться и дальше. Но я не утверждаю, что мои методы самые лучшие, и всегда готов к обсуждению.
Для программирования я использую интегрированную среду разработки CodeWarrior IDE, большим поклонником которой был еще до приобретения Freescale компании разработчика Metrowerks. Она продолжает мне нравиться и в текущем воплощении Eclipse. Существует несколько других IDE, которые я использую по случаю для обеспечения программной поддержки некоторых наших клиентов. Но когда я пишу свой собственный код для демонстрации характеристик МК, то пользуюсь CodeWarrior IDE.
Мне нравится также инструмент Processor Expert Software в составе CodeWarrior IDE, создающий шаблон программы, который помогает быстрее запустить МК. Он тоже генерирует хорошо документированный программный код для инициализации и управления периферией. Я часто сравниваю код, сгенерированный Processor Expert Software с информацией из справочников и спецификаций на МК. Это помогает понять, как управлять периферией микросхемы и неизменно ускоряет процесс обучения. Чтение технической документации становится менее утомительным.
Программирование на аппаратном уровне не означает, что вы должны писать на языке ассемблера. Это означает, что вы должны понимать язык ассемблера. Вам понадобится дезассемблирвание исходного кода на языке Си. Это в точности покажет, как работает компилятор. Ведь не обязательно то, что он делает, соответствует тому, чего вы от него хотели добиться.
Это важный урок, никогда не путайте желаемый и действительный результат компиляции.
Также вам нужно разбираться в технической документации на МК – в распределении памяти, регистрах, периферии и т.д. Это может напугать, ведь по мере сокращения геометрических размеров кремниевых схем руководства становятся все больше, а МК все сложнее. И это тоже часть веселой игры с микроконтроллером.
Как и документация, программа должна быть написана в виде небольших легко анализируемых блоков. Только так можно развить четкое представление об управлении аппаратной периферией МК. Откусывайте от слона по одному байту (гм!) за раз.
Базовый шаблон
Давайте начнем с начала. Существует простой и широко используемый шаблон запуска МК после подачи питания. С несколькими незначительными отличиями это основополагающая структура, поверх которой компиляторы языка Си и разработчики операционных систем реального времени строят свои программные комплексы. Этот шаблон использует и Processor Expert Software. На Рисунке 1 показана общая структура программы МК.
| Рисунок 1. | Общая структура программы МК. |
Несколько аппаратных элементов МК требуют инициализации сразу после подачи питания, до выполнения основной программы. Эти компоненты относятся больше к работе МК, чем к выполнению прикладной программы. Как минимум, сюда должна входить инициализация сторожевого таймера и тактового генератора. Пока их частота жестко привязана к приложению, все программы требуют инициализации этих двух аппаратных модулей.
Вслед за запуском генератора и аппаратных таймеров следует инициализация программных элементов. Точнее, вам нужно сконфигурировать RAM (память с произвольным доступом). Это память, которая делится между стеком и переменными программы. В общем случае, стек будет наращиваться с конца RAM, в то время как переменные программы располагаются в начале памяти. Это простейшая организация пространства RAM, и в подобном распределении места возможны несколько исключений.
Если указатель стека не был автоматически сконфигурирован – тут самое место задать ему начальное значение, перед выполнением каких-либо подпрограмм или обработчиков прерываний.
Всегда, когда это возможно, я предпочитаю на этом этапе очищать всю RAM. Это приносит свои выгоды. В первую очередь, по определению, это очистит все программные переменные, которые станут равными нулю. Очистка происходит очень быстро. Я считаю, что большинство алгоритмов легче создавать и использовать, если знаешь, что необходимые переменные исходно равны нулю.
Во-вторых, появляется визуальная техника отладки дампа памяти, которая позволяет буквально увидеть использование RAM и выявить, залез ли стек в область памяти переменных.
Когда основная аппаратная часть работает и программные переменные инициализированы, пора запускать функцию main(). Именно здесь в приложении инициализируются специальные программные и аппаратные модули. При использовании модульной техники программирования каждый функциональный модуль должен иметь свои собственные процедуры аппаратной и программной инициализации, требующиеся какой-либо функции.
Наконец, когда все инициализировано, необходимо включить аппаратные прерывания. И сделать это обязательно до того, как программа уйдет в основной цикл функции main(). На выбор существует несколько подходов к построению основного цикла. Три наиболее популярных метода – это конечные автоматы, планировщики и операционные системы реального времени.
Независимо от выбранной структуры основной программы, подпрограммы-функции, отвечающие за конкретные задачи, выполняются в соответствии с программными событиями, в то время как аппаратные события запускают функции обработчиков прерываний. В любом случае, по завершении подпрограммы управление передается в главный цикл.
Главный цикл программы – также единственное место, где следует сбрасывать сторожевой таймер, если он включен. Сбрасывание сторожевого таймера в нескольких местах программы расходится с его основной целью – защитой системы от зависания, т.к. возможен «уход программы» из основного цикла. Эффективное использование сторожевого таймера, очевидно, подразумевает минимальное время выполнения подпрограмм и функций обработки прерываний.
Без привязки к характеристикам какого-либо МК, я рассмотрел основы работы и привел программный шаблон управления МК. Это может показаться несколько старомодным, но я знаю, что не одинок. Многим хотелось бы на каком-то этапе своей карьеры увидеть подобный этому обзор и простые соображения, к которым не так уж легко прийти самому. Все сказанное с равным успехом относится к МК с 8-, 16- и 32-битной архитектурой.
Я считаю, что важно понимать машину, исполняющую твой код. Безусловно, найдется место и программам с высоким уровнем абстрагирования от аппаратной части МК. Но мне доставляет настоящее удовольствие работать с «железом». Я надеюсь, найдутся единомышленники, согласные со мной. Это отправная точка в замечательном путешествии к пониманию условий, при которых можно извлечь максимум из «железа» МК.
Перевод: Антон Юрьев по заказу РадиоЛоцман
Источник: www.rlocman.ru
Фундаментальные основы хакерства. Учимся анализировать программы для x86-64 с нуля
Исследование исполняемого файла можно разделить на три этапа: поверхностный, глубокий, хирургический. На первом мы малыми силами собираем информацию о подопытном файле. Под «малыми силами» я подразумеваю легкие в использовании и широко распространенные средства анализа. В этой статье мы поговорим о них и для наглядности взломаем несложную защиту.