[SM 0]

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

 

Сколько всего понаписали, а потом сказали то же, что и я. То, что программирование (программирование - это процесс написания программы. Программа - это последовательность действий, выполняемых вычислительным устройством, так, к слову, чтобы разночтений терминологии не было) скорее всего заменится функциональным описанием устройства в целом. Пусть на ФЯП, пусть на матлабе-симулинке, пусть на HDL, который скорее всего дорастет до уровня ФЯП (или наоборот, ФЯП получат то, что есть в HDL), пусть еще на чем-то другом, это не суть важно. На сегодня есть синтез программ с описаний на ФЯП, и синтез устройств с описаний на HDL. На мой взгляд - что будущее за синтезом и программ и устройств с описаний на каком-то там языке описания устройств, и это ясно не сегодняшний HDL, это HDL будущего, скорее всего что-то гибридное из ФЯП+HDL.

 

Что касается того, что HDL похож на ФЯП, а ФЯП на HDL - да это голый факт. Что такое модуль в HDL? Это некая сущность, которая выполняет определенную функцию. Что такое куча соединенных модулей - это те же функции ФЯП, где результат одних используется другими. И там и тут параллельные вычисления - и именно это является определяющим в единообразии. По большому счету одно и то же, только одно делали математики, другое железячники. Осталось им объединиться.

 

PS

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

 

PPS

Насчет амбиций у программистов - форум не весь читаете. Была тут темка про то, наука программирование или не наука, и оттуда все. Я кстати тоже был программист с амбициями :) пока до конца не разобрался в принципах HDL и ФЯП.

[Leka 0]

Мысли вслух... Пусть описаны зависимости:

a = f1(...);

b = f2(...);

c = f3(a, b );

Вопрос: когда "запускать" f3() ?

- При "готовности" или "a", или "b"?

- Или при "готовности" и "a", и "b"?

- Или... ?

При "последовательном" программировании таких вопросов не возникает.

При "параллельном" описании устройств - требуются явные ответы на подобные вопросы --> дополнительные описания, операторы, блоки, имена, ... --> текст перегружается рутиной (хорошо видно на описаниях КА).

Изменено 23 февраля, 2010 пользователем Leka

[CaPpuCcino 0]

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

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

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

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

(((я, кстати, расскажу вам ещё один интерсный момент: даже когда вы складываете в голове 1 + 2 = 3 на яблока(как этому обычно учат детей), вы выполняете обратную операцию - вы представляете сразу три яблока, а потом делите яблони на 2 группы - группа из одного яблока и группа из 2х яблок, а "один плюс два равно три" детям говорят для того чтобы они учили не цифру три, а цифру один и цифру два, т.к. мозгу проще вычленять из объекта детали, чем представлять их композицию, так что никаого последовательного действия при сложении ваш мозг не выполняет/при операциях в пределах размерности сознания. если счёт за пределами размерности, мозг образует неразрывные группы по принципу "много, меньше, больше, так же". но это уже совсем офф-топик/)))

 

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

ЗЫ: кстати, синтез с SC Менторы вернули пару месяцев назад (подозреваю, стоит ждать ответный шаг со стороны продв.Синопсиса)

Вопрос: когда "запускать" f3() ?

- При "готовности" или "a", или "b"?

- Или при "готовности" и "a", и "b"?

- Или... ?

При "последовательном" программировании таких вопросов не возникает.

вот, очередной дитя фон-Неймана

а теперь постройте поточную диаграмму этой системы и думаю вам сразу станет понятно, что это не минус, а огромный плюс параллельных (к которым в частности отн. и функциональные языки, кстати, как и HDL-и) языков программирования(в том числе с точки зрения производительности системы).

 

ну вы просто накрыли всех скептиков ракетным залпом.

к сожалению не тот квадрат

[dxp 34]

Мысли вслух... Пусть описаны зависимости:

a = f1(...);

b = f2(...);

c = f3(a, b );

Вопрос: когда "запускать" f3() ?

- При "готовности" или "a", или "b"?

- Или при "готовности" и "a", и "b"?

- Или... ?

При "последовательном" программировании таких вопросов не возникает.

При "параллельном" описании устройств - требуются явные ответы на подобные вопросы --> дополнительные описания, операторы, блоки, имена, ... --> текст перегружается рутиной (хорошо видно на описаниях КА).

