Выпуск 3
[Main] [TMC 1] [TMC 2] [About]
[ 1 2 3 4 5 6 7 * ]


Доброе время суток, уважаемые читатели!

В этом выпуске рассылки я хочу подробнее рассмотреть главный объект эмуляции - микропроцессор.

Вначале замечу, что эмуляция вычислительной системы (ВС) далеко не всегда заключается в эмуляции только ее центрального процессора (ЦП). Хотя существует множество эмуляторов только каких-то отдельных микросхем, практической пользы от них мало. Ведь обычно нам хочется иметь полную виртуальную копию ВС, чтобы можно было на ней отработать полноценные программы. Для этого обычно требуется реализовывать и все устройства, которыми может комплектоваться эта ВС или какой-либо разумный их минимальный набор. Вообще говоря, каждое внешнее устройство тоже состоит из микросхем, работу которых нужно проэмулировать. Однако, в некоторых случаях это делать совсем не обязательно: если нам не нужна столь подробная детализация системы, то подобное точное копирование сильно увеличит затраты на создание эмулятора. Рассмотрим простой пример: для архитектуры IBM PC разработан интерфейс ATA/ATAPI, который оговаривает принципы взаимодействия ПК и контроллера IDE устройств. В эмуляторе совсем не обязательно реализовывать копию этого контроллера. Достаточно запрограммировать правильные отклики от устройств в соответствии с этим стандартом. Впрочем, существуют некоторые подводные камни. Например, если была допущена какая-то ошибка со стороны фирмы-производителя устройства и, в общем, устройство не полностью соответствует стандарту, то исправить эту "брешь" обычно гораздо дешевле на уровне драйвера (отзыв и замена устройств может быть очень дорогим "удовольствием" для компаний- производителей). Поэтому, при эмуляции нам нужно учитывать не только поведение, согласно стандарту, но и отклонения от стандарта.

Хотя в рамках проекта TMC планируется создание не столько эмулятора, сколько адекватной объектно-ориентированной модели, скорее всего, придется пожертвовать детализацией и реализовывать внешние устройства способом, далеким от их физического представления.

Классификация центральных процессоров - задача довольно сложная, однако, наше изначальное ограничения класса рассматриваемых вычислительных систем рамками персональных компьютеров, позволит несколько облегчить задачу. Согласно книге Дж. Донована ("Системное программирование", изд. "Мир", Москва 1975) центральный процессор состоит из следующих блоков:

  • блок управление памятью;
  • регистр команд;
  • интерпретатор команд;
  • общие регистры;
  • рабочие регистры;
  • счетчик команд.

Все эти блоки отличаются друг от друга по выполняемым функциям и своей сложности. Перед рассмотрением давайте уточним понятие регистра. Регистром будем называть набор триггеров, имеющих два положения 0 и 1. Количество таких триггеров определяет разрядность регистра. В общем, можно считать, что регистр - это ячейка памяти, но обращение к ней проходит гораздо быстрее, чем к другой памяти, поскольку обычно такая память помещается на один кристалл с ЦП.

Давайте рассмотрим все по порядку.

Блок управления памятью позволяет осуществлять пересылки между процессором и памятью. Стандартный цикл работы процессора заключается в получении очередной инструкции из памяти (не будем рассматривать возможности кэширования), отработки какой-то логической схемы, поэтому, возможно, требуется считать или записать какие-то данные извне (например, пересылка данных из регистра в память или из памяти в регистр осуществляются командой, обычно именуемой MOV).

Регистр команд служит неким аккумулятором, в который помещается команда, считанная из памяти. Вообще говоря, структура этого блока может быть самой разнообразной, в том числе и отсутствовать полностью.

Интерпретатор команд занимается отработкой поступившей команды и выполнением каких-то микродействий, в соответствии с кодом команды. В том числе, этот блок должен прочитать или записать операнды этой команды в память, если в этом есть необходимость.

Общие регистры - это программно "видимая" память, которая используется для временного хранения операндов, а также определяет состояние ЦП. Например, программа сложения 2 и 2 для процессора 8086 выглядит следующим образом:

        mov     ax,2
        add     ax,2

Первой командой число 2 будет помещено в регистр "ax", а второй к его значению прибавится еще 2. В итоге, регистр ax будет содержать число 4. В каждом ЦП есть так называемый, регистр состояния (в x86 он называется - регистр флагов). Он характеризует режим работы процессора и состояние после выполнения последней команды. Например, весьма распространен флаг (флаг - один триггер в регистре) переноса (Carry Flag), который устанавливается в состояние 1, если последняя арифметическая команда совершила переполнение. Например, у нас регистр содержит 16 триггеров, это означает, что в него помещаются числа без знака от 0 до 65535 (2^16-1). Если мы к числу 65535 прибавим 1, то результат сложения не поместится в 16 бит и будет некорректен. При этом установится флаг переполнения, указывающий на перенос в следующий разряд. Рабочие регистры, в отличие от общих, программно не адресуемы. Они используются интерпретатором команд ЦП для временного хранения операндов или каких-то промежуточных значений.

