nedoPC.org

"Z80 Finite State Machine - или по-русски: конечный автомат."

Та-ак, будем пытаться впихнуть в 4 бита по тактам. Ну и картинки надо будет внимательно порассматривать.
Хорошо, конечно, что и авторы процессора на вопросы отвечают, но всё равно странно, что за столько времени процессор до конца не изучен. Вроде и недокументированных команд немного.
В общем буду ковырять этот процессор. Вот эта тема заинтересовала http://zx.pk.ru/showthread.php?t=12970
Я можно сказать "чайник" в процессоростроении, но очень хочется разобраться, ну и в качестве побочного продукта будет ещё один эмулятор

Вот здесь - глянь - источник, кажется, неплохой... хотя и англоязычный:

http://stackoverflow.com/questions/9673551/zilog-z80-op-code-implementation

Процессор чисто коммерческий - поэтому до конца и не изучен.
Я думаю, Шима, Фаджин и компания неплохо подзаработали, продавая в розницу
недокументированные возможности.
Но они заслужили... проц-то выдающийся и легедарный!

А потом - есть другой фактор: повышение процента выхода годных кристаллов.
Если что-то дополнительное не работает - так оно и недокументированное!

Чем больше я читаю всяких описаний, тем больше возникает сомнений в их правильности. В описаниях много говорится о том что происходит, но почти нет информации почему так происходит. Эти описания слишком громоздкие, содержат много ветвлений, иногда проще описать таблицей на 256, а то и 65536 значений, но всё это может происходить из-за одного транзистора. Например, 3 и 5 биты регистра флагов. Или инструкция ld H,(IX+d). Кстати, а как выполнится последовательность байт "DD 77" или "DD ED 80"? А ещё я нигде не встретил описания почему ld (IX+d),d короче на несколько тактов чем должна быть и когда именно читается второй d, из-за чего плывут эмуляторы компьютеров, в которых используется #WAIT.

Z80 намного проще чем кажется, он рисовался потранзисторно, всё что получилось, со всеми ошибками и недокументированностями, должно подчиняться небольшому количеству простых правил. Когда будет готова плата для опытов создам отдельную тему и буду делиться идеями. Или Шаос напишет письмо в Zilog, visual6502.org срисуют схему, а мне не стоит заморачиваться?

А если подойти с другой стороны:
Команда ADD A,r
Исполняется за 4 такта.
Такт 1:
- выставляется адрес
- MREQ, RD выставляются в 0.
Такт 2:
- анализируется WAIT
- при необходимости вставляются пустые такты для обработки WAIT
Такт 3:
- защелкивается во внутрь код команды
- и наверное весь такт или по крайней мере половина
его затрачивается на раскодирование команды
Такт 4:
- собственно исполнение команды
- в конце такта результат защелкивается в приемнике.
В случае 4-х битности АЛУ мы обработали только половину данных.
????????????

Когда я анализировал растактовки i8080 и Z80 для своего спеца я обратил внимание на одну вещь. ПОЧЕМУ у Z80 опкод (тот что при активном М1) считывается по фронту (0=>1) а данные по спаду (1=>0)? Это наводит на мысль об использовании обоих тактовых перепадов, что логично. Моторолла делала так же: у них все измеряется не в тактах а в состояниях. В такте, соответственно, 2 состояния.

Наверное потому, что информация с шины данных
в первом случае попадает в что-то, похожее на регистр команд,
во втором случае в один из рабочих регистров.
Наверное разработчикам было так удобно.
В случае использования обоих перепадов, можно было-бы
DAD HL,r16 сделать и покороче.

Если внимательно прочитать весь документ Oral History of the Zilog Z80 Microprocessor, то ряд вещей становятся более понятными.

Возможно, если бы Шима и Фаджин делали совсем оригинальный проц с нуля, он был бы шустрее и круче...

Но они решали коммерческую задачу: подмять под себя всех пользователей 8080 и захватить этот рынок, взять лучшее у 6800 Мотороллы и привлечь часть её пользователей.

Поэтому полная совместимость с 8080 им во многом мешала, что сказывалось на аппаратных решениях, к тому же проц не должен был повторять даже частично 8080, иначе их бы затаскали по судам...

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