На самом деле и при параллельной реализации проблем нет: если известен алгоритм, в котором четко определены зависимости - например, что f3 гарантировано должно запускаться после f1 и f2, то без проблем можно пускать параллельную реализацию и гарантировать целостность алгоритма с помощью средств синхронизации. Этот подход может дать выигрыш по скорости, т.к. f1 и f2 могут выполняться параллельно. Реализация, конечно, получается сложнее.

 

Кстати, заметьте, ничего не мешает сделать такую реализацию и без явного указания - например, если компилятору известно, что зависимостей между f1 и f2 нет, тогда он может при наличии двухядерного процессора запустить каждую функцию на отдельном ядре. Сам ЯП никак тут не ограничивает.

 

 

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

Вот только не надо навешивать ярлыки на оппонентов. Я, как уже говорил, сам от железа и программирование для меня - океан, в который я зашел по щиколотку. Но и с этой позиции видно, что HDL до глубин функциональной сложности, достигнутой в ЯП как до Луны пешком. Посмотрите хотя бы на STL - структуры данных, контейнеры, алгоритмы, итераторы, аллокаторы - обобщенное программирование прет со страшной силой. А в нашем любимом SV что? Жалкое подобие. А на уровне синтеза так вообще самый сложный объект данных - FIFO. И вся возня идет на уровне: клоки, регистры, состояния КА.., т.е. уровень абстракции очень низкий. И даже на этом уровне требуется неслабая поддержка со стороны верификации, что порождает целые методологии и требует недешевых симуляторов. А ведь STL - это только одна библиотека одного ЯП общего назначения, причем достаточно низкоуровневого.

 

Вообразите себе синтезируемый модуль, который делает синтез RTL из SV описания. Или хотя бы синтезируемый модуль симулятора а-ля QuestaSim. Вот когда такого рода задачи будут достижимы за соизмеримую цену по сравнению с ЯП, тогда и поговорим о стереотипах.

 

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

Вы меня извратили. :) Я написал:

 

(само слово алгорим и обозначает последовательность действий, приводящих к нужному результату)

 

Где тут знак равенства между "алгоритм" и "образ мышления"? Я лишь сказал, что алгоритм, как сущность, есть порождение образа мышление человека, т.к. алгоритм (даже параллельный) выражается в последовательных предложениях. А предметно-логическое мышление человека - последовательное. Вот вы же не можете мыслить одновременно о 10 вещах? Вы в каждый момент времени мыслите об одной из них, а остальные "имеются в виду" (лежат в "кэше" мозга. Кстати, реально больше 7-9 вещей одновременно в голове удерживать малореально - такова емкость "кэша" у большинства людей).

 

 

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

Не сомневался, что будете не согласны, и согласен, что спорить не будем, а точки зрения высказаны.

 

ЗЫ: кстати, синтез с SC Менторы вернули пару месяцев назад (подозреваю, стоит ждать ответный шаг со стороны продв.Синопсиса)

Очень хочется надеяться, что появятся эффективные синтезаторы SC. Руки чешутся. :)

[SM 0]

Мысли вслух... Пусть описаны зависимости:

a = f1(...);

b = f2(...);

c = f3(a, b );

Вопрос: когда "запускать" f3() ?

- При "готовности" или "a", или "b"?

- Или при "готовности" и "a", и "b"?

- Или... ?

 

