Спроектировать процессор «на коленке». Возможно ли?

zyxman>> Не все задачи удобно решаются статической иерархией классов.
pokos> Ясное дело.

С этим никто не спорит.

pokos> Мишаня, это у тебя засилие С++ подобных в мозгу, не иначе. В нормальных объектных языках все классы динамические. Более того, они являются объектами.

Нет, это не оно. Есть достаточно серъёзные работы по статическим языкам и динамическим. Динамические языки и их поддержка вовсе не убер вафель. Платить надо очень большие "деньги" за это.

Ну и не надо путать средства разработчика (статическая иерархия классов) и средства моделирования реальности (списки, структуры, классы и т.д.). Та же модель доступа по классам — это другая область, нежели доступ к членам и методам класса.

tarasv> спорят с теми кто наборот объявляет перепрограммируемую аппаратную реализацию решением очень многих (чуть ли не всех) проблем и прорывом в повышении быстродействия и функциональности компьютеров

То есть у вас нет ощущения что индустрия и мы все в тупике?

Wyvern-2>>> Вот память Виртекса4:
pokos>> Ты мне про Ерёму, а я-то тебе про Фому. Ты забываешь про топологию связей, дружище. В ПЛИСинах она - главный тормоз.
zyxman> Wyvern-2>> Регистры ЦПУ и кэш - пот ушанкой оттирают
pokos>> Чо ж не оттирать, если они работают в разы быстрее...
zyxman> Это как раз тот случай когда черепаха обгоняет зайца.
Это битва слона с китом.

pokos>>> В процессоре для этого есть регистры, не забыл? И работают они побыстрее памяти в ПЛИСинах.
Wyvern-2>> Вот память Виртекса4:
Wyvern-2>> Регистры ЦПУ и кэш - пот ушанкой оттирают
tarasv> А зачем всему этому великолепию еще и до двух штук ядер PowerPC? Ведь дело то плевое на программируемой логике сделать гораздо круче процессор чем какойто отстойный PPC на 450МГц
Ну, с великолепием нужно поосторожнее, это спецификации по максимуму. А теперь смотрим сколько стоит XC4VFX140 - $5К в розницу. Потом берем что-нибудь попроще типа XC4VFX20 ($300), смотрим параметры Цены взял с потолка на digikey.com.

А вообще наиболее продаваемый их чип это Спартан. Он сильно дешевле и процессора там нет. Предлагается использовать MicroBlaze: MicroBlaze Soft Processor 32-бит RISC, опция - FPU, MMU. Он конечно тормозит на своих 100-200Mhz, но тем не менее, Линукс на нем крутится. Места только занимает дофига.

Еще есть PicoBlaze - это простенький и маленький 8-битный контроллер на уровне PIC/AVR. Таких можно напихать много.

tarasv>> спорят с теми кто наборот объявляет перепрограммируемую аппаратную реализацию решением очень многих (чуть ли не всех) проблем и прорывом в повышении быстродействия и функциональности компьютеров
zyxman> То есть у вас нет ощущения что индустрия и мы все в тупике?

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

Mishka> ... Динамические языки и их поддержка вовсе не убер вафель. Платить надо очень большие "деньги" за это.
Более того, я даже знаю, что это за "деньги", и кому их надо платить.
Потому и предлагаю дать экземпляру по ядру. Тогда часть денег в виде мильона разыменований при доступе к методу будет не нужна - все методы и скрытые объекты сидят уже тут, в ядре, скомпилированные.

Mishka> Ну и не надо путать средства разработчика (статическая иерархия классов)...
В Smalltalk нет статических классов, поэтому там оно спутано изначально, причём, намеренно. Так же, как и в Форте, нет разницы между средой разработки и программой. И ничего, вполне себе коммерчески успешный продукт.
Вот потому-то я тебе про засилие С++ и толковал...

tarasv>> А зачем всему этому великолепию еще и до двух штук ядер PowerPC? Ведь дело то плевое на программируемой логике сделать гораздо круче процессор чем какойто отстойный PPC на 450МГц

