Easyelectronics.ru

Я за то, что язык - скорее набор инструментов, чем один инструмент, соответственно выбор делается исходя из предоставляемого оными возможностями (и ограничениями). Естественно, если используется процедурный стиль, то лучше уж Си использовать, хотя все равно можно поспорить (та же строгая типизация) - IAR, например, позволяет с одинаковым удобством использовать как C, так и C++. Сравнение "совочек-роторный экскаватор" скорее к либам можно отнести - если кто-то для небольшого дела тянет вместо "атомарной" библиотеки (например, для CRC) огромный фреймворк.

Давайте сменим тему:



C vs Java?

К слову был сегодня в книжном, в руки попалась книжечка, что-то типа "Программируем на Swift". Уже на первых нескольких страницах я мог прочитать что, к несомненным плюсам этого языка можно отнести:

1) Скорость выполнения некоторых алгоритмов на Swift может быть выше по сравнению даже с Python'ом (фантастика!)
2) Благодаря UTF кодировке в исходниках вы можете самовыражаться в именах переменных и константах еще точнее: доступны символы, иероглифы и (барабанная дробь!) емодзи. Уи-и-и-и!

Положил книжку обратно на полку. Это какой-то уже постмодернизм в программировании наступает, мое мнение.

Народ, а мож кто знает... Вот в паскале есть такая конструкция как with, и она позволяет сделать такое:

вместо

А в Си есть что нибудь похожее???

VivalzarD, ближайшее, что есть - ссылки в C++.
Определяете ссылку с именем из одной буквы и пользуетесь... Не совсем то, но уменьшает мусор в коде (и, как и with, не создаёт оверхеда)

2 aamonster
Ну да как-то так и надо видимо делать... просто думал а вдруг что-то такое же есть :-)

Я выходил из этого положения #define-ом типа

Но лишний #define как-то глаз не радовал... хотя...

Все не правы)) Будущее за фортом!)))

ИМХО дефайн, как и все макросы зло. Если имя структуры слишком долго писать, либо структура в структуре в структуре, то я определяю локальный указатель на эту структуру с коротким названием.

Так и типобезопасно и читаемо.

Если инициализация то:

struct { int a; int b } s = { 1, 2 };

Если на гоцаце подвизаемся - то т.н. designated initializers доступны.

2 siarzhuk
Не, не иницализация. С инитом все кошерно обстоит. Чисто использование в коде.

2 elisey
Дык ссылка-то в памяти место займет, или компилятор заоптимизирует??? мне ж это в основном на кодинг МК надо, а там оператива на вес золота порой.

VivalzarD, ссылки гарантированно заоптимизирует, указатели - лучше проверить, но скорей всего тоже.

Если переменная локальная, то она разместится в стеке и уничтожится после выхода из контекста. Да и 21 век на дворе, уже не нужно экономить байты, нужно время экономить)

для тех кто на сях есть такое https://plus.google.com/communities/103 ... 3092790651 если кто не знал

если приглядеться то ... навигация слева

Лично мне плюсы в эмбеде как-то не очень, но это скорее вкусовщина. Надо сказать что и си и плюсы довольно далеко от идеала, устарели.

Хотелось бы видеть что-то вроде Go.

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


В рамках армов - те же STM32F100C4T имеют 4 кб оперативки и 16 кб флеша, при этом 135 рублей за штуку. Очень часто этого хватает с головой. Если не хватает - можно взять STM32F100C8T - 8 кб оперативки и 64 кб флеша, 169 рублей за штуку. Разница в 34 рубля, чуть дороже одной поездки на метро по "тройке" в Москве. Для партии разница чуть меньше.

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


Здесь, конечно, бред. Та же Visual Studio давно поддерживает юникодные исходники (2008 точно умеет), что позволяет делать вещи типа "int переменна = 10;", но в здравом уме я бы не стал превращать все в 1С. Для мобильников, в т.ч. для iOS, часто сейчас пишут на JS, при этом приложение такое вроде гарантированно тянет за собой свой инстанс v8. Поэтому даже мелкая хрень там может весить метров 30, хотя скрипт + вьюха всего килобайт 100. Там вообще довольно часто все какое-то не здоровое на вид.
P.S. Сама по себе идея прогать на JS впоне нормальная - код на старте парсится в бинарный формат и уже он довольно быстро исполняется, это ничем не хуже, чем тот же Lua или Python. Главная проблема в алгоритмах, которые там используют, и в том, что тянут с собой каждый раз инстанс движка. Но это никто править не будет, так как это не подстегивает к продажам новых телефонов с бОльшим количеством оперативки и памяти.

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