Из свойств функции f3 (после ее анализа на ее области определения и области значений, которые могут быть представлены a и b однозначно следует, при каких a и b ее результат зависит только от a, только от b, или от обоих а и б, так что такого вопроса возникнуть не может. И потом эта сложность лишь для синтеза программ. Для синтеза устройства же - функция f3 может просто вычисляться всегда и постоянно, одновременно с f1 и f2.

 

И вся возня идет на уровне: клоки, регистры, состояния КА.., т.е. уровень абстракции очень низкий.

 

Вы не сравнивайте либу с языком. Это две разные вещи. Не так много людей пишет на С, не используя ни одной либы. На SV тоже можно либ (модулей)понаделать, которые будут решать те или иные задачи, которые средствами языка решаются сложно. И их делают, и самые разные. Только в С их решили постандартизировать, в SV некий разброд. Но это лишь дело времени, С значительно старее.

[dxp 34]

Вы не сравнивайте либу с языком. Это две разные вещи. Не так много людей пишет на С, не используя ни одной либы. На SV тоже можно либ (модулей)понаделать, которые будут решать те или иные задачи, которые средствами языка решаются сложно.

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

 

Но и в том, и в другом языках полно кода на собственно языке. И на SV неизбежно вылезает работа с клоком, тактами, что само по себе сразу притягивает дизайн к наиболее низкому уровню из возможных при поведенческом описании. ЯП Си тут при всей его низкоуровневости стоит значительно выше по уровню абстракции. На SV, кстати, писать верификационный код (т.е. несинтезируемый, без жесткой привязки к тактам) по трудоемкости ровно как на Си, что и обуславливает удобство его использования для этих целей. Когда HDL позволит писать эффективный код тоже без жесткой привязки к тактам, вот это будет прорыв. А традиционные HDL при этом останутся как ассемблеры - где надо, можно и руками с точностью до такта выловить, важно, что не нужно весь большой и сложный проект писать в таком стиле.

[SM 0]

Когда HDL позволит писать эффективный код тоже без жесткой привязки к тактам, вот это будет прорыв.

Он и так отчасти позволяет. Можно написать комбинаторную функцию и конвейеризировать ее средствами синтезатора - отменно работает, и вполне оптимально (retiming/pipelining). А вот то, что эффективного метода "опоследовательнить" комбинаторную функцию, по аналогии с конвейеризацией, пока нет, это факт. Но это и есть один из вопросов того, что должно быть решено в будущем.

[CaPpuCcino 0]

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

на пространстве RTL Си по сравнению с SV вообще делать нечего/ он здесь не просто хуже, он здесь вообще никак. на поле программирования SV по мощности стоит где-то в весовой категории Java, здесь не то что обычный Си, но и Си++ может немного нервно покурить в стороночке (на всякий случай напомню какими характеристиками обладает SV на этом поле: автоматическое управление памятью, защищённые хендлеры, встроеные типы данных высокого уровня абстракции - хэши, динамические массивы, многомерные статические массивы, коллекции(нетипизированные динамич. массивы), сереализация и десереализация, и вы будете смеятся банальный тип string, и очень много того, чего программерам и не снилось - например, встроенные механизмы синхронизации и многопоточности). Си++ отдыхает. единственное что остаётся за рамками SV это темплетизация, но её включат уже в следующем стандарте (я договорился ;)). ЗЫ: более того в новом стандарте будет даже аспектно-ориентированное программирование (хотя казалось бы, язык-то HDL-ный).

fork
begin:thread_1
  a=f1(x1,x2);
  @event_1;
  c=f3(a,b)
end:thread_1
begin:thread_2
  b=f2(x3,x1)
  ->event_1;
  d=f4(b,x2);
end:thread_2
join
e=f4(d,c);

вот посмотрите, готовое поточное описание для х-голового процессора. изобразите такое на Си++

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

ЗЫ: разбирай халявную тему для диссертации

[dxp 34]

каша какая-то. а Си что позволяет писать без привязки к тактам? нет. он вообще никак писать не позволяет там, где SV должен привязываться к тактам.

Действительно каша. Си позволяет писать без привязки к тактам, ибо и тактов там никаких нет и в помине. И я лишь говорил, что привязка к тактам - это опускание на более низкий уровень абстракции. И поэтому HDL - это более низкоуровневые языки по своей природе. И ничего более. Уже не первый случай неверной интерпретации моих слов.

 

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

Правда? А на самом деле это вы как раз с этого и начали, что и сподвигло меня возражать. Вам цитаты привести?

 

на пространстве RTL Си по сравнению с SV вообще делать нечего/ он здесь не просто хуже, он здесь вообще никак.

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

 

на поле программирования SV по мощности стоит где-то в весовой категории Java, здесь не то что обычный Си, но и Си++ может немного нервно покурить в стороночке (на всякий случай напомню какими характеристиками обладает SV на этом поле: автоматическое управление памятью, защищённые хендлеры, встроеные типы данных высокого уровня абстракции - хэши, динамические массивы, многомерные статические массивы, коллекции(нетипизированные динамич. массивы), сереализация и десереализация, и вы будете смеятся банальный тип string, и очень много того, чего программерам и не снилось - например, встроенные механизмы синхронизации и многопоточности). Си++ отдыхает. единственное что остаётся за рамками SV это темплетизация, но её включат уже в следующем стандарте (я договорился ;)).

