nedoPC.org

Ну поделился хотя бы в общих чертах мыслями интересными. А то я вторую страницу
хоть кого-нибуть на этот предмет уговариваю тут.

Ну, например, можно сделать так. Допустим, что у нас 2 проца в Специалисте. По сбросу, один проц висит в ресете сигналом с порта, а второй стартует как обычно, через НП. Вот он стартанул, все сделал, заинитил. На нем крутится ОС. Загрузка файлов и все такое. Он в 0 загружает джамп на стаб, стаб в его системной памяти организован как бесконечный цикл с ожиданием перехода. Он спускает второй проц и тот попадает в стаб. Тут юзер тыцкнул в прожку. Прожка грузится в 0 (например это игра Lode Runner), первый проц подготовил всякое и отпустил второй проц. Устанавливается команда перехода второго проца в 0 и процесс пошел: игра крутится на втором проце, а ОС следит за ним. Ну это все общие положения и они не интересны.
Другой вариант, ИМХО, интереснее. Что если сигналы WAIT/BUSR второго процессора вывести на порт? Тогда первый процессор получает практически полный контроль над вторым! И тогда, при правильной организации памяти программ второго процессора + вывод на порты статуса адреса (данные можно по адресам выяснять, но и их тоже можно вывести) и сигналы управления, то можно организовать настоящую пошаговую трассировку и отладку на железном процессоре. Отсутствие житага можно компенсировать вызовом прерывания (хоть каждую команду), чтобы дампить содержимое регистров. Вот как-то так. :3

Честно говоря мне слегка другого хотелось. Есть задача, супервизор как-то
разделяет её между процессорами и они начинают молотить свои части параллельно,
после выполнения идёт обмен результатами и супервизор как-то осуществляет
синхронизацию. Собственно в этом видится выигрышь - не шибко мощные процы
достигают большей производительности решая задачу одновременно частями.
Таков был, как мне кажется, принцип конвееров ещё у Генри Форда...

Ну, это логически правильно и подразумевается по умолчанию. Главное - это правильно планировать решение задачи, под многопоточность.

Ну дык надо попробовать, пока ты пекёшь горячий "Специалист",
может даже на одном типе процессоров, если это будет проще.
И Шаоса попросим с ОСью подмочь, ведь в его голове "Многие структуры и решения
для такой системы уже давно сложились и продумались ... еще с десяток лет назад".
А тут вдруг он заскромничал что-то. Может хоть общую концепцию параллелизма продумаем...
Тем более, что "Спец" тебе это явно не испортит.

Спец-М в смысле многоядерный? Ололо! Но вариант, да. Надо продумать циклогенератор на эту тему. Хммм. Подумал тут, что свой SpeZ-M как раз двухядерным наверное и сделаю. Или даже 3х. Посмотрим, по расчетам.

Ну надо же рискнуть попробовать, если по всеобщим здесь воспоминаниям, такого 8-битного компа до сих пор практически не было!
Тем более не лепить всё с нуля - а на базе любимого нами "Спеца".
У меня макетка больше твоей - на ней только синхрогенератор был тогда
собран. Получится - я тоже на ней сделаю. А то я было прицеливать её
начал под РИСК-проц на мелкой логике.

Вот RAW дамп моих начальных мыслей :3

Юзаем Z80. Думаю, не надо объяснять почему. Z80 хочет данные по обоим перепадам такта: по подъему М1 опкод а по спаду просто данные. У нас есть еще и синхрогенератор, которому тоже нужен доступ к памяти. Если учесть, что доступ одному процессору требуется на обоих фронтах, а такт равен 8ти точкам растра, тогда мы получаем 4 устройства и 8 слотов обращения к ОЗУ. 1 устройство - это синхрогенератор, остальные 3 - 3 процессора Z80. Каждое обращение к общему ОЗУ каждого процессора нужно прогейтить соответствующим сигналом фазы. Т.к. синхрогенератору разрешено обращаться 2 раза за 8 точек, то второе обращение можно приспособить под чтение атрибутов, тем самым используя только одну 8ми битную память. Атрибуты необходимо будет задержать на 4 точки: технология как в спектруме, + еще один регистр. В таймингах это выглядит примерно так:

