Когда машинный код генерируется из программы, как он преобразуется в операции аппаратного уровня? [закрытый]

Я рекомендую прочитать книгу Петцольда "код". Он объясняет эти вещи как можно лучше без знания физики / электроники.

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

существует два основных типа ОЗУ, статический и динамический. И, как следует из их имен, до тех пор, пока вы не удалите питание, статическая оперативная память будет сохранять свое значение до изменения. Динамическая память больше похожа на перезаряжаемую батарею, и есть много логики, которую вы не видите с ассемблером или микрокодом или любым программным обеспечением (обычно), которое держит заряженные батареи заряженными и пустыми. Подумайте о куче стаканов для воды, каждый из них быть немного. Статическая память стаканы держат воду, пока она не опустеет, никакого испарения, ничего. Скажем, очки с водой-это единицы, а единицы без-нули (произвольное определение). Когда ваше программное обеспечение хочет написать байт, есть много логики, которая интерпретирует эту инструкцию и командует памятью для записи, в этом случае есть небольшой помощник, который заполняет или опустошает очки, когда команда или читает значения в очках, когда команда. В случае динамической памяти стекла имеют маленькие отверстия в дне и постоянно, но медленно выпускают воду. Таким образом, очки, которые держат один, должны быть заполнены обратно, поэтому вспомогательная логика не только реагирует на команды чтения и записи, но также периодически проходит по ряду очков и заполняет их. Зачем тебе такая ненадежная память? Это занимает дважды (четыре раза?) столько же транзисторов для sram, сколько и для dram. Дважды жара / сила, дважды размер, дважды цена, с добавленной логикой все еще дешевле использовать dram для объемной памяти. Биты в вашем процессоре, которые используются, говорят для регистров и других вещей, основаны на SRAM, статичны. Объемная память, гигабайты системной памяти, обычно dram, динамическая.

основная часть работы, проделанной в процессоре / компьютере, выполняется электроникой, что набор инструкций или микрокод в редком случае микрокодирования (семейства x86 / были микрокодированы, но когда вы смотрите на весь процессор типы микроконтроллеров, которые управляют большинством бытовых предметов прикосновении они, как правило, не платформах, поэтому большинство процессоров не платформах). Точно так же, как вам нужен какой-то работник, чтобы помочь вам превратить C в ассемблер, а ассемблер в машинный код, есть логика превратить этот машинный код в команды для различных частей чипа и периферийных устройств вне чипа. загрузите исходный код llvm или gcc, чтобы получить представление о процентах компилируемой программы по сравнению с количеством программного обеспечения, необходимого для компиляции. Вы получите представление о том, сколько транзисторов необходимо, чтобы превратить вашу 8 или 16 или 32-битную инструкцию в какую-то команду для некоторого оборудования.

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

Я также рекомендую написать эмулятор, у меня есть один под названием thumbulator в github, если вам интересно. Вы сделали ассемблер, поэтому вы понимаете процессор на этом уровне в той же ссылке ассемблера для процессора обычно определяется машинный код, поэтому вы можете написать программу, которая читает биты и байты машинного кода и фактически выполняет функцию. Инструкция mov r0,#11 у вас будет некоторая переменная в вашей программе эмулятора для регистра 0, и когда вы увидите эту инструкцию, вы поместите значение 11 в эту переменную и продолжите. Я бы избегал x86, пошел с чем-то более простым pic 12, msp430, 6502, hc11 или даже набор инструкций для большого пальца, который я использовал. Мой код не обязательно хорош в любом случае, ближе к грубой силе (и все еще багги, без сомнения). Если бы все, кто читает это, приняли одно и то же определение набора инструкций и написали эмулятор, у вас, вероятно, было бы столько разных реализаций, сколько есть людей, пишущих эмуляторы. Аналогично для оборудования, то, что вы получаете, зависит от команды или отдельного лица, реализующего дизайн. Таким образом, не только есть много логики, связанной с разбором и при выполнении машинного кода эта логика может варьироваться от реализации к реализации. Один x86 к следующему может быть похож на рефакторинг программного обеспечения. Или по разным причинам команда может выбрать do-over и начать с нуля с другой реализацией. Реально это где-то посередине куски старой логики, повторно используемые, связанные с новой логикой.

Микрокодирование похоже на гибридный автомобиль. Микрокод - это просто еще один набор инструкций, машинный код и требует много логики для выполнять/выполнить. Что он покупает вам в больших процессорах, так это то, что микрокод может быть изменен в полевых условиях. Не в отличие от компилятора в том, что ваша программа C может быть в порядке, но компилятор+компьютер в целом может быть багги, поместив исправление в компилятор, который является мягким, вам не нужно заменять компьютер, аппаратное обеспечение. Если ошибка может быть исправлена в микрокоде, то они будут исправить его таким образом, что BIOS при загрузке будет перепрограммировать микрокод в чипе и теперь ваши программы будут работать нормально. Нет транзисторы были созданы или уничтожены, провода не добавлены, просто программируемые части изменены. Микрокод является, по сути, эмулятор, но эмулятор, который очень хорошо подходит для набора инструкций. Google transmeta и работа, которая там шла, когда Лайнус там работал. на этом процессоре микрокод был виден немного лучше.

Я думаю, что лучший способ ответить на ваш вопрос, за исключением того, как работают транзисторы, - это либо посмотреть на количество программного обеспечения / источника в компиляторе, который берет относительно простой язык программирования и преобразует его в ассемблер. Или посмотрите на эмулятор, такой как qemu, и сколько программного обеспечения требуется для реализации виртуальной машины, способной запускать вашу программу. Количество аппаратного обеспечения в чипах и на материнской плате находится на одном уровне с этим, не считая транзисторов в памяти, миллионы до многих миллионов транзисторов необходимы для реализации того, что обычно составляет несколько сотен различных инструкций или меньше. Если вы пишете pic12 эмулятор и получить представление о задаче, то задумайтесь, что 6502 взял бы, то z80, то 486, а затем подумайте о том, что четырехъядерный intel 64 бит может включать. Количество транзисторов для процессора/чипа часто рекламируется/хвастается, поэтому вы также можете почувствовать, сколько есть, что вы не можете видеть из ассемблера.