С++ разорвет ваш SV в клочья по эффективности кода, это раз!

 

В С++ все вами перечисленное используется со времен, когда в умах авторов SV еще даже не было проекта этого языка. В С++, если вы не знали, используется иной подход - там не принято любое понравившееся частное решение пихать в язык и стандарт. Язык содержит только базовые средства, а весь прикладной функционал вынесен на уровень библиотек. И это правильно - это позволяет применять в каждом случае наиболее эффективное решение для этого варианта. Это является ключевым моментом при портировании (для SV вопросы портирования вообще не стоят, т.к. ниша у него четко определенная и очень узкая). И это просто дает возможность получать гибкие, расширяемые решения. Так вот, в С++ все вами описанное выше и еще очень многое другое давно не просто используется, но обкатано, вылизано и используется самым широчайшим образом - используется на уровне библиотек. Для примера посмотрите хотя бы библиотеку boost.

 

Все это стало возможным и применяется как основная стратегия расширения благодаря тому, что язык С++ сразу задумывался расширяемым - возможность создавать типы, определяемые пользователем и дает такую возможность.

 

V и SV такой возможности не дает. Поэтому в SV просто понапихали все подряд, и получаем в итоге раздутого непомерно несбалансированного монстра - все, что увидели из удачных наработанных решений (кстати, наработанных в том числе и на библиотеках С++), все пихают в стандарт. Бедный язык. Стандарт уже скоро открывать будет страшно. Будь он не HDL, где ниша, в общем-то, пуста, а ЯП, это был бы апофеоз кривости - такой ЯП сдох бы быстрее, чем окончательно появился на свет. Поначалу новшества нравились - псевдонимы типов, структуры, перечисления - все это облегчает проектирование. Но чем дальше слежу за развитием SV, тем грустнее делается. И при этом аффтары так и не доросли до того, чтобы включить в язык те же шаблоны или другой способ создавать полноценные параметризованные типы. Т.ч. гордиться тут совершенно нечем. :(

 

На уровне RTL SV очень недалеко ушел от V, и все что умеет - он умеет по наследству. Все крутые новшества - тупое заимствование из области классического программирования, причем качество языка в этом аспекте оставляет желать лучшего. И все это требует для сборки проекта и выполнения кода весьма дорогостоящих сред разработки. Кстати, не в этом ли причина приостановки развития SC? Ведь его можно гонять на бесплатном С++ компиляторе - получать полный цикл верификации, а временные диаграммы смотреть отдельными вьюверами, если возникает такая необходимость. И кому будут нужны квесты и их аналоги от синопсиса за десятки килобаксов? Получается, что ментор и синопсис, развивая SC, просто роют себе яму. Не исключено, что они это поняли и по тихому прикрыли.

 

Т.ч. как вам не обидно будет это слышать, но по факту против С++ (с его background'ом в виде библиотек) SV - это просто ясельная группа детского сада. Я не теряю надежды на возобновление работ по SC - вот где есть развернуться. И яркий пример того, что С++ со специализированной библиотекой прекрасно может поддерживать все концепции HDL - от низкоуровневых (клоки, такты) до параллельности, синхронизации по событиям, верификационных возможностей и т.п.

 

Успех SV и возник на базе того, что он без труда влез в занятое V пространство - синтез и верификация. На халяву. Ему не пришлось трудно пробивать себе дорогу и завоевывать "место под солнцем". В отличие от многих ЯП, которые делом доказали, что они адекватны жизни.

 

В заключение такая аллегория: SV против C++ (не забываем про библиотеки) в аспекте программирования (несинтезируемая часть SV) - это как спортивная тировая мелкокалиберная винтовка для стрельбы на мелким мишеням на 25 м против СВД. Она хорошо подходит только для поражении этих самых мишений в тире на указанной дальности, но вне тира она просто дорогостоящая бесполезная игрушка, которая не держит ни климатику, ни удары/вибрации, ни жесткие условия эксплуатации, ни обладает достаточной убойной дальностью. И если СВД уступает этой винтовке в тире (на ее "поле"), так это до поры, пока не применить соответствующий тюнинг - навеску патронов откалибровать, учесть параллакс прицела, возникающий из-за возвышения линии прицеливания над линией бросания и т.д. И будет попадать еще лучше.

 

P.S. Возможно, был несколько эмоционален, прошу извинить, если что не так.

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

[mikeT 0]

... здесь не то что обычный Си, но и Си++ может немного нервно покурить в стороночке (на всякий случай напомню какими характеристиками обладает SV на этом поле: автоматическое управление памятью, защищённые хендлеры, встроеные типы данных высокого уровня абстракции - хэши, динамические массивы, многомерные статические массивы, коллекции(нетипизированные динамич. массивы), сереализация и десереализация, и вы будете смеятся банальный тип string, и очень много того, чего программерам и не снилось - например, встроенные механизмы синхронизации и многопоточности). Си++ отдыхает. единственное что остаётся за рамками SV это темплетизация, но её включат уже в следующем стандарте (я договорился ;)).

 

Простите, но по-моему, у Вас очень поверхностное и примитивное представление о С++ и его возможностях.

 

автоматическое управление памятью

А зачем это встраивать в С++? Почитайте Строуструпа и многочисленные конфы по этому вопросу, этот вопрос многократно пережеван (лет 20-25). С++ позволяет делать практически любые вещи, в т.ч. и "автоматическое управление памятью" не за счет "волшебных встроенных конструкций" (которые имеют ряд серьезных недостатков), а за счет мощи самого языка, на котором можно сделать практически все что угодно (если руки правильно заточены). В качестве примера того что можно сделать, можете посмотреть boost MPL (это не автоматическое управление памятью, а по сути пара других парадигм программирования (метапрограммирование, функциональное программирование), которые могут быть применены с использованием "обычного" императивного С++). Важно! Это не "притянутые за уши" примеры, а реально используемые вещи, вот только 95% если не 98% С++ программистов врядли могут писать на таком уровне (не потому что это недоступно для их мозга, а потому что они после какого-то уровня считают "а теперь я знаю все про С++!").

shared_ptr и weak_ptr которые вместе по сути реализуют мощь типа garbage collector - это уже по теме "автоматическое управление памятью".

 

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

Снова - а зачем это встраивать в язык? Это все реализуется средствами С++, очень изящно и эффективно. Используется наверное лет 15, не меньше.

 

Банальный тип string, и очень много того, чего программерам и не снилось

Напишите это на серьезном форуме С++ :rolleyes:

 

Си++ отдыхает.

Потому что нет встроенного типа "строка"? Или "автоматического управления памятью"? Если Вы так действительно считаете, но при этом хотите серьезно разобраться в теме, то лучше поговорите со спецами по С++, только не с быдлокодерами. Рекомедую почитать хотя бы обзорно про STL, boost, loki (Александреску) и т.п.

 

вот посмотрите, готовое поточное описание для х-голового процессора. изобразите такое на Си++

 

Так С++ вроде не для описания процессоров создан. Ну а если про "процессоры", то Систем С это С++ + небольшая надстройка. "Небольшая", даже крохотная - по сравнению с той же stl+boost. И, самое главное, надстройка реализованная в виде библиотеки.

 

Что касается самой диаграммы - если понимать ее как задачу распараллеливания, то это все решается. Легко, давно отработано, широко используется. Посмотрите хоть библиотеки на С++, хоть средства ОС. Я лично этим не занимался по роду работы, но куча знакомых людей вокруг все рабочее время занимается как раз подобными задачами :rolleyes:

 

P.S.

Я не программист на С++, если что :rolleyes:

Просто:

а) использовал в работе, до уровня использования того же boost пока не дошел, но четко осознаю, что есть вещи, которые "очень круты" + "которыми я не владею"

