Концепция управляемого данными процессора

[@promka]

Продолжайте, любопытно.
Картинки в чем рисовали?

[@moooV]

Первые две из интернета, последнюю в inkscape сделал.

[@Hellbot]

Обязательно продолжайте.

[@PiaFraus]

1)Не совсем понимаю — почему все ограничивается на однозадачности?

2) А еще интересная мысль — объединить их. То есть один процессор — фон Неймановский, второй такой. Фон Неймановский для реализации многозадачности, управлением чего-н-дь… возможно операционная система на нем. А второй трудоголик используется первым для вычислений.

[@moooV]

1) Однозадачность — результат невозможности установления соответствия между пакетами и задачами, то есть нельзя определить, какой пакет к какой задаче относится. Для этого придумали тегирование пакетов, т.е. многозадачность все-таки возможна.

2) А вот это, по идее, будет трудно, если вообще возможно: модель памяти у таких процессоров — ассоциативная, а у обычных — линейная.

[@PiaFraus]

1) Ну как мне кажется( а я тут ничего не смыслю:)) тут есть два выхода:

а) пакет может состоять из
ID задачи | ID пакета |флаг готовности | код операции и используемые пакеты в кач-ве операндовZ

б) собственно а зачем устанавливать соответствия?
Ну работает параллельно куча задач. И что? ID пакетов у каждой задачи свои… выдаются автоматом при запуске программы. ну типа как адресные ссылки на операнды в памяти сейчас.

2) ну так в этом то и весь смысл. Вот например я работаю с программой Математика. Тут эта пакетность ой как выгодна бы была. И как бы было мне здорово, если бы операционка — работала как обычно, а конкретно Математика работала бы с таким процессором.
Ну грубо говоря — все как обычно, но в момент запуска моего алгоритма на исполнение программа бы не компилила это в обычный асм код, а компилила бы ее в множ-во пакетов и скармливала бы второму процессору. Как-то так…

[@moooV]

1) Пакет там такой в реале:
Код_операции | Адр._приемника_рез.1 | Адр._приемника_рез.2 | Операнд1 | готовность1 | Операнд2 | Готовность2

>>>выдаются автоматом при запуске программы. ну типа как адресные ссылки на операнды в памяти сейчас.
Логично, но по какой-то причине этого нету.

2) В принципе возможно, но, опять же, реализаций нет. о_0

[@PiaFraus]

Надо создать свою реализацию :) ( с блекджеком...)

Кстати, неплохая тема какому-н-дь студенту для диплома, а потом, возможно, и докторской, а потом, возможно, и новой ниши на рынке

[@moooV]

Все новое — хорошо забытое старое.

[@Fiery_Ice]

Мне оно напомнило построения по цифровой микросхемотехнике. Отличная штука для определенных задач: можно к примеру сделать быструю эмуляцию какой-либо сложной цифровой схемы.

[@sylvio]

Самое интересное — про реализацию-то и пропустили.
Видимо их все еще нет по тому, что не смотря на то, что у них «высокая эффективность вычислений» в одном блоке, дешевле и проще напихать десяток не таких эффективных блоков современных процессоров и получить ту же производительность.
Физическая реализация очень много значит

[@moooV]

Про реализацию я планирую рассказать в следующем посте, как раз на примере того японского процессора.

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

Вполне возможно. А еще, может быть, из-за того, что к моменту перехода от концепции до образца, ниша была уже прочно занята, а кадры обучены на ф-Н машины.

[@SabMakc]

А я думаю, что проблема в том, что на фон Неймановской архитектуре такая архитектура эмулируется, а наоборот — нет…

[@SabMakc]

Хотя нет, вру, эмулировать и тут можно (кто нам мешает задать ф-цию, возвращающую значение, скажем байта, по заданному адресу), только будет далеко до оптимальности…

[@Wott]

На мой несколько дилетантский взгляд, процессор после парсинга комманд так и работает.
Идея состоит в том что бы поднять их уровнем выше? Чем это принципиально отличается от RISC?

[@moooV]

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

[@SabMakc]

Напомнило функциональные языки программирования (Я с Haskell работал)…

[@max7]

Лисп-машина?

[@moooV]

Неожиданно…
Посмотрел википедию про лисп-машины:

>>>В 1973 году Ричард Гринблэтт и Томас Найт, программисты лаборатории ИИ при Массачусетском технологическом институте, начали работу над тем, что впоследствии стало «проектом Лисп-машины MIT». Изначально это был компьютер, аппаратно приспособленный для выполнения некоторых основных операций Лиспа (вместо того чтобы обрабатывать их программно) в 24-битовой теговой архитектуре.

По срокам совпадает, по принципу тоже. Очень даже может быть.

[@dshalkhakov]

Я правильно понял, что такой процессор реализует редукцию графов «в железе»?

[@moooV]

По ходу, да.

[@ingeniarius]

Есть ещё одна интересная архитектура, которая даже была железно реализована…
Сетунь-70 а впоследствии ДССП

[@TVzavr]

Да, грустно все это. Вы молодец, что сами решили копнуть эту тему. Но дальше — грустно от того, что целое поколение выросло, полностью потеряв целый пласт знаний и наработок.
В СССР это направление развивалось очень серьезно. Кстати, если Вы хотите найти больше информации на эту тему, поищите data flow graph computers, или reconfigurable computing.
Насчет применений — почитайте материалы о проекте Nvidia Tesla (технология CUDA) — www.oszone.net/5141/nvidia_tesla.
Почитайте о работах академика Бурцева.
В общем, если будет интересно — могу рассказать, где такие системы применяются, в чем их реальная сила и слабости.