Различия между версиями 10 и 11
Версия 10 от 2018-04-03 14:50:08
Размер: 14128
Редактор: ArsenyMaslennikov
Комментарий: поргамму-гененратор
Версия 11 от 2019-06-14 15:17:59
Размер: 14352
Редактор: FrBrGeorge
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 74: Строка 74:

=== Приложение ===
{{attachment:screenshot.png|Внешний вид MARS: оталдчик и исполняющая среда}}

{{attachment:screenshot2.png|Внешний вид MARS: редактор}}

Инструментальная поддержка преподавания дисциплины «Архитектура ЭВМ и язык ассемблера» на ВМК МГУ

  • Курячий Георгий владимирович, «Базальт СПО»

  • Рудаченко Михаил Евгеньевич, ГБС РАН

Аннотация: преподавание базовой (второй семестр обучения) дисциплины «Архитектура ЭВМ и язык ассемблера» требует совмещать в семестровом курсе (52 часа теории + 52 часа практики) широкую фактологическую часть с практическим изучением одного конкретного языка ассемблера. Продуктивная по сути идея (автокод как практическая иллюстрация архитектуры) встречает всё больше трудностей: изучение современного ассемблера (nasm для x86_64) усложнено незначимыми практическими реалиями, изучение устаревшего (MASM для DOS) или модельного — страдает вопиющим расхождением с современностью. Так или иначе, большая часть теоретического материала не имеет практической поддержки. Авторами разработан, предложен и дважды проведён курс, основанный на архитектуре MIPS32 (эмулятор MARS) и классических модельных машинах, в котором сделана попытка поддержать практикой максимально возможный спектр изучаемых тем с автоматической проверкой программной части домашних заданий. В конце доклада обсуждаются возможности дальнейшего развития программной части курса.

О курсе «Архитектура ЭВМ и язык ассемблера»

Это базовая дисциплина, которую читают на первом курсе во втором семестра на факультете ВМК МГУ. Плотность достаточная (4 часа теории + 4 часа практики в неделю), но объём сведений, которые хочется (следует!) туда втиснуть, год от году растёт.

Цель
сформировать понимание, что такое «архитектуры ЭВМ» и почему они такие
Задачи
теория + фактология + практика
  • Изучить основы логической организации ЭВМ; смоделировать и сравнить несколько различных архитектур
  • Рассмотреть современное состояние ЭВМ и принципы, по которым развивается их архитектура, например:
    • конвенции и ABI;
    • базис: система команд, виды адресации, регистры, подпрограммы, флаги и т. д.
    • системные вызовы, прерывания, ловушки; внешние устройства, порты, MMIO, DMA и прочее; сопроцессоры;
    • аппаратная оптимизация — кеш, конвейер, упреждающие вычисления и зависимости вычислительных потоков;
    • аппаратная изоляция: режимы процессора, виртуальная память, виртуализация;
  • Освоить язык ассемблера, в котором по возможности эти принципы применяются на практике
  • Изучить некоторые приёмы низкоуровневого программирования и моделирования данных

К сожалению, два варианта этого базового курса, на наш взгляд, упираются в две крайности: один воспроизводит курс прошлого тысячелетия по 16-битной архитектуре (MASM4 + DOS), другой основан на nasm и x86_64. Сейчас готовится новый курс на базе Masm32 и Windows XP, сочетающий, на наш взгляд, худшие качества первых двух вариантов — моральную и актуальную устарелость и усложнённость изучаемого материала.

Выбор архитектуры

Мы провели много времени в спорах, что же взять за основу — идеальный учебный процессор в вакууме или настоящее живое железо, в котором пропустить всё лишнее. В итоге разработку идеального процессора мы оставили команде RiscV, а сами пришли к такому компромиссу:

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

  • В качестве базовой архитектуры выбрать MIPS32, как наиболее подходящую по соотношению «современность»/«адекватность системы команд». В виде бонуса мы получаем простой и понятный конвейер. Российские реалии: процессор «Байкал Т» имеет архитектуру MIPS32.
  • В качестве среды программирования выбрать MIPS Assembler and Runtime Simulator (MARS). Недостатки того, что это эмулятор, компенсируются наглядностью

  • Если хватит времени/интеллектуальных усилий, прокинуть мостик между языком ассемблера и Си в стиле «Си — это такой суперудобный макроассемблер», перейдя либо на настоящее железо, либо на полный эмулятор Qemu.