б) есть у кого спросить

в) есть желание разобраться в вопросе, а потом делать громкие заявление типа "ХХХ - маст дай, YYY - рулез форевер". А лучше вообще "громких" заявлений не делать :rolleyes:

 

Я не фанат С++. И не утверждаю, что "С++ на все случаи жизни". Друзья пишут очень серьезный большой проект на Эрланге и говорят, что для данного проекта есть ряд преимуществ по сравнению с С++.

[SM 0]

Вообще тема была о том, куда что стремится в будущем, а развели холивар на тему что на данный момент лучше. А о чем речь - в первую очередь о том, что при описани устройств на HDL, во всех существующих, можно мыслить так же, как при функциональном программировании (хотите - наоборот - при использовании функционального программирования мыслить мерками описания устройств). Главные принципы те же. SC кстати тоже HDL, а не язык программирования, хоть он и построен на базе C++ и с использованием его синтаксиса. Что вышло в результате построения HDL на базе C++? Дало первую ласточку - синтез программы по описанию устройства. Убогий синтез, не мультитредный, когда каждый отдельно взятый модуль/функция обсчитывается своим тредом/процессором/компьютером, но все таки синтез. На сегодня это решение единственное, позволяющее с одного описания синтезировать как устройство, так и программу. Конкурентов нет - и качество решения соответствующее, синтезированная программа далека от оптимальной, а синтезаторов устройств раз-два и обчелся... Но мне кажется, что будущее именно за этим принципом. Будущее за введением в имеющиеся языки принципов функционального программирования, в HDL их вводить не надо, они там с рождения, их там развивать надо, а в С их вводят со страшной силой (SC это только один вариант, ориентиованный на синтез устройств, а есть еще много чего, не ориентированного на это). А кто такой "RTL Designer" - это тот, кто может описать устройство в целом с использованием языка описания устройств, т.е. HDL, а не при помощи программирования (описания последовательности операций вычислительного устройства). Соответственно эта профессия никуда не денется. И чем больше в языки вводится абстракции и элементов функционального программирования, тем больше программисты превращаются в RTL-дизайнеров, потому что все меньше становится программирования, и все больше функционального описания устройств как единого целого.

 

