A давайте разработаем собственный Z80 на VHDL.

[specorg]

Может кто нить знает как работает конвейер команд в eZ80? Может получиться добавить, возможно удастся ещё увеличить его производительность.

Нашёл только такое упоминание (картинки прикрепил к посту)

http://www.zilog.com/docs/um0077.pdf

Pipeline Description

The CPU pipeline reduces the overall cycle time for each instruction. In principle, each instruction must be fetched, decoded, and executed. This process normally spans at least three cycles. The CPU pipeline, however, can reduce the overall time ofsome instructions to as little as one cycle by allowing the nextinstruction to be prefetched and decoded while it executes the current instruction as displayed in Figure 2. The CPU operates on multiple instructions simultaneouslyto improve operating efficiency.

In Figure 3, the pipelining process is demonstrated using a series of nstructions. The first LD instruction prefetches its opcode and first operand during the decode and execute phases of the preceding INC instruction. However, the second LD instruction in the sequence only prefetches its opcode. The bus WRITE during the execute phase of the first LD instruction prevents the pipeline from prefetching the first operand of the next instruc-tion. Thus, the number of bytes prefetched is a function of the command currently execut-ing in the CPU.
When a control transfer takes place, the Program Counter (PC) does not progress sequen-tially. Therefore, the pipeline must be flushed.All prefetched values are ignored. Control transfer can occur because of an interrupt or during execution of a Jump (JP), CALL, Return (RET), Restart (RST), or similar instruction. After the control transfer instruction is executed, the pipeline must start over to fetch the next operand.

Хотел бы ещё добавить к обсуждению части участников в теме - всё это только теория, не судите строго.

Кто-то в этой теме предлагал вариант, процессора на базе команд Z380 с шиной 16/32 бит. Хороший вариант, все возможности процессора Z380 имитировать не нужно на 100%. Сложность заключается в том что нужно переделать T80 или NextZ80:
- шина данных к памяти 16/32 бит SD-RAM;
- шина адреса к памяти 32 бит (или меньше в целях экономии выводов, если не планируется ставить все 4Гб);
- система команд, регистров, прерываний? Z380;

Ещё момент, Z380 поддерживает проц Z180, нужна ли поддержка команд Z180 в 32 битном режиме? Может "отсеять" ненужные вещи?

Насчёт модели памяти и совместимости с Z80 машинами, такие мысли - поскольку Z80 использовался нами в компьютерах типа Spectrum 48K/128K и т.п. и это является можно сказать эталоном, то почему бы не создать так называемый виртуальный VZ80?

Как это выглядит - выделяем каждому процессу память страницами по 16Кб/64Кб/1Мб. Как раз хватит для режима совместимости Z80 для запуска виртуальных машин 48Кб/128Кб а доступ к памяти до 1Мб по стандарту Pentagon или другой (например).

Можно пойти дальше, сделать параллельную работу этих VZ80 с контекстным переключением, которым будет заниматься менеджер процессов (программа).
Единственное что-то надо делать для разделения ресурсов: экран, порты устройств.
Дальше можно развить идею вывода экрана VZ80 в область окна ОС которая будет управлять системой в режиме VGA например в виде окна. Порты можно сделать у каждого процесса свои или общие и управлять ими при контекстном переключении.

Что касается использования возможностей z380 для работы, то для создания или портирования ОС необходимы механизмы эффективного управления памятью и процессами. Так же важна защита памяти от изменения другими процессами (ошибки, сбои и т.п.).

Можно как вариант взять за основу управления памятью в виде страниц 16Кб/64Кб/1Мб через специальные регистры страниц, в котором в виде битовой карты будет прописаны права доступа процесса к страницам
- 0 нет доступа
- 1 есть доступ

Охват области памяти при размере страницы:

16Кб

1 байт - 8 бит - 128Кб
2 байта - 16 бит - 256Кб
4 байта - 32 бит - 512Кб
2х4 байта - 64 бит - 1Мб
4х4 байта - 128 бит - 2Мб
8х4 байта - 256 бит - 4Мб
16х4 байта - 512 бит - 8Мб
32х4 байта - 1024 бит - 16Мб
64х4 байта - 2048 бит - 32Мб
128х4 байта - 4096 бит - 64Мб