Да, плюсы штука довольно странная, просто привыкли все к ним...

С другой стороны в классическом эмбеде маловероятно появление чего-то отличного от C и C++, во всяком случае в ближайшее время. Причина довольно простая - к существующим архитектурам и объемам проектов эти языки подходят неплохо, стимула менять их на что-то в массовом порядке нет. А реально используется обычно именно тот способ программирования, который выбран и поддерживается производителем чипа, в данной индустрии связь между производителем и разработчиком очень плотная.

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

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

Я бы скорее увязывал появление новых языков в области встраиваемых систем с ростом производительности старых, нежели появлением новых архитектур. Нынешние IoT вещи, SoC'и и прочие "граничные" устройства сложно отнести к какому либо определенному виду.

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

Однако жизнь на месте не стоит, парадигмы использования меняются (IoT, recognition era, AI, и т.д.), в связи с чем можно ожидать появления и распространения других платформ, в том числе и гораздо более производительных. И скорее всего они потребуют другого инструментария для программирования, возможно, принципиально иного.

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

В "классических" задачах управления и HMI еще долго будет доминировать "классическая" же архитектура, со свойственными ей средствами разработки. Я не думаю, что тут стоит ожидать чего-то нового, но думаю что будут более широко использоваться такие средства разработки, как Matlab.

Из ближайшего можно ожидать распространения event-driven и сервисного подхода к программированию, в связи с распространением IoT. Но это произойдет скорее на уровне библиотек и фреймворков, чем на уровне языков программирования, хотя вполне можно ожидать большего распространения во встраиваемых системах языков типа Node.js

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

Начиная с 196* г. от Р.Х. все только и говорят что вот уже на подходе новые архитектуры, а к ним надо будет использовать принципиально новые, не имеющие аналогов в мире, языки и парадигмы. И все 50 лет весь системный серьёзный софт пишется на С, а экзотика типа транспьютеров, параллелы или эльбруса грустно хлопает глазками в углу. Вот как выпускницы филфака с красным дипломом на бирже труда, только вместо диплома у них результаты синтетических тестов. И когда Нвидия выкатила свою мегауспешную CUDA - она сделала это на С. С не подходит для паралельности? Ну-ну.

CUDA не относится к С, это, так же как и OpenCL - язык группы C-like. Массово параллельные системы можно программировать и на C/C++, собственно во многих случаях именно это и происходит, например в области HPC, но это - боль. Поверьте человеку, который давно уже занимается именно массово-параллельными системами.

Большая часть таких задач сейчас пишется на Go - он именно для этого и создавался, и прекрасно себя показывает. Также много питона, встречается и Erlang.

Часто бывает так, что на разных уровнях применяются разные языки, даже в рамках одной системы. Например, программирование непосредственно ядер CPGPU ведется на C-like языках типа CUDA или OpenCL, фреймворки нижнего уровня (базовая математика) пишутся на C++ с расширениями (требуют специальных компиляторов), прикладные программисты пишут на Go, Питоне или Яве. Большая часть нейронных сетей, например, делается именно так.

Что касается новых архитектур, то они не "на подходе", а давно уже тут, просто вы что-то пропустили. У одного Intel их уже три, классический x86, MIC, и FPGA+OpenCL, мы используем все. А есть еще GPGPU. Потихоньку поднимают голову нейрочипы, и есть подвижки в квантовых компьютерах. Все это также есть и в области встраиваемых систем, и очень активно развивается. Но для людей, которые не варятся внутри этой отрасли, все это пока что не очень заметно...

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

Python для параллелизма подходит не больше чем любой другой ООП, засилье питона в машинном обучении только из-за его общей популярности и простоты - алгоритмы пишут не программисты. То что CUDA это не нативный С это понятно, даже компилятор у них другой. Но выбрали его как раз из-за совместимости с системными программистами и гибкости работы с памятью, что при CUDной модели памяти весьма важно - можно получить прирост производительности на порядок просто грамотно разместив переменные.
Сейчас популярность языка в той или иной области может радикально поменяться просто выпуском удобного инструмента, как Node.js оживил хилый джаваскрипт, а Андроид дал могучего пинка Джаве (как мне кажется, зря). Но в области операционных систем и низкоуровневых программ С пока даже не видит адекватной замены.
IoT? Недавно попробовал ESP8266 с NodeMCU (Lua). Отличная вещь, понятная, простая, консоль интерпретатора практически заменяет ОС - есть тебе и сетевой стек, и файловая система. А внутре у неё - неонктот же С.