Легенда:
20M - Gиксельклок.
S/C - Слот времени обращения синхрогенератора.
P/A - Этот сигнал можно использовать для указания адреса для разделения атрибутов и пикселей.
ASTB - Строб записи атрибутов, сама запись синхронно по пиксельклоку.
ASTB - Строб записи пикселей, сама запись синхронно по пиксельклоку.
Fn - Слот обращения к памяти процессора с номером n.
CLKn - Тактовая частота процессора с номером n, для каждого в своей фазе.
При уже отработанной развертке SVGA для специалиста 384х256, одно обращение к памяти занимает время 1 точки. Это 50нс. Я проверил на своей 15нс памяти, с учетом задержки в 555КП2 мультиплексорах - все успевает. Эта общая память будет содержать экран (даже если ее всего 64КБ, и атрибуты будут находиться прямо в ней же, можно для сокращения объемов как в спектруме - один атрибут на знакоместо в 8х8 точек) и некоторое общее окно. Помимо этого, каждый процессор будет иметь свое ОЗУ (64КБ хватит, принцип такой же, как у МХа: вся область переключается, окромя маленького шлюза вверху), а первый Z80 еще и ПЗУ для стартовой программы. Делать доступ к портам всем можно, но не обязательно (в случае с Z80 можно реально развязать порты на IORQ), т.е. достаточно одному. Или каждому можно сделать выделенный набор портов. Первый проц стартует из ПЗУ, по принципу специалиста, остальные стартуют от 0 из этого общего ОЗУ, тем самым им не требуется свое ПЗУ: мастер зальет задачу, пустит второй проц, задача этого процессора прокеширует все что надо (код и данные) в свое ОЗУ, переключится и будет маслать, изредка поплёвывая результатами в выделенную область основного ОЗУ и/или забирая оттуда новые. Потом так же запускаем третий процессор. Каждый из них может нагадить в основное ОЗУ (а значит и экран). Ну а синхронизация потоков - это уже дело программистов.

Ну собственно и весь концепт. Только синхрогенератор и циклогенератор я буду делать на CPLD, ипал я в рот еще раз паять эти проводки в тройном экземпляре. :3

Задался вопросом, а что в принципе есть по похожим двухпроцессорным компьютерам?
Что нам глаголет Гугль? Негусто...

1.Электроника УКНЦ
С точки зрения архитектуры, УКНЦ — двухпроцессорная машина, т. к. содержит два одинаковых процессора 1801ВМ2, один из которых (центральный процессор) исполняет программы пользователя, а другой (периферийный процессор, ПП) выполняет роль контроллера периферии: клавиатуры, дисплея и др. Между процессорами существует несколько каналов обмена, причём обмен через каналы устроен так, что ПП выглядит для ЦП как VT-терминал: от ЦП к ПП передаются символы для вывода на экран, от ПП к ЦП — символы, вводимые с клавиатуры. Периферийный процессор имеет собственные 32 КБ ОЗУ, видеопамять — 3 блока по 32 КБ и 32 КБ ПЗУ со встроенными сервисными процедурами. Существовала возможность запустить код на втором процессоре и некоторые программы это использовали. Можно было задействовать часть видеопамяти как виртуальный диск, при этом палитра цветов сокращалась до одноцветной.
http://softina.do.am/publ/13-1-0-12

2. Epson НХ-20
Epson НХ-20 был двухпроцессорной системой: в нем работали два 0,6-МГц процессора Hitachi 6301. Возможности НХ-20 были весьма скромны: производительность процессоров невелика, объем ОЗУ - всего 16 Кбайт, монохромный экран, отображающий всего четыре строки текста по 20 символов. Однако это полноценный ПК - в его ПЗУ был записан Microsoft BASIC, он был оснащен последовательным портом и встроенным ленточным накопителем.
http://www.npk.ru/articles/article.html?id=120

3. Sega Mega Drive
Прообразом послужил игровой автомат "System 16" фирмы SEGA. Именно у него была заимствована двухпроцессорная архитектура: MC68000 (Motorola) и Z80 (Zilog).
http://www.chipinfo.ru/literature/radio/200207/p33-35.html