64Кб

1 байт - 8 бит - 512Кб
2 байта - 16 бит - 1Мб
4 байта - 32 бит - 2Мб
2х4 байта - 64 бит - 4Мб
4х4 байта - 128 бит - 8Мб
8х4 байта - 256 бит - 16Мб
16х4 байта - 512 бит - 32Мб
32х4 байта - 1024 бит - 64Мб
64х4 байта - 2048 бит - 128Мб
128х4 байта - 4096 бит - 256Мб

1Мб

1 байт - 8 бит - 8Мб
2 байта - 16 бит - 16Мб
4 байта - 32 бит - 32Мб
2х4 байта - 64 бит - 64Мб
4х4 байта - 128 бит - 128Мб
8х4 байта - 256 бит - 256Мб
16х4 байта - 512 бит - 512Мб
32х4 байта - 1024 бит - 1Гб
64х4 байта - 2048 бит - 2Гб
128х4 байта - 4096 бит - 4Гб

Получается что для полного описания доступа страниц 4Гб по 1Мб на страницу нужно 128 регистров по 32 бита каждый. Но в целях экономии можно ограничится меньшим размером - например, при 8 регистрах по 32бита и размере страницы - охват области памяти:

16Кб - 4Мб
64Кб - 16Мб
1Мбайт - 256Мб

Как видно лучше конечно чтобы страница была равна 1Мб, т.к. позволяет больше памяти охватить, но может конечно в идеале лучше 64Кб, может процессу не нужен целый мегабайт, а только скажем 50Кб. Но для адресации скажем 64Мб в этом случае нужно будет 32 регистра по 32 бит. Возможно для оптимизации, в зависимости от размера памяти в целом нужно будет выбирать свой размер страницы.

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

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

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

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

Кстати насчёт GUI для ОС можно предложить взять за основу FreeGEM http://www.seasip.info/Gem/History/freegem2.html

PS: Для тех кто не понял ничего по поводу страниц, то я описал идею не модели памяти какой-то новой или модификацию имеющиеся , а назначение физическим страницами памяти логических страниц процесса. Память процесса линейна и является логической и состоит из тех страниц которые указаны в битовой карте (где бит установлен в "1" единицу). Все операции процесса выполняются в логических страницах. Склейка - это объединение физических страниц памяти которые принадлежат процессу (по битовой каарте), чтобы у процесса логическая память была непрерывна. Процессу вообще будет не заметно какие его логические страницы назначены на физические - у него будет просто линейная память, без каких либо перерывов и всего механизма этого он не увидит никогда. Обратиться к другим процессам он не может, за исключением, если не указать другому процессу, что такая же физическая страница (или несколько) тоже принадлежит ему - таким образом можно вызывать функции из DLL или ПЗУ например. Программная поддержка тут никакая не нужна - используется обычный асм Z80,Z380 компиляторы есть.

[Advertiser]

[Vadim]

И что мы получаем? Тот же пень, только на основе кода z80, а не 8086. Смысл? Только если в самом процессе разработки.

[specorg]

И что мы получаем? Тот же пень, только на основе кода z80, а не 8086. Смысл? Только если в самом процессе разработки.

Этим идеям до пней очень далеко, даже до i386 тоже. Рассматривается как бы апгрейд проца Z80 в "расширенный" 32 битный режим Z380. Но толку от 32 битного режима без управления памятью будет мало.

Если посмотреть историю развития процессоров в том числе Zilog, то многие пошли по пути аппаратного управления страницами, защитой и уровнями привилегий.

Не помню кто в теме писал, что при запуске одной программы мы получим CP/M.

Допустим напишем мы многозадачный CP/M, как распределять память между программами если все программы находятся в одной и той-же памяти? Можно конечно, но надёжность системы будет низкой - никакой гарантии что кривая программа или драйвер не завалит всю систему.