Инструменты

Базовой LMS у нас на факультете является Moodle. В основном использовались три вида модулей — урок, задание, форум-семинар и контрольная. В контрольных мы старались давать параметрические задачи.

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

Эмулятор MARS оказался неплох (правда, только в своей области):

  • Простая IDE
  • Отладчик и дизассемблер, редактора памяти, регистров, сопроцессора
  • поддержка текстового В/В и выполнения программы в режиме эмулятора без UI
  • Поддержка нескольких простейших внешних устройства, в т. ч. работающих по прерываниям и растрового графического дисплея
  • Наглядные модули, описывающие работу конвейера, кеша и предсказателя перехода

Поскольку практических заданий было много (в среднем, 3 к лекции), в какой-то момент в их проверке подключилась система проведения олимпиад Ejudge. И модельные машины, и MARS хорошо встраиваются в EJudge, но в силу простоты и краткости программ для первых, мы решили ограничиться автоматической проверкой только программ для Mars.

Пришлось разработать три варианта «обвязки» Д/З:

  • типа «из памяти в память», когда входные и выходные данные лежат в заданных местах памяти, а необходимый для EJudge ввод-вывод делает программа-footer
  • типа «полная программа» (после изучения темы «ввод-вывод»)
  • типа «подпрограмма» (после изучения темы «подпрограммы и конвенции по передаче параметров»), в которой программа-footer, помимо формирования ввода и вывода, проверяла соблюдение конвенций по вызову

Задачи для контрольных каждый студент получал так: скачивал программу-генератор (на Python), запускал её и получал текст условия и «номер варианта». Контрольные также пришлось проверять вручную.

Выводы

  • Модельные машины в том виде, в котором они описаны в методичке, слишком похожи друг на друга, и не похожи на MIPS. Возможно, стоит отказаться от конкретно этого варианта и разработать более общий фреймворк, позволяющий моделировать более широкий спектр архитектур, причём так, чтобы плавно переходить к системе команд MIPS32.
  • Следующие темы отсутствуют (ещё не запрограммированы или принципиально невозможны) в MARS:
    • Виртуальная память
    • Многопроцессорность
    • DMA и иные контроллеры
    • Упреждающие вычисления, псевдоскалярность, векторность
    • Микропрограммы
    • Виртуализация Все такие темы пришлось изучать «всухую», есть подозрение, что контроль остаточных знаний по ним разочарует. Некоторые из этих тем можно проиллюстрировать, написав соответствующие модули для MARS (это несложно), а некоторые — нет.
  • Курс читался дважды. Оба раза в основное время к теме про Си вырулить не удалось за недостатком ресурсов (времени и плотности материала). Был подготовлен факультативный курс по Си на базе виртуальной машины с Linux и эмулятором Qemu-user-mipsel для изучения сгенерированного кода. К сожалению, формат курса (форум) оказался неудобным для изложения, потому что по факту получился учебник; требуются ресурсы для превращения одного во второе.
  • Вполне возможно, что стратегически правильное решение — отказаться от MIPS в пользу RiscV, как доступной, достаточно несложной, перспективной и ультрасовременной архитектуры. Ранее останавливало отсутствие наглядных инструментов, наподобие MARS, что там сейчас творится — надо исследовать.

См. также

Приложение

Внешний вид MARS: оталдчик и исполняющая среда

Внешний вид MARS: редактор

FrBrGeorge/LVEE_Winter_2018 (последним исправлял пользователь FrBrGeorge 2019-06-14 15:17:59)