4. BBC Microcomputer
Технические характеристики
Процессор: MOS Technology 6502A (в Model B — 6512A) на тактовой частоте 2 МГц
Память: 32 КБ ПЗУ (в Model B — 48 КБ), 16 КБ ОЗУ (в Model B — 32 КБ, в Model B+ — 64 КБ)
Полнофункциональная клавиатура с десятью функциональными клавишами
Экран: 8 текстово-графических режимов — от 160 х 256 точек при 8 цветах, до 640 х 256 точек при двух цветах.
для BBC Micro выпускалось несколько вариантов "second processor", например: Z80 или 6502
Все это были модули расширения с сопроцессорами, которые использовали, помимо собственных, ресурсы основной машины, прежде всего среду I/O.
Технология подключения второго процессора у Acorn-а получила название "Tube".
С подключением "second processor" становилось возможным использовать дополнительный софт, или ускорить работу уже имевшегося.
Двухпроцессорная система, ПО если верить описаниям было. В частности Z80 подключали для использования CP/M и софта под него.
http://ru.wikipedia.org/wiki/BBC_Micro
http://zx.pk.ru/showthread.php?t=11368&page=22

PS.
Ну посмотрим, что программисты скажут... Я - убей не знаю, как "синхронизацию потоков" затеять...

PPS.

PPPS.Процессор 1801ВМ2, можно считать, довольно крут, но и стар, и в УКНЦ его
превратили как 8086 в 8088 (так глаголят в инете).
http://www.az-libr.ru/Persons/0GN/fe16506c/Books/info/19880219.shtml

2_HardWareMan

Тут материальчик, похоже, для тебя будет интересен. Поскольку о 16-разрядном Z80 ты тут на форуме мысли высказывал.
http://www.nedopc.org/forum/viewtopic.php?t=7925&postdays=0&postorder=asc&start=0
Я не знаю, бред это или смысл имеет - не вник пока...
http://abzac.retropc.ru/content?id=293



PS. И ещё взглянь - что вот здесь за хламида?
http://www.benryves.com/projects/z80computer

2_HardWareMan

Ну в принципе - всё логично, вроде, в твоём "RAW дамп".
Поскольку я не знаю аналогов - сравнить мне не с чем.
Растактовку по экранке проверять мне бестолку - это уж
как у тебя в железе уляжется.

Но вот этот момент меня чуть смущает:

Функции БИОС и OC процы откуда брать будут? Первый - из ПЗУ, а остальные?
В ОЗУ им накидаем копии? ПЗУ-то обычно более медленное...

Гуглю Инет на вопрос "Многопроцессорные системы и параллельное программирование".
Как всё неконкретно и расплывчато, как и во всех
книжках, что я читал...
Нет живого примера, от чего отпрыгивать начать...

ПедиВикия утверждает, что мы можем сильно и не выиграть...
https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BC%D0%BC%D0%B5%D1%82%D1%80%D0%B8%D1%87%D0%BD%D0%B0%D1%8F_%D0%BC%D0%BD%D0%BE%D0%B3%D0%BE%D0%BF%D1%80%D0%BE%D1%86%D0%B5%D1%81%D1%81%D0%BE%D1%80%D0%BD%D0%BE%D1%81%D1%82%D1%8C


Исходя из того, что мы предварительно обсудили, хотелось бы добиться
Распределённых вычислений.
https://ru.wikipedia.org/wiki/%D0%A0%D0%B0%D1%81%D0%BF%D1%80%D0%B5%D0%B4%D0%B5%D0%BB%D1%91%D0%BD%D0%BD%D1%8B%D0%B5_%D0%B2%D1%8B%D1%87%D0%B8%D1%81%D0%BB%D0%B5%D0%BD%D0%B8%D1%8F

И на кого возлагается эта бодяга? На программёра или частично эту задачу
можно возложить на супервизор и ОС?

PS. Ну вобщем-то основные черты вырисовываются... Завтра к вечеру, возможно, их соберу и изложу...

Советую перестать читать русскоязычную википедию - особенно на ночь
Там ничего кроме дезинформации и тупых приколов давно уже нету...

Открываю истину - даже однопотоковые приложения выигрывают на многопроцессорных (многоядерных) системах, т.к.кроме запущенного приложения в компьютере ещё живёт и операционная система с кучей своих параллельных процессов, в том числе занимающихся отрисовкой графики. А если в приложении использованы треды, то оно уже способно распараллеливаться. Если очень хочется в однопоточном приложении заюзать все ядра, то можно пошаманить с OpenMP (не путать с OpenMPI) - это некая надстройка языка C/C++, говорящая компилятору в каких местах и как код можно раскидывать на разные ядра - например так можно раскрывать циклы и т.д.

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

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

А самый простой способ организации взаимодействия между параллельными процессами - это очереди событий. Если кто программировал для Windows - то это оно и есть...

Ну да, система все равно ляжет в общее ОЗУ (или только самое нужное). Остальное - в локальном ОЗУ.