Вот как раз таки классический процессор сделать на FPGA - оч. неблагодарное занятие. Максимум ресурсов при минимуме производительности Поэтому и впихиваются процы на кристаллы FPGA

tarasv>>> спорят с теми кто наборот объявляет перепрограммируемую аппаратную реализацию решением очень многих (чуть ли не всех) проблем и прорывом в повышении быстродействия и функциональности компьютеров
zyxman>> То есть у вас нет ощущения что индустрия и мы все в тупике?
tarasv> У меня нет ни малейшей уверенности что реконфигурируемое железо сильно поможет в увеличении общей производительности систем с учетом того что на нераспаралеливаемых задачах оно проигрывает обычным процессорам и достаточно сильно, а число хорошо распаралеливаемых задач похоже что ограниченно принципиально.

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

Но увы, ПЛИС общего назначения в ПК если и появятся то нескоро. Основная проблема ПЛИС - это слишком низкий уровень языков разработки и отсутствие стандартизации. VHDL хотя и похож внешне на Аду на самом деле скорее ассемблер. И в реале, несмотря на все красивые слова об универсальности, железо пишется и оптимизитуется под конкретный продукт с конкретным чипом, а поколения чипов меняются раз в год. Для массового рынка это неприемлимо. Еще ПЛИС должны быть надежно защищены от дурака (или хакера), поскольку реально легко спалить железо, не говоря уже о всем остальном. Это означает что прошивки для них писать смогут только авторизованные ОЕМ - тоже плохо.

С другой стороны прогресс не стоит на месте и постепенно все эти проблемы можно решить. Хороший пример это технология CUDA от nVidia Параллельное программирование и вычислительная платформа | CUDA | NVIDIA

dmitrik> С другой стороны прогресс не стоит на месте и постепенно все эти проблемы можно решить. Хороший пример это технология CUDA от nVidia Параллельное программирование и вычислительная платформа | CUDA | NVIDIA

Знал, что Cell и GPU игровых карт используются в научных расчетах, но не знал, что все зашло так далеко

Ээээхххх...где сейчас "гидроакустическая приставка Рица"

dmitrik>> С другой стороны прогресс не стоит на месте и постепенно все эти проблемы можно решить. Хороший пример это технология CUDA от nVidia Параллельное программирование и вычислительная платформа | CUDA | NVIDIA
Wyvern-2> Знал, что Cell и GPU игровых карт используются в научных расчетах, но не знал, что все зашло так далеко

Еще бы не зайти! - Это только кажется что уже все придумано и сделано и всего хватает - реально мегагерцев/мегабайтов по прежнему не хватает, особенно заметен сейчас отрыв количества собираемой информации от скорости обработки в науке - в том-же коллайдере предфильтрующий компьютер (пока на FPGA), встроили прямо в матрицу датчиков элементарных частиц, потому что просто физически тяжело затянуть в тот объем достаточно проводов чтобы без предфильтрации все выводить в ВЦ. Мало того, даже на старых ускорителях годы проходят, прежде чем в гигантских массивах информации об проведенных экспериментах находится чего-то новое.

Аналогичная ситуация в астрономии - просто элементарно собирается больше информации чем возможно обработать.

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

Wyvern-2> Ээээхххх...где сейчас "гидроакустическая приставка Рица"

А это что?

Wyvern-2>> Ээээхххх...где сейчас "гидроакустическая приставка Рица"
zyxman> А это что?

Это тут офф, а в "Морском" - мощнейшая бойня происходила...

pokos> Более того, я даже знаю, что это за "деньги", и кому их надо платить.
pokos> Потому и предлагаю дать экземпляру по ядру. Тогда часть денег в виде мильона разыменований при доступе к методу будет не нужна - все методы и скрытые объекты сидят уже тут, в ядре, скомпилированные.

Нет, это немного не туда. Статические языки позволяют выполнить некоторые предусловия, находясь в которых, ты гарантированно не должен проверять. Это позволяет сильно экономить на многих вещах.


