Нашёл только такое упоминание (картинки прикрепил к посту)
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 компиляторы есть.