А вот Z8000 делали несовместимым ни с чем, несколько переуверившись в себе на волне успеха - вот Z8000 популярным и не стал...

А Intel чухнула проигрыша, сделала выводы и поняла - своих пользователей надо увлекать дальше за собой.
Отсюда совместимость снизу-вверх постоянно поддерживается...

Но, говорят, и камни Intel отсюда - одни из самых "мутных", да и систему команд многие считают запутанной и нелогичной...

И ещё есть один момент - очень скользкий: как соблюсти баланс между простотой камня
и удобством его программирования.

Вот, к примеру, у очень стройного простого и логичного 6502 нет инструкций сложения и
вычитания без учета флага переноса С.

С аппаратной точки зрения это совершенно понятное и логичное упрощение - не надо ничего
коммутировать на входе Cin АЛУ.
И когда я конструировал 4-битное АЛУ, я этот момент очень наглядно понял.

Поэтому у 6502 при сложении/вычитании иногда необходимо предврительно манипулировать
флагом С.
Это несколько неудобно, но всё же терпимо...

А вот в микроЭВМ ВЕ48 Intel выбросила инструкцию вычитания - это ОЧЕНЬ упрощает АЛУ,
но вот постоянно складывать с выполненным программно дополнением до 1 - неудобно крайне...

То есть, оба решения приводят к снижению цены кристалла но увеличивают объём
программы и снижают удобство использования камня, хотя и скомпенсированы повышенным быстродействием.

Только вот взвесить "ЗА" и "ПРОТИВ" каждого такого решения весьма проблематично.

Я думаю, что это заблуждение - кристалл Z80 содержит около 6000 транзисторов - отсюда и прикидывай примерный размер полностью покрывающей его стейт машины...

P.S. Фотка кристалла Z80A имеется:

http://s.zeptobars.ru/Z80A-HD.jpg

При желании можно разобраться где у него 8 бит, а где 4...

Интересно, где-нибуть уже начинали разбираться, как с 6502 потранзисторно?



PS. http://ru.wikipedia.org/wiki/Zilog_Z80 - Количество транзисторов: 8500
Хех! Ну Вика лучше всех всё всегда знает!

Эту фотографию уже рассматривал, надо будет попробовать разобраться хотя бы в шинах. Потранзисторно вроде visual6502.org занимаются, но что-то по-моему они не торопятся.

Размер стейт машины представляю. Приведу пример (пока не проверенный, надо проводить опыты на реальном процессоре) что я имею в виду под простыми правилами.
DD и FD вроде как префиксы, которые меняют HL, H, L на IX/IY и для некоторых операций добавляют смещение. Для программиста это именно так. Можно их даже назвать двухбайтными операциями. А дальше начинается: для операций с префиксом отдельная таблица длительностей в тактах, R увеличивается на 2, а не на 1, цепочка префиксов не разрешает обработку прерываний, на команду влияет последний префикс в цепочке, каждый лишний префикс выполняется за 4 такта и увеличивает R на единицу... остановиться можно на операциях вида ld H,(IX+d) Почему она пишет не в IXH, а в просто H? И чем дальше, тем больше становится условий и особенностей. Это можно описать на HDL и пусть дальше оптимизатор старается, но это не наш метод
Как оно внутри:
1. DD и FD - обычные операции вроде NOP, выполняются за 4 такта, увеличивают R на 1. (готова длительность команд с префиксами)
2. При каждой операции устанавливаются триггеры, которые изменят следующую операцию. Эти же триггеры запрещают прерывания. Потом они обязательно сбрасываются, см. следующий пункт. (готова обработка цепочек префиксов)
3. При ld H,(IX+d) адрес формируется с установленными триггерами, а при записи результата триггеры уже сброшены, поэтому запись происходит в H, а не IXH/IYH.
Всё. И эти правила, если они верны, корректно обработают любую операцию, в том числе те недокументированные, которыми никто никогда не пользовался и которых нет в эмуляторах.

Ещё одно правило. Как выполняется операция:
- выставили PC на шину адреса (начали M1)
- выполнили цикл чтения операции, refresh
- циклы выполнения/чтения/записи
Так? Нет.
- выполнили цикл чтения операции, refresh
- циклы выполнения/чтения/записи
- выставили на шину адрес для чтения следующей операции
То есть каждая операция при завершении выставляет на шину адрес для чтения следующей.