Наконец, счетчик команд - это регистр, в котором содержится адрес следующей команды, которую должен выполнить ЦП. Исторически он получил название PC (Program Counter), а в архитектуре x86 он называется IP (Instruction Pointer).

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

Теперь мне бы хотелось рассмотреть основные параметры, по которым можно охарактеризовать (весьма, впрочем, поверхностно) ЦП с точки зрения системного программиста. Далее я также буду следовать Дж. Доновану (Общий подход к новой машине, п 2.11):

  1. Память.
    1. Какова минимальная единица памяти?
    2. объем памяти?
    3. схема адресации?
  2. Регистры.
    1. Сколько всего имеется регистров?
    2. Каковы их размеры, функции и взаимосвязи?
  3. Данные.
    1. Данные каких типов могут обрабатываться этой вычислительной машиной?
    2. Может ли она обрабатывать символьную информацию, числа, логические данные?
    3. В какой форме эти данные хранятся в памяти?
  4. Команды.
    1. Какие классы команд входят в систему команд вычислительной машины?
    2. Имеются ли арифметические команды, логические команды, команды для обработки символьных данных?
    3. Каковы их форматы?
    4. Как они хранятся в памяти?
  5. Специальные средства.
    1. Какова структура системы прерываний данной вычислительной машины?
    2. Какой механизм защиты предоставляется в распоряжение пользователя?
  6. Как-то мне попалось неплохое разделение команд для x86 на типы, хочу его привести (по материалам Гибсона):

    1. Команды пересылки (регистр-регистр, регистр-память, память- память, стековые).
    2. Арифметика (+, -, *, /, : )
    3. Логика (OR, AND, XOR, ...)
    4. Сдвиг и ротация (SHL, SHR, SAL, SAR, ROL, ROR)
    5. Индексирование и счет (INC, DEC)
    6. Манипуляция с битами (SETcc, TEST)
    7. Зацикливание (LOOP)
    8. Переход (JMP, Jcc, CALL/RET)
    9. Ввода/вывода (IN, OUT)

    На этом мне хотелось бы закончить основную часть рассылки. На этот раз я немного не уложился в планируемое время. Наверное, это сказывается приближение университета :). Сейчас я заинтересовался несколькими путями развития эмулятора, и буду пробовать что-то из этого воплощать. Во-первых, я стал искать проекты эмуляторов, построенных по принципу ООП. Задача оказалась нетривиальной. Я нашел только несколько планируемых проектов на sourceforge.net, но там даже нет толком изложения объектной модели, поэтому не буду приводить ссылки, любой желающий сам может в этом убедиться :). За время поисков мне встретились следующие любопытные проекты (в разделе эмуляторов):

    • MDK - The MDK provides a simulator of D. Knuth's MIX computer, and a development environment to write, run and debug MIXAL programs on it.
    • ATasm - ATasm is a 6502 command- line cross-assembler that is compatible with the original Mac/65 macro assembler released by OSS software. The aim of ATasm is to provide Atari home-brew coders with a comfortable and powerful toolset.
    • PalmZX - A sinclair spectrum emulator for the PalmOS platform. Sure, the platform is limited, but all I want to provide is a way to play manic miner on the palm. I guess I *could* write one up, but where would be the fun in that!

    Первый интересен прежде всего классичностью задачи. Нечто напоминающее Машину Тьюринга.

    Второй - это ассемблер для 6502. Как мне удалось установить опытным путем, именно аналог этой микросхемы установлен на моей видеоприставке Dendy. Мне бы хотелось написать эмулятор для нее, но останавливает несколько обстоятельств. Первое заключается в том, что создано их немало и весьма качественных, а второе, заключается в том, что в Dendy помимо CPU имются еще ряд микросхем - процессор тайловой графики и процессор звука. Если без звука я могу бы обойтись, но реализация графического процессора задача первоочередная, а найти его описание мне не удалось :(.

    Третий интересен своей экзотичностью. Эмулятор для карманного компьютера - это весьма необычно. Появляется возможность поиграть в те игры, в которые когда-то играли на телевизоре, да и размер спектрума был не слишком маленький. Уж точно в карман бы не поместился :).

    И вот на этом мне бы хотелось закончить этот выпуск. Следующий я постараюсь подготовить в течение недели. Спасибо за внимание.

    Автор рассылки: Виктор Петренко (Top)

[Main] [TMC 1] [TMC 2] [About]
[ 1 2 3 4 5 6 7 * ]