pokos> В Smalltalk нет статических классов, поэтому там оно спутано изначально, причём, намеренно. Так же, как и в Форте, нет разницы между средой разработки и программой. И ничего, вполне себе коммерчески успешный продукт.

Ага, расскажи мне — всё-таки делали компайлер со Смолтока в соседней лабе. Как ты описываешь атррибуты в нём? Это посылка сообщения может не знать. Но аттрибуты там возникают вовсе не динамически.



In Smalltalk, Classes and instances are objects, and share some common properties. This is not true in Java, because static methods cannot have all these properties. The 'class' method give us the class of an object; and also classes can resppond to 'class' method. But...wait a moment, what is the class of Class? It is Metaclass:
Metaclass:
Metaclass instances add instance-specific behavior to various class-describing objects in the system. This typically includes messages for initializing class variables and instance creation messages particular to a class. There is only one instance of a particular Metaclass, namely the class which is being described. A Metaclass shares the class variables of its instance.

Look at this table:

#|  Expression                    -> Output

---

1 |  (Object new) class            -> Object
2 |  Object class                  -> Object class
3 |  Object class class            -> Metaclass
4 |  Object class class class      -> Metaclass class
5 |  Object class class class class -> Metaclass
5'|  Metaclass class class          -> Metaclass

Note: 5 and 5' are the same.

The trick is in the 5th expression. We should define MetaMetaclass for the 5th output. For avoiding this infinite recursion, Smalltalk overlap 'Metaclass' and 'Metaclass class'.



      






Не скажешь, откуда иерархии и правило Smalltalk overlap 'Metaclass' and 'Metaclass class' появилось? Чисто статические вещи, кстати. Но опять, не надо путать разные вещи. Да, в Форте и в Смоллтоке попытались отказаться (по разным причинам) от статического описания классов (в Форте их нет). Но вот основа-то осталась — те же методы с заголовками описываются статически.

pokos> Вот потому-то я тебе про засилие С++ и толковал...

Это не засилие, это просто не понимание того, что и зачем служит. У динмаческой части населения. Примерно, как полностью проверять машину перед каждым действием — засунули ключ в зажигание, надо выйти и проверить давление в шинах, хотим переключить скорость на дороге — надо остановиться и проверить давление в шинах.

dmitrik> Ну, все-таки число таких задач постепенно растет, в первую очередь за счет мультимедии и игр.

Количество программ, но не задач — в математическом понятии. Последнне тоже растёт, но очень медленно, как и количество задач, которые не распараллеливаются. Просто всё больше программок стали использовать алгоритмы решения (одни и те же), которые распараллеливаются.

dmitrik>> Ну, все-таки число таких задач постепенно растет, в первую очередь за счет мультимедии и игр.
Mishka> Количество программ, но не задач — в математическом понятии.

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

Кстати вот конкретный пример: где-то в последние годы одна организация заявила что посчитала все варианты шашек (64 клеточных естественно), и там были сделаны весьма любопытные выводы, что например вероятность выигрыша у белых и черных очень существенно отличается

dmitrik>>> Ну, все-таки число таких задач постепенно растет, в первую очередь за счет мультимедии и игр.
Mishka>> Количество программ, но не задач — в математическом понятии.
zyxman> В математическом понятии новых задач не появлялось уже лет 30
Ну здрасьте приехали. Из "бытовухи": крипто, компрессия, 3D графика, видео, обработка изображений... И только не надо говорить что все это было придумано еще рабами Рима В том же фотошопе дофига математики которая была сделана (алгоритмы придуманы, теоремы доказаны) в последние 10-20 лет, что есть нормальный срок от академической теории до массового применения. Это уже разбирали в научно-техническом.

Mishka> Нет, это немного не туда. Статические языки позволяют выполнить некоторые предусловия, Это и хорошо, и плохо. Для программы, один раз залитой в машину со всеми своими классами - это хорошо - убыстряет в разы. Для программы, которая может модифицироваться в процессе работы, - это плохо - она не знает, какие условия перестанут быть априори заданными через 5 секунд.