ЗЫ

А то, что библиотек разномастных для С/С++ больше, чем для V/SV - это ежу понятно, сколько лет одному, а сколько другому. И сколько народа в мире занимается программированием, а сколько описанием устройств... Тут и спорить то не уместно. Но это пока...

[Methane 0]

А то, что библиотек разномастных для С/С++ больше, чем для V/SV - это ежу понятно, сколько лет одному, а сколько другому. И сколько народа в мире занимается программированием, а сколько описанием устройств... Тут и спорить то не уместно. Но это пока...

Что пока? Это как пищевая пирамида. Тех кого едят, в 10 раз больше чем тех кто ест.

[SergeyF 0]

Библиотеки - это, конечно, хорошо. А верифицируемость(формальная) и моделирование? Я, например, не совсем понимаю, чем в C/C++ заменить тот же механизм SVA.

 

Я не зря упоминал язык esterel, родственник языка lustre. На lustre, в свою очередь, например, построена среда SCADE (Wiki, Esterel Technologies). Из нее, после формальной верификации модели из квадратиков, генерируется код на том же С, причем соответствующий DO-178B (без помощи C кодеров).

 

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

 

Если почитать предложение по стандарту Esterel, то возникает вопрос, зачем он нужен - по сути, все это есть в SV (IMHO).

 

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

 

Я не против C/C++... но тут было правильно подмечено, что программист выбирает совершенно не обязательно его - тот же C# или Java зачастую удобнее. Так почему именно C++ привязывать?

 

P.S. Предвижу через десять лет диалог:

- Как в классе <...> задействовать встроенные модули памяти для буферизации и задать порог заполнения FIFO?

- Задействуй библиотеку <...>, там нормально получается и подкрутить параметры потока можно.

- Мне для нее весь проект переписывать, по-другому никак нельзя?

[dxp 34]

Библиотеки - это, конечно, хорошо. А верифицируемость(формальная) и моделирование? Я, например, не совсем понимаю, чем в C/C++ заменить тот же механизм SVA.

 

[...]

 

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

Вы с SystemC знакомы?

 

Я не против C/C++... но тут было правильно подмечено, что программист выбирает совершенно не обязательно его - тот же C# или Java зачастую удобнее. Так почему именно C++ привязывать?

Производительность. Жаба и шарп будут едва ли быстрее имеющихся решений на HDL. Эффективный компилируемый код дает тут качественный скачок.

[SM 0]

Эффективный компилируемый код дает тут качественный скачок.

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