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

Вначале небольшое лирическое отступление. Вот и начался университет. Учеба - вещь интересная, но весьма тяжелая. Начались интересные и сложные спец. курсы и новые дисциплины. Стало уже совсем очевидно, что выпускать рассылку в прежнем темпе (летних каникул) не удастся. Собственно, я и планировал снизить темп с приходом университета. Времени удается выделять значительно меньше, из-за чего может сильно пострадать качество рассылки. Этого мне (а я уверен, что и Вам) совсем не хочется. К тому же, я сейчас пытаюсь решить некоторые технические вопросы, связанные с оформлением рассылки. Дело в том, что мне хочется размещать графические материалы, потому что UML - язык схем, а пока их поместить в рассылку не удается. Скорее всего, решение этой проблемы будет заключаться в том, что выпуск будет выходить без графиков и в письме будет указан точный адрес файла-архива, содержащего полный выпуск. Те средства, которые предоставляет subscribe.ru меня пока не устраивают полностью, потому что до сих пор получаю рассылки в обычном текстовом формате, а не новомодном (и увесистом) HTML. Очень полезной оказалась статистика этой же службы subscribe.ru, которая позволяет понять, что у большинства из Вас нет проблем с доступом к Интернету в режиме on-line. Также мне пока не удается завершить работу над сайтом. Там хотелось бы размещать интересные материалы, связанные с рассылкой. А теперь перейдем к содержательной части выпуска.

В этом выпуске мы поговорим о внешних воздействиях на вычислительную систему. Под воздействием мы будем понимать все, что не относится к вычислительному процессу ни одного из узлов. Например, когда центральный процессор системы производит обработку каких-то данных, то можно считать такой процесс внутренним. Если же мы рассмотрим процесс установки центрального процессора внутри вычислительной системы обслуживающим персоналом или нажатие на клавишу устройства ввода ЭВМ оператором, то эти процессы является внешними по отношению к вычислительной системе.

В общем, такое деление кажется очевидным, но смысл его нужно объяснить дополнительно. Поскольку мы создаем эмулятор (учитывая применение ООП - модель) ЭВМ, то хочется воспользоваться представляющимися возможностями наиболее полно. В дальнейшем хочется иметь модель, в которой, по возможности, не будет зависимости между внутренними процессами и внешними воздействиями. Это стремление объясняется, прежде всего, соображениями надежности и адекватности модели. Вполне логичным кажется такой подход, при котором ни центральный процессор, ни модули памяти не подозревают о том, что есть некий внешний мир. Действительно, в реальных вычислительных машинах не существует аппаратных средств для изменение содержимого ОЗУ или ПЗУ "на лету". Варианты построения специальных моделей с подобными аппаратными возможностями рассматривать не будем в силу того, что подобное решение дорого по сравнению с реализацией программного эмулятора и не должно давать преимуществ. В любом случае, одну и ту же задачу можно решить разными способами. Мы выбрали программное моделирование. Поскольку в программе эмулятора реализовать ту же возможность изменения значений ячеек памяти "на лету" достаточно просто, мы не упустим этой возможности. Реализовать все внешние воздействия мне кажется разумным в форме утилит классов. Поскольку мы ориентируемся на C++, то эти утилиты можно представить в виде классов-друзей для наших классов, представляющих ЭВМ.

В прошлом выпуске мы рассмотрели базовые классы памяти: MemoryController, MemoryChipFrame, MemoChip. Определим их условно в группу Memo. Все они имеют методы для чтения и записи байтов и пакетов. Разница лишь в системе адресации (весь массив памяти в системе представляет MemoryController). Было бы здорово к такой системе обмена данными иметь вторую систему для супервизорного (внешнего) вмешательства. Поскольку мы договорились делать систему с разделением внешних и внутренних событий, такие методы классов реализуем как защищенные, а доступ к ним определим через классы-утилиты, которые являются дружественными по отношения к данным классам. С это целью вводятся методы класса MemoChipFrame:

     virtual void _BYTEWrite(BYTE value, conMax addr)=0;
     virtual void _BYTERead(conMax addr, BYTE& value)=0;

Они помещаются в раздел защищенных (protected) определений и носят чисто виртуальный (pure virtual) характер. В дальнейшем, если модуль памяти (MemoChip или любой другой наследник) захочет определить свое собственное поведение, в нем следует реализовать эти методы. Как вы могли заметить, в этом интерфейсе нет привычных пересылок пакетами. Это сделано умышленно из соображений краткости исходных кодов. На данном этапе вряд ли понадобится отладочный интерфейс с высокой нагрузкой на передачу данных. В систему вводятся два новых класса: AdminMCF (Admin MemoryChipFrame) и AdminMC (Admin MemoryController). Первый выглядит следующим образом:

     Конструктор(MemoChipFrame&);
     Assign(MemoChipFrame&);
     void _BYTEWrite(BYTE value, conMax addr);
     void _BYTERead(conMax addr, BYTE& value);

Этот класс-утилита напрямую вызывает методы для записи и чтения байтов в классы, унаследованные от MemoChipFrame. Класс, с которым осуществляется работа указывается либо как параметр конструктора, либо может быть указана впоследствии методом Assign() Хотя ничто не мешает использовать этот класс отдельно (и это может оказаться очень полезным, например, в случае отображаемых в память регистров устройств), но основное его использование осуществляет следующий класс - AdminMC:

     Конструктор(MemoryController& MC);
     void Assign(MemoryController& MC);

     void AddChipFrame(conMax fromAddr,MemoChipFrame& mc);

     void _BYTEWrite(BYTE value, conMax addr);
     void _BYTERead(conMax addr, BYTE& value);

Этот класс обладает операциями, подобными AdminMCF по чтению и записи данных, только с той разницей, что адреса для этих операций теперь указываются не относительно устройств, а как абсолютные в глобальном адресном пространстве. Они работают следующим образом: находится фрагмент (MemoChipFrame) памяти и вызывается для него нежный метод отладочного чтения или записи. Разумеется, при этом адреса пересчитываются в относительные для этого фрагмента памяти.

Исключительным методом для этого класса является метод AddChipFrame(). Он предназначен для осуществления такого внешнего вмешательства, как сборка глобальной памяти. В реальной вычислительной системе (например, в ПК) этот процесс можно сравнить с установкой модулей памяти в соответствующие разъемы материнской платы.

Эти два класса логично объединить в группу Admin. В дальнейшем в нее планируется помещать все классы, осуществляющие внешнее воздействие на систему. В следующем выпуске мы поговорим о моделировании устройств ввода-вывода и активных элементов системы. Под активными элементами подразумеваются устройства, которые могут сами инициировать обмен данными с ЭВМ. Например, таймер или устройство ввода оператора.

Спасибо за внимание.

С уважением, автор рассылки Виктор Петренко (Top).