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

[Sameone]

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

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

Если страницы будут идти последовательно - то память программе надо будет выделять сразу по максимуму. Это не есть гут (представь себе, что ИЕ при запуске сразу резервирует место под полсотни вкладок с ютуба, хотя ты в 99% случаев открываешь только страницы поиска и почту. Чтобы сделать возможным динамическое перераспределение памяти, следует потратить больше ресурсов на поддержку карты распределения.
Именно: иметь список ИД процессов с указанием номера первой физической страницы памяти, а также иметь список страниц памяти, содержащий для каждой страницы один-единственный элемент - номер следующей страицы. Или 0, если это последняя выделенная страница памяти. При выделении кванта времени для очередного процесса ОС просто "суёт" процессору в специальный регистр ИД процесса. Просто и эффективно.

если не указать другому процессу, что такая же физическая страница (или несколько) тоже принадлежит ему - таким образом можно вызывать функции из DLL или ПЗУ например

ИМХО - так делать не надо, это прямая дорога к dll-hell. Динамическая библиотека - это разделяемый ресурс, для управления которым и предназначена ОС. Т. е. DLL должна лежать в принадлежащей ОСИ области памяти, а приложения должны выставлять запрос на выполнение библиотечных функций. Т. е. процессор должен, как минимум, поддерживать разделение памяти на 2 области (кольца, в терминологии ИБМ) - память ОС и память приложений.

[Advertiser]

[vlad]

А с верилогом-то какие проблемы были?

Как видишь никаких, просто весь проект у меня на VHDL и у Xilinx есть конструкции примитивов не перевариваемые Quartus'ом, типа RAM16X1D (16-Deep by 1-Wide Static Dual Port Synchronous RAM):

RAM16X1D #(.INIT(16'h0000)) RAM16X1D_bit1 (.DPO(rdor[1]), .SPO(rdow[1]), .A0(SELW[0]), .A1(SELW[1]), .A2(SELW[2]), .A3(SELW[3]), .D(DIN[1]), .DPRA0(SELR[0]), .DPRA1(SELR[1]), .DPRA2(SELR[2]), .DPRA3(SELR[3]), .WCLK(CLK), .WE(WE[0] & !WREQ));

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

Согласен, но это уже намного сложнее... Можно конечно использовать для этого M9K установив требуемую разрядность, некий кеш В основном, я пока рассчитываю на 8-ми разрядную архитектуру ReVerSE, как никак это больше знакомо, проще и намного понятнее для начинающих.

Кстати, есть ли готовые кэш+sdram контроллеры?

Готового нет, сейчас думаю стоит ли идти в этом направлении...

[TSL]

у Xilinx есть конструкции примитивов не перевариваемые Quartus'ом, типа RAM16X1D (16-Deep by 1-Wide Static Dual Port Synchronous RAM):

Сегодня собрал проект для некстЗ80, наступил на ту же макрофункцию, но за 2 минуты скачал с гуглов RAM16X1D.v, добавил в файлы квакуса - все скомпилилось искаропке. (Хотя может год назад этого файла в гуглах и не лежало, я хз...)
Вопрос в другом: поскольку аффтар писал хдл для Xilinx, можно ли перепилить сорц с учетом каких-нить оптимизаций для альтер? Сорцы курил, навскидку ничего такого не увидел.

[ZEK]

Quartus'ом, типа RAM16X1D

На том же opencores есть нормально написанные

Кстати, есть ли готовые кэш+sdram контроллеры?

На opencores есть

[b2m]

На opencores есть

Например? Я видел там DDR2 SDRAM контроллер и подобное, но реализации с кэшем не нашёл.

[vlad]

Например? Я видел там DDR2 SDRAM контроллер и подобное, но реализации с кэшем не нашёл.

Можно глянуть как реализован к примеру в plasma-cpu...

[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/железе воплотить при желании. (когда для них уже есть программная инфраструктура)