Мультипроцессор

[Пётр]

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

Так вот, сразу же возникло несколько вариаций на которые, возможно, у народа есть ответ/светлая мысль.

Предположим, что есть общее поле памяти и много CPU. Общий выполняемый код. Процессоры определяют свой номер по чтению из условного порта, допустим, мой уже любимый, порт #00h.

Определить же наличие и количество процессоров будет легко, учитывая то, что каждый выполняет свой код в зависимости от состояния порта. Количество зверьков до 256.
На практике хоть 2-4-8, это вполне нормально для пробы.

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

Дело в том, что у меня в zx-palm для минимизирования зависимости от спецпрограммирования применяется "ход конем", а именно ez прогружает образ ппзу в рам-память Z80, дальше запрет записи, ez пускает и тормозит его в зависимости от задач. Z80+ram+2микрухи - получается отдельный модуль. В данной схемной реализации нет особых проблем в добавлении n-го количества Z80-модулей, т.е. это нужно учесть заранее.

на чтение - самое простое, что пришло в голову, это дать каждому процессору свой кусок 64к, остальное тонкости запуска многопроцессорности в момент инициализации.

на запись - писать одновременно, это уже вопрос, т.е. кеширование или что-то другое.
..
Выстроить их в очередь для обращения к памяти, это самое простое, но теряем производительность на запись, а если учесть возможную необходимую зависимость, то и на чтение.
..
Дать четным одну часть памяти, а остальным другую. Предположим экраны/части (трети) экранов.
..
Запись в более быструю память "хитрым" и быстрым контроллером. Правда в этом случае, количество доппроцессоров сократится.
..
Поставить детекторы записи в память и.. по очереди читать(переносить) из памяти каждого в общее поле, откуда уже формируется картинка и т.п.

[Advertiser]

[Black_Cat]

боян..
http://www.zx.pk.ru/showthread.php?t=4564

[Пётр]

боян..
http://www.zx.pk.ru/showthread.php?t=4564

Я видел эту тему, но думаю, это не из области практики. Очень близко.
Возникли именно практические вопросы, т.к. в "наладоннике" изначально заложено два проца, так что огород городить, когда можно поднять затею "боян"'ов на практически реализуемый уровень и даже пойти дальше. Накладно для 256 камней, но вполне по силам для 2х(для всех), 4-8ми для масштабируемых.

Добавлено через 13 часов 12 минут
Ну и чего все замолчали?

Добавлено через 14 часов 18 минут
Какие мысли по поводу организации записи в память?

[that inside]

хмм ктото увеличевает CLK ктото толичество процов это мода щя такая или есть мысли?
а вапщето сушествуют такие уже давно но там кантроль процов сложно незя просто заставить один читать то другой читать се

[Raydac]

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

[Пётр]

хмм ктото увеличевает CLK ктото толичество процов это мода щя такая или есть мысли?

Есть не только мысли. Я задумался в "Наладоннике" о том, что хорошо бы, чтобы у ВСЕХ реальщиков была возможность получить теже или близкие к моей разработке возможности. Это в свою очередь не оставит zx-palm в программном вакууме, который погубил много хорошего.
Так вот, очень долго (лет 12) крутилось в голове слово, - "как" (подразумевается, как объять все разбросы и шатания), - со временем пришло решение..
Для начала мне надо до конца года показать "Наладонник" на любой из zx-пати, т.к. многие к кому я обращался за софтверной поддержкой говорили дословно, - "для начала сделай zx-palm, а после мы включимся в проект со стороны софта", - и никакие разумные доводы, что для начала нужно хоть какое-то наполнение, по минимуму. Снова задумался, теперь уже меньше, года на три, минимизировал влияние программистов на проект особенностями схемы и тройкой лишних микрух.
Пока жду макетки, решил, что торможу зря, начал продумывать пошаговую отладку участков своей схемы на реальном спеке и вот оно. Возможен апгрейд до 21MZh без переделки базовой платы. Нет никаких проблем подключить шустрые процессоры к реальному спеку.
Прототип вообще соберу из того что уже есть, без заморочек (128+AY).

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

Если у каждого своя память, то какие проблемы-то. А вот когда они будут писать результаты своей работы в интересующую нас область, вот тогда и потребуется что-то особенное.
Сейчас вообще склонен к тому, чтобы контроллер в момент формирования экрана читал одновременно со всех памятей одновременно. Страшно подумать для скольки процессоров это прокатит, т.к. адреса для всех, тоже что и для одного, а данные вообще мимо ULA. Что и как миксовать, вот это придется решать.
Вот с ДМА'бы eZ'товским разобраться, вот это уже хорошие доп CPU по 50MZh каждый.

Добавлено через 12 минут

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

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

[Raydac]

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

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

[Пётр]

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

Ну естественно в некоммерческих целях, многопроцессорный zx-демомонстр.
Если в коммерческом, то никаких загрузчиков-пускателей, а один код и разные значения одного и того же порта для каждого из камней, синхронизация.. В любом случае для демосцены нужно что-то более конкретное.
Уже руки чешутся поднабрать макеток (сегодня видел в магазине под QFP) и намакетировать.. ..но нет, сначала zx-палм (в нем и так, в идеале, два проца).
Кстати, кстати, что-то из реала уже есть, когда сразу две экранных области используют, одну для графики, другую для атрибутов. Очень приличные картинки получаются. Правда по формуле 1x8.

[that inside]

да сильно а конкретно из чего все это по подробней пожалуйсто

[Пётр]

да сильно а конкретно из чего все это по подробней пожалуйсто

А теперь сам конкретизируй, что тебя интересует.