Судя по всему при развитии процессоров, часть функций ОС по управлению памятью и процессами переложили на CPU. В итоге получили грамотное управление процессами, памятью, повысили надёжность системы. Вот собственно и появилась идея дополнить Z80 процессор необходимым функционалом, чтобы эффективно использовать 32 битный Z380 режим.

[smalcom]

была аналогичная идея про виртуальные z80 с "окнами вывода" в ОС и супервизором на Z380. ИМХО идея живучая. Вот только про Z380 не читал досконально, а вот к примеру схема защиты i386 мне ненравица.

[mastermind]

ИМХО все эти идеи, насколько бы они ни были хороши, насчет продвинутых моделей памяти и т.п. без программной поддержки ничего не стоят.
Вот, например, для начала неплохо бы LLVM-backend для уже существующего Z80 довести до юзабельного состояния, а затем уже есть смысл расширяя его и эмуляторы экспериментировать с усовершенствованиями, которые затем можно и в VHDL/железе воплотить при желании. (когда для них уже есть программная инфраструктура)

[bigral]

...LLVM-backend для уже существующего Z80 довести до юзабельного состояния...

По-моему даже если для z80 генерировать супер оптимизированный код то всеравно его возможности будут достигать максимум того софта который уже есть на CP/M или zx/msx платформах (там все в ручную на асме оптимизировалось !!! это превзойти не реально). Проблема z80 в ограниченном количестве одновременно доступных данных и ограниченной длинне программы (про частоту молчу). Если кто-то предложит хитрый способ ЭФЕКТИВНОГО преодоления адресного лимита в 64кб тот сделает революционный прорыв не токо для z80 а для всех платформ. Из всего что до сегодняшнего момента я слышал, больше всего меня впечатлила в этом плане связка: MMU в PDP-11 + modula2 компилер который генерит спец exe-шники с ограничением размера функций в длинну страницы (8кб). Но там всеравно неясно что делать с длиииинными данными, хотя в теории возможно на уровне системы сделать само-перематывающиеся в окне массивы данных. Так или иначе требуется какой-то механизм эфективной работы с виртуальными адресами (причем по желанию любой разрядности, так как каждой программе нужен разный обьем памяти для работы).

[BYTEMAN]

Кстати насчёт GUI для ОС можно предложить взять за основу FreeGEM http://www.seasip.info/Gem/History/freegem2.html

это же Atari ST ))))

[mastermind]

bigral, никто не спорит насчет ограниченности возможностей Z80.
Но тема-то данная как раз об его усовершенствовании (с целью "преодоления адресного лимита" либо еще для чего). Рабочий LLVM-backend (для Z80) в этом плане очень был бы полезен в плане моделирования/обкатки таких модификаций (ну и, естественно, для создания по ходу дела инструментария для "усовершенствованных Z80", если до этого дойдет), т.к. "легким движением руки" (относительно) можно в такой бэкенд добавлять всякие несуществующие (в реальном Z80) инструкции и т.п. и смотреть что из этого получается, насколько те или иные усовершенствования на практике эффективны и т.п. (т.е. при применении существующих llvm-фронтендов - компиляторов и т.п., которые сами доработок под новые бэкенды практически не требуют, т.к. об архитектуре target-процессора они практически ничего не "знают")
Если не понятно о чем я, рекомендую почитать об архитектуре LLVM.

[ZEK]

тогда уже допилить Z80 под LLVM, что бы поменьше было разворачивание команд машины в команды проца, ну и регистров добалтать, либо сделать прямой доступ к альтернативным регистрам, уже проще будет развернуться

[bigral]

...Если не понятно о чем я, рекомендую почитать об архитектуре LLVM...

во во... и из этой самой архитектуры следует только то что она не рассматривает проблему ограниченности адресуемого пространства совсем, ну т.е. подразумевается что есть пространство адресов которого ХВАТАЕТ (т.е. подразумевается что оно бесконечное???) И что при таком подходе можно сделать с z80??? - правильно, сделать его 64bit адресным (и тогда он мало чем будет отличаться от любого другого проца у которого нет проблем с адресным лимитом, правда опять же на данном этапе развития электроники)