Mishka> ...Как ты описываешь атррибуты в нём? Это посылка сообщения может не знать...
Я тебе больше скажу, она и не ДОЛЖНА знать, в чём прелесть-то. Перестань мыслить в стиле "одна башка на всё", прими, что на каждый объект (а не процесс!) у тебя свой, абсолютно независимый процессор.

Mishka> Не скажешь, откуда иерархии и правило Smalltalk overlap 'Metaclass' and 'Metaclass class' появилось?
Вроде, написано понятно: "For avoiding this infinite recursion", вполне логично.

Mishka> Чисто статические вещи, кстати.
Это шаблоны в С++ чисто статические вещи. А тут специально пришлось закруглять динамические вещи в статику.
Mishka> Но вот основа-то осталась — те же методы с заголовками описываются статически.
Дык и что? Ты можешь перегрузить любой метод в любой момент. Статичность описания - это для программиста, а не для программы.

Mishka> ...Примерно, как полностью проверять машину перед каждым действием — засунули ключ в зажигание, надо выйти и проверить давление в шинах,...
Не, ты опять мыслишь в стиле С++. Проверяешь всю затронутую иерархию вместо локальной проверки прямо в экземпляре. В моём стиле это будет "хочешь засунуть ключ в зажигание, проверь, подходит ли он по размеру." Шины не нужно проверять. Они статичны. Только статичность эта возникает не при написании или компиляции, как в С++, а при загрузке объекта на ядро. Если объект меняется по каким-либо причинам, он перезагружается. Перемены эти не так часты как работа методов, поэтому особых препятствий не вижу.
Т.е. язык остаётся полностью динамическим. А run-time статический в смысле каждого отдельного экземпляра. И возможно это только потому, что все объекты независимы во время исполнения. Дерево объектов используется только во время загрузки экземпляра на ядро.

Balancer> ЭППЗУ - электрически программируемое ПЗУ
Вот это - сцупер! На этом фоне ОППЗУ просто меркнет!

Balancer>> ЭППЗУ - электрически программируемое ПЗУ
Anika> Вот это - сцупер! На этом фоне ОППЗУ просто меркнет!
Anika>

Ну, ГОСТ суров, но это ГОСТ По нему микросхемы индекса РР обозначались как ЭППЗУ. Самого этого ГОСТа навскидку не нашёл, но зато вот применение термина в другом ГОСТе: ГОСТ 30607-98. КОНТРОЛЛЕРЫ ПРОГРАММИРУЕМЫЕ СТАНОЧНЫЕ. Общие технические требования » Ресурс машиностроения. Машиностроение: новости машиностроения, статьи. Каталог: машиностроительный завод и предприятия.

«ЭППЗУ - программируемое постоянное запоминающее устройство с электрическим способом записи и стирания информации;»

Balancer> Ну, ГОСТ суров, но это ГОСТ

А в ЕСКД (что тоже ГОСТ) была такая иерархия:

Постоянное запоминающее устройство (ПЗУ) - ROM

Программируемое ПЗУ (ППЗУ) - FROM

ППЗУ с возможностью многократного программирования (РЭПЗУ) - RPROM

Репрограммируемое ППЗУ с ультрафиолетовым стиранием (РФПЗУ) - UVPROM

pokos> Шины не нужно проверять. Они статичны. Только статичность эта возникает не при написании или компиляции, как в С++, а при загрузке объекта на ядро. Если объект меняется по каким-либо причинам, он перезагружается. Перемены эти не так часты как работа методов, поэтому особых препятствий не вижу.
pokos> Т.е. язык остаётся полностью динамическим. А run-time статический в смысле каждого отдельного экземпляра. И возможно это только потому, что все объекты независимы во время исполнения. Дерево объектов используется только во время загрузки экземпляра на ядро.

