nedoPC-580 (SMP на 5 процессорах КР580ВМ80А)

[Lavr]

Касаемо мультипроцессорного кода я тебе скажу, что опыт имеется. На Сеге. :3

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

[HardWareMan]

Касаемо мультипроцессорного кода я тебе скажу, что опыт имеется. На Сеге. :3

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

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

[Lavr]

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

[HardWareMan]

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

[Lavr]

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

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

[HardWareMan]

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

[Lavr]

Спец-М в смысле многоядерный?

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

[HardWareMan]

Вот 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

[Lavr]

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

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 ... 33-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.

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

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

PPS.

Компания Hitachi также производила процессоры от Motorola, кроме того, она выпустила и собственные усовершенствованные процессоры Hitachi 6301/6303, которые имели большее количество регистров, при этом будучи совместимыми сверху вниз с оригинальными Motorola 68xx.

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

[Lavr]

2_HardWareMan

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

Все мы давно привыкли считать, что микропроцессор Z80 является 8-разрядным и, соответственно,
Spectrum тоже. И если кто-то скажет, что ZX-Spectrum может быть 16-разрядным (если только он не построен на базе процессора Z180 (64180), выпускаемом сегодня фирмой Zilog, имеющим аналогичный Z80 набор команд), то его наверняка сочтут «компьютерным неучем» (писюканцем). Но все же, попробуем поразмышлять, может ли Spectrum, построенный на базе Z80, быть 16-разрядным?

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

Но если два процессора заставить работать параллельно друг с другом, т.е. в один такт, то они образуют систему представляющую из себя как бы один микропроцессор. Таким образом, такая система будет обрабатывать 16-битную информацию (один Z80 - 8 бит, плюс второй Z80 - 8 бит).

Каким же образом обрабатывать полученную информацию, ведь каждый отдельно взятый процессор все равно обрабатывает по 8 бит? Пусть на выходах А0-А7 у первого процессора образуется сигнал 01001101 (в десятичном виде 77, по таблице символов - буква «М»), а на тех же выходах второго процессора 8-битный сигнал 11010110 (в десятичном виде 213, что соответствует оператору Merge). Это по отдельности, но т.к. оба процессора работают параллельно, то оба этих 8-разрядных байта, выданные обоими процессорами одновременно, будут представлять собой один 16-разрядный байт 0100110111010110 (или в десятичном виде 290). В данном случае выходы А0-А7 обоих процессоров, можно рассматривать как выходы А0-А15.

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

Но не потеряет ли 16-разрядный Spectrum совместимость с 8-разрядным? Нет, если по мере необходимости использовать только один процессор Z80, вместо двух, но однопроцессорные системные платы (т.е. компьютеры на базе одного процессора z80) не смогут пользоваться некоторыми аппаратными разработками и ПО для двухпроцессорных. То есть получается вполне приемлемая совместимость - сверху вниз. Что из этого всего может получиться - судите сами. Я, в свою очередь, хочу задать вопрос разбирающимся в этом деле синклеристам - возможно ли это, т.е. верно ли мое предположение?

Яков Очаковский

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

[Lavr]

2_HardWareMan

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

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

Первый проц стартует из ПЗУ, по принципу специалиста, остальные стартуют от 0 из этого общего ОЗУ, тем самым им не требуется свое ПЗУ: мастер зальет задачу, пустит второй проц, задача этого процессора прокеширует все что надо (код и данные) в свое ОЗУ, переключится и будет маслать, изредка поплёвывая результатами в выделенную область основного ОЗУ и/или забирая оттуда новые.

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

[Lavr]

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

ПедиВикия утверждает, что мы можем сильно и не выиграть...
https://ru.wikipedia.org/wiki/%D0%A1%D0 ... 1%82%D1%8C

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

Исходя из того, что мы предварительно обсудили, хотелось бы добиться
Распределённых вычислений.
https://ru.wikipedia.org/wiki/%D0%A0%D0 ... 0%B8%D1%8F

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

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

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

[Shaos]

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

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

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

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

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

[HardWareMan]

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

Первый проц стартует из ПЗУ, по принципу специалиста, остальные стартуют от 0 из этого общего ОЗУ, тем самым им не требуется свое ПЗУ: мастер зальет задачу, пустит второй проц, задача этого процессора прокеширует все что надо (код и данные) в свое ОЗУ, переключится и будет маслать, изредка поплёвывая результатами в выделенную область основного ОЗУ и/или забирая оттуда новые.

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

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

[Lavr]

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

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

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

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

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

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

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

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

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