"Хоронили С, порвали три питона".

Хилинх на днях анонсировал PYNQ - Zynq с питоновским фреймворком для перепрограммируемой логики. Свежо предание, но верится с трудом.

Процент прибыли зависит от отрасли. В HPC, например, MIC уже очень существенная часть продаж Intel. В других областях это пока не нужно.

Что касается CUDA или OpenCL, то от C там только базовый синтаксис. Сами языки, подход к программированию, компиляторы и прочее - совершенно иные, даже близко не совместимые (по причине того что внутренняя архитектура GPGPU или FPGA принципиально иная). Ближе всего к классической архитектуре находится MIC, там на низком уровне обычно связка из C++ и MPI. Для GPGPU пока что наиболее типична offload модель, там есть еще и host code, он сейчас как правило пишется на C++ с существенными расширениями. Но надо понимать, что этот код как правило сервисный, и не занимается вычислениями. Собственно, он и параллелизуется редко. Для MIC и FPGA такая модель тоже возможна, но для них это скорее legacy, постепенно отмирает.

Xylinx, кстати, недавно портировал C на FPGA. Я смотрел на то что получилось, выглядит неплохо, но смысл этого даже они пока объяснить не смогли (я имел с ними беседу на эту тему). Впрочем, у них получилось скорее что-то среднее между C и OpenCL. Intel для FPGA развивает именно OpenCL, но там принципиально другой подход - код не выполняется ядрами (ALU), их вообще нет, а растаскивается прямо в логику, насколько это возможно, и использует встроенные мультиплицирующие сумматоры, коих на чипе несколько тысяч.

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

Если вы делаете код на OpenCL для Altera FPGA, то выглядит это примерно так же, как программирование машины тьюринга. Но после компиляции (впрочем, там не совсем компиляция), получается не совсем МТ. Точнее говоря, совсем не МТ, а просто набор логики, реализующий именно те операции с данными, которые вы описали в коде. Этот набор логики - не ALU в общем понимании этого слова, это скорее похоже на аппаратный акселератор конкретных операций. То есть, если вы правильно опишете на OpenCL кодер или декодер видео, то на выходе получите что-то вроде архитектуры аппаратного кодека. Если вы описываете таким образом свою нейронную сеть, то вы получите ее прямо в FPGA, в виде внутренней структуры, а не в виде набора операций.

Дополнительно, эта логика опирается еще на "жесткие" аккумулирующие мультипликаторы, которые напоминают соответствующие блоки в ALU, но ALU не являются. Они умеют только умножать входящие данные на коэффициент, и накапливать результат.

Это, конечно, в идеале, на практике все немного сложнее, и требует достаточно качественного кода, написанного с пониманием этого процесса.

Надо сказать что даже ядро CUDA - не совсем МТ, во всяком случае полнотой МТ оно не обладает.

Когда компилятор Xilinx делает топологию FPGA из сишного кода, он поступает немного иначе - пытается скорее создать внутри FPGA именно набор ALU. Которые, в свою очередь, работают уже примерно так же, как и ядра GPGPU, то есть исполняют код. Там конечно тоже не Си, но что-то очень похожее, более похожее на Си, чем OpenCL. И с несколько большей гибкостью. Но это делается уже с определенной потерей производительности, потому что "мягкие" ядра в FPGA конечно же работают хуже, и обходятся дороже, чем "жесткие" в ASIC, CPU или GPGPU.

Если говорить про нейронные чипы, то они вообще не МТ ни в каком виде.

Если говорить про Си, то надо отличать Си как язык, и соответственно как подход к программированию, и Си как синтаксис. У обычного классического Си довольно хороший, простой и понятный синтаксис, который почти без изменений перешел очень много куда, в том числе в OpenCL, Go, Java, C#, JS и много куда еще. Но несмотря на похожесть синтаксиса, это совершенно другие языки, часто даже с другой парадигмой. Именно на этих языках и пишется на данный момент большая часть прикладных программ. Си же как таковой остался в основном в системном программировании, ну и в эмбеде, где грань между системным и прикладным ПО в данный момент почти отсутствует.

Надо сказать что синтаксис C++, в отличие от Си, как раз не прижился более нигде, на мой взгляд он довольно-таки крейзи. C++ используется в прикладном программировании довольно широко, но постепенно все-таки замещается другими языками, ближайший конкурент - Go (в принципе улучшенная версия C++).

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