Тоже вариант.
Кстати, в том-же Perl такой принцип достаточно активно применяется - например есть там шаблонные движки (например, для HTML), так у многих есть возможность не обрабатывать каждый раз шаблон, а сразу скомпилировать в быстроисполняемый код, в котором все что не меняется станет константами, а только меняющиеся фрагменты будут заменены соответствующими конструкциями.
В Форте это вообще стиль мышления..

А во всяких разных C/C++ и родственных языках/системах, оно идеологически противно, поэтому практически не применяют, кроме крайне необходимых случаев вроде SQL, который принципиально так работает (сначала компилирует запрос, потом исполняет).

pokos> Я тебе больше скажу, она и не ДОЛЖНА знать, в чём прелесть-то. Перестань мыслить в стиле "одна башка на всё", прими, что на каждый объект (а не процесс!) у тебя свой, абсолютно независимый процессор.

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

pokos> Вроде, написано понятно: "For avoiding this infinite recursion", вполне логично.

Вроде спросил понятно — как же без этого статического правило динамика не обошлась. Или не доходит?

pokos> Это шаблоны в С++ чисто статические вещи. А тут специально пришлось закруглять динамические вещи в статику.

Блин, ещё хуже. GP путать с чем-то другим. Всё ещё хуже, чем в доме Обломских.

pokos> Дык и что? Ты можешь перегрузить любой метод в любой момент. Статичность описания - это для программиста, а не для программы.

Писец просто, а не беседа. Если у метода произвольные возвращаемые данные и произвольные параметры, то как ты соотвествие установишь? По именам? А кто сказал, что семантика за ними та же?

pokos> Не, ты опять мыслишь в стиле С++. Проверяешь всю затронутую иерархию вместо локальной проверки прямо в экземпляре. В моём стиле это будет "хочешь засунуть ключ в зажигание, проверь, подходит ли он по размеру." Шины не нужно проверять. Они статичны. Только статичность эта возникает не при написании или компиляции, как в С++, а при загрузке объекта на ядро. Если объект меняется по каким-либо причинам, он перезагружается. Перемены эти не так часты как работа методов, поэтому особых препятствий не вижу.

НЕ, это ты предлагаешь так. В стат языках эта иерархия проверена однажды — на шаге компиляции. А ты хочешь всё проверять при каждом чихе.

pokos> Т.е. язык остаётся полностью динамическим. А run-time статический в смысле каждого отдельного экземпляра. И возможно это только потому, что все объекты независимы во время исполнения. Дерево объектов используется только во время загрузки экземпляра на ядро.


Не, ты не различаешь тогда динамику и статитку. Вот последнее — это чистая статика с отложенной линковкой. Никакого отношения к тому, что описал зиксман — не имеет.

Balancer> «ЭППЗУ - программируемое постоянное запоминающее устройство с электрическим способом записи и стирания информации;»
Осталось придумать аналогичные устройства с магнитным, световым, телепатическим и ещё каким-нибудь способами записи и стирания...
ЦМД не предлагать! У них же всё равно запись работает через электричество...

Anika> Осталось придумать аналогичные устройства с магнитным, световым, телепатическим и ещё каким-нибудь способами записи и стирания...

Ну, запись электрическая итак на всех (почти), а основная мысль в этой категории именно про стирание.

Ибо есть ещё и именно оптический способ стирания.

Неужели с 573РФ2/РФ5 никогда не работал?

Balancer> Ибо есть ещё и именно оптический способ стирания.
Balancer> Неужели с 573РФ2/РФ5 никогда не работал?
Да работал, конечно. Синклеры и АОНы клепаючи - как можно было иначе?
И с 2764, и с 27128 работал. Правда, не советского производства.
Про 573РФ7 слыхал, даже видел, но дела не имел. Обычно работал с корейскими "томсонами" и ГДР-скими аналогами.
А лампа-стиралка со струбцинкой и отражателем - до сих пор где-то в хламе наличествует.
Но ЗАПИСЬ-то всё равно сугубо электрическая, а?

Anika> Но ЗАПИСЬ-то всё равно сугубо электрическая, а?

Ну да. У ЭППЗУ и запись и стирание - электрические. Всё правильно