Прикинем, что у нас получится на основе 4-х процессорного "Специалиста", где мы решили сделать один процессор ведущим и три ведомыми, но как-бы независимыми, поскольку каждый процессор будет иметь своё ОЗУ (64КБ хватит, принцип такой же, как у МХа: вся область переключается, окромя маленького шлюза вверху), а первый - еще и ПЗУ для стартовой программы. Максимум что получится - многозадачная система, задачи на четыре, если не делать программный механизм сохранения и замещения задач, используя СМД-карту как диск.

Асабливая здесь неприятность, что прототип - "Специалист" - система сильно связанная. К примеру, опрос клавиатуры жестко завязан на процессор и без него даже скан-код не формируется. А многопроцессорные машины в теории - слабосвязанные. То есть, имеем налицо все проблемы Виндавоза с устройствами ВВ - они общие для всех процессоров. А программное обеспечение, мы знаем, способно у нас порт клавиатуры перенастраивать, что и так создаёт трудности при подключении стандартной клавиатуры. Если исключить дикую возможность дать каждому процу по своей ВВ55, то остаётся то, что УВВ ведомым процам мы не даём, а ведущий должен обслуживать ВВ55, отслеживать прихоти в настройке её каждым процем, читая "РУС" из памяти по месту УС ВВ55 и подставляя в память ведомым на адреса портов А,В,С нужные значения. Если это в принципе программно решаемо - на ведущий придётся повесить прерывание, хотя бы от счётчиков на 50-60 Гц, как в "Синклере" - обслуживать клавиатуру и поддерживать функции многозадачности, если конечно мы хотим, чтоб и ведущий что-то делал, кроме задач супервизора.

Второе - это таймер ВИ53. Здесь ещё хуже. Особого стандарта на него нет и заюзан он преимущественно для звука - на него даже в оригинале не повесишь прерывание - нет подходящей частоты. Таймер при 2.5МГц у ведущего - не сымитируешь для ведомых. Отсюда - либо дать им по таймеру, скоммутировав программно-аппаратно выходы так, что звучит таймер активной задачи - либо не давать таймеров навовсе. Вариант - отдавать таймер процу активной задачи - наихудший. Придётся отслеживать настройки и в итоге каша получится.

Теперь область экранного ОЗУ. Конечно, неплохо коммутировать её на вывод от ОЗУ активной задачи. Перебрасывать массив экрана - тормоза будут большие, на мой взгляд.
ПЗУ с функциями БИОС мы завязали на ведущий процессор. Это хорошо. Ведомым есть возможность подгружать в ОЗУ специфические ПЗУ мониторов или ОС.

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

Что мы в итоге получим: машину типа научно-бухгалтерской. Первой задачей крутится какой-то длительный расчет на "ВАСИК"-е или "Паскале", второй задачей - рисуем в графредакторе, третьей задачей - пишем статью в текстовом редакторе или убого лазием в Интернет. Есть возможность обмена данными через супервизор и переключения окон отдельных задач.
Вот такое у меня сложилось мнение. Готов услышать все замечания и словить все гнилые памэдоры.

PS. Похожая система, и довольно удобная, была у меня на 286-й машине 20МГц под ДР-ДОС (позже НОВЕЛЛ ДОС). Так что я счастливо избежал Виндовсов 3.хх и пересел только на Пень-166ММХ под Вынь-95. Переключатель задач ДР-ДОС работал не в пример лучше Виндавоза, и хотя он и не обеспечивал "оконности" но с оконностью ДОС-задач и Виндавоз глюкавил, а ДР-ДОС даже на ХТ обеспечивал многозадачность.
Хорошая заставка была у у них при загрузке:"Мы заставим Ваши компьютеры работать!"

PPS. Выигрышь в принципе получается вот в каком случае. Когда мы конкретно распараллелим задачу. К примеру - если идёт расчёт с выводом графики, то один проц считает, а второй - обслуживает графическое отображение и все операции ввода вывода. Так мне казалось в своё время, когда я продумывал "Специалист" на двух процах. Для этого надо было переписать "ВАСИК". Я его декомпильнул корректно, но дальше добавления отдельных функций дело не пошло. Я понял, что в одиночку я осилю эту задачу тогда, когда она станет даже мне не нужна.

PPPS. Всё о чем сказал Шаос - вполне справедливо, но потребует работы над собственным ПО. Я только не согласен с предложением "не читать"… читать надо всё, сравнивать и составлять собственное мнение. Особенно, если чужих мнений вокруг негусто.