То же самое с 3 и 5 битами регистра флагов. На уровне транзисторов там всё намного проще, чем если попытаться описать все возможные исследованные и не очень случаи.

Будет забавно, если у меня получится совершенно другая схема, но на 100% совместимая

В ожидании "железа" рассматриваю систему команд. Далее не совсем упорядоченные мысли.

Явно просматривается основной набор команд и то, что выполняется через префиксы. Префиксы (CB, ED, DD/FD) выполняются как обычные команды за 4 такта, устанавливая соответствующие триггеры, поэтому следующая команда выполнится особым образом.

Триггер префикса DD/FD:
- Заменяет обращения к HL на обращения к IX/IY.
- Если в команде используется косвенная адресация, то в самом начале выполняется цикл чтения байта смещения (3 такта) и вычисление адреса (5 тактов), исключением является только одна команда "ld [IX+offset],data", у которой чтение байта данных происходит одновременно с вычислением адреса, поэтому она на 3 такта короче, чем должна быть. Это же 5-тактовое вычисление адреса используется для относительных переходов.
- Сбрасывается до окончания выполнения команды. (это надо проверить на недокументированных командах)

Триггер префикса CB использует тот же блок, что и основные команды сдвига/вращения. То есть не так: основные команды сдвига/вращения частично используют возможности этого блока.

Префикс ED вообще прилеплен сбоку в последнюю очередь и, кажется, имеет отдельный декодер, при этом основной должен блокироваться.

Эти дополнительные блоки (блок сдвига и блок выполнения ED) подключены через основное АЛУ, у которого выбирается функция Y=B, поэтому эти команды так активно меняют флаги.

Основной блок команд:
- Команды 8-битных пересылок.
- Команды 8-битного АЛУ, изменяющие флаги. Исключение inc и dec, они не изменяют флаг переноса.
- Команды 16-битных пересылок (эта же часть FSM может использоваться для чтения адреса в командах вида "ld [адрес],A").
- Команды перехода, работы со стеком (группы пересекаются из-за команд call, ret, rst, которая тот же call).
- Прочие команды (префиксы, scf, ccf...).

16-битные регистры: BC, DE, HL, AF (всех по два), IX, IY, SP, PC (12 штук, видны на фото кристалла), и временный для хранения адреса (а может даже два, на фото они отдельно). Причём у основных 16-битные только выходы, входов по-моему нет, запись в основные регистры только 8-битная. Но что делать с PC, который всегда инкрементируется?

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

Вот что меня просто озадачивает и коробит при реализации процессоров на мелкой логике,
что в интегральном исполнении коммутация узлов осуществляется чаще всего двумя, а то и
одним канальным транзистором.
То есть - пропускаем состояние, либо размыкаем соединение.

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

Да вот самый простой пример - 4-bit homebrew CPU:



Вот так автор реализовал всякий регистр в своей схеме.

А если начать "нищебродствовать", то это очень отражается на "заумности" схемы, и вызывает
сложности в построении системы команд.

Так что - как ты применишь "железо" на транзисторах, будет весьма интересно!

А зачем буфер цеплять к регистру, у которого у самого перевод в третье состояние имеется? OC - это же оно и есть, нет?...

Вот и я про то же. Если мыслить "как реализовать в эмуляторе" - это одно, "на логике" - совсем другое. А на транзисторы я вот там насмотрелся http://forum.emu-russia.net/viewtopic.php?f=13&t=3938
Можно поставить одну 74HC373, сразу и регистр, и Z-выход.
У меня план как бы такой:
- посмотреть как работает реальный Z80
- эмулятор, пусть даже не realtime, но потактовый
- FPGA (Спектрум, Специалист)
- может быть 80386, но так, "просто посмотреть", понравился вот этот проект http://zet.aluzina.org/index.php/Zet_processor
- своя платформа, nedoSprinter тоже штука интересная, но мне больше нравится "большая дорогая FPGA"
а потом, из любви к искусству, можно Z80 и на дискретной логике, и на транзисторах