1. Нужна ли для развития микроэлектроники в России и смежных с ней областей инженерной деятельности ассоциация специалистов?

[byRAM 24]

1 час назад, dxp сказал:

Нету никаких 2-4 раз. С++ даёт ровно такой же оверхед как и С, а С проигрывает ассемблеру максимум 10-15%, и то смотря где и как. На современных больших процессорах ещё надо постараться написать код эффективнее компилятора: компиляторописатели знают особенности аппаратуры целевого процессора обычно получше рядового программиста...

Что-то подобное я уже слышал тут от одного сбежавшего модератора, которого здесь на форуме программировать учили. До этого его хватало только на советы почитать ХХ или ТШ. Симуляторы гнобил как мог (ну потому, что ни одного не осилил), зато свято верил в талант компиляторописателей.

Я знаю их талант: выдавать своё ... за конфетку. Да, это талант, не отрицаю: все свято верят в то, что Си- и C++-компиляторы идеально используют память МК, нет, чтоб проверить 

Изменено 11 марта, 2023 пользователем byRAM

[baumanets 12]

6 часов назад, dxp сказал:

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

 

6 часов назад, dxp сказал:

. А если у кого-то бинарник раздуло всяким мусором, так просто надо уметь пользоваться инструментом. К языку и технологии это отношения не имеет.

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

Получается занятно, мы уходим от языка, но начинаем тратить время на изучение тулов, которых меньше не станет.

Если смотреть с точки зрения фундамента, то убиваем своё время зазря, на всякие интерфейсы тулов, их гуи чекбоксы и параметры. По-дефолту "из коробки" то Borland С++ кладёт в exe шлак. 

6 часов назад, dxp сказал:

компиляторописатели знают особенности аппаратуры целевого процессора обычно получше рядового программиста

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

8 часов назад, byRAM сказал:

Не согласен, я не раз уже "выводил на чистую воду" косяки перехваленных компиляторов IAR и MPLAB X.

Так я и дизассемблировал прошивки PIC16. Много там веселых конструкций подряд типа MOVF  F,W MOVWF  F. Гоняет число компилятор туда-сюда, а чего гоняет, того сам и не знает. 🙂

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

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

Хотел я на Микроне в своё время сделать контроллер на базе PIC-ядра, но никому это нафиг не надо было, коль бабло с ОКРов идёт нескончаемым потоком, они отбрыкиваются от всего, что мешает бюджеты осваивать.

 

Трагедия нашей России такова, что изнутри контор никто никого не слушает, не воспринимает и не хочет воспринимать.

 

Изменено 11 марта, 2023 пользователем makc
политика

[_4afc_ 25]

1 hour ago, baumanets said:

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

Получается занятно, мы уходим от языка, но начинаем тратить время на изучение тулов, которых меньше не станет.

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

Вот именно это я имел ввиду говоря изучать что то типа "IAR" - студенту.

 

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

Можно изучить самому.

Другое дело, если со сменой платформы приходится менять и среду - это трата дополнительного времени, которое никто не даст и не оплатит.

 

Это же касается различных HAL библиотек.

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

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

 

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

А они эти чекбоксы и гуи ещё и регулярно перетасовывают в каждом обновлении среды.

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

[baumanets 12]

  

В 11.03.2023 в 15:36, byRAM сказал:

Я знаю их талант: выдавать своё ... за конфетку. Да, это талант, не отрицаю: все свято верят в то, что Си- и C++-компиляторы идеально используют память МК, нет, чтоб проверить 

 

В ВУЗе железячникам дают сначала программирование на языке высокого уровня "сверху", но само понятие типа данных через язык полностью  не раскрывается.

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

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

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

И получается по факту образование: транзисторный уровень изучается, логический изучается, а потом бах и сразу микроконтроллер с его языком. А что между ними - тёмный лес.

Хорошо были журналы "Хакер" с ссылками на ныне несуществующие сайты, хоть как-то пробелы образования закрывали.

В то же самое время наши преподы вечерами вместо научной работы со студентами пили пиво и играли в контру. Нулевые во всех смыслах. Бауманка.

Шестнадцатеричный редактор, дизассемблер, отладчик -  формируют у инженера-цифровика правильную картину мира.

Что касается микроэлектроники России.

В 2005-м надо было делать PIC-ядро.

В 2010-м ... AVR-ядро. Атмеги тогда только-только пошли, а об ардуино никто и не слыхал.

В 2015-м ARM легально лицензировать, сделать реинженеринг и уйти от патентов.

С 2020-х актуальны нейропроцессоры со всякими цифровыми нейронами, NPU.

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

Шёл 2022. Синтакора, Микрон feat НИИМЭ и Прогресс домучали Риску 5 с куцей ЕЕПРОМ.

Где-то в параллельной вселенной надо выпустить журнал Хакер, где крупными буквами на заголовке будет написано

Ламеры процессоростроения.

Зато ДЦ неСОЮЗ решал задачи по выстраиванию своей конторы в теле Микрона, аки паразитизм в теле живых организмов.

Чужой в теле хищника. Судя по уходу в свои офисы и производства весьма успешно.

 

 

[HardEgor 66]

В 11.03.2023 в 23:28, baumanets сказал:

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

Получается занятно, мы уходим от языка, но начинаем тратить время на изучение тулов, которых меньше не станет.

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

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

[baumanets 12]

В 11.03.2023 в 21:40, _4afc_ сказал:

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

А они эти чекбоксы и гуи ещё и регулярно перетасовывают в каждом обновлении среды.

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

+1

[_4afc_ 25]

1 hour ago, HardEgor said:

И если смотреть с точки зрения оптимизации, то компьютер нормально оптимизирует.

Вероятно нет.

Если программистов заставляют писать: X=A; if (C) X=B;

вместо if (C) X=B; else X=A;

то очевидно компилятор не в силах оптимизировать что условие С возникает редко.

И получается программист берёт на себя задачу оптимизации предсказания ошибок ветвления, да ещё и программа становится платформозависимой.

 

А вообще-то это должен делать компьютер в 2023 году.

[vov4ick 35]

42 минуты назад, _4afc_ сказал:

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

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

Си - это, со слов его создателей, переносимый ассемблер. Для большей переносимости есть Фортран (как раз для математических алгоритмов), Модула-2, Паскаль наконец.

3 часа назад, _4afc_ сказал:

А они эти чекбоксы и гуи ещё и регулярно перетасовывают в каждом обновлении среды.

Эти проблемы решают make, cmake и т.д., если вы именно про среду разработки. Параметры компиляторов практические не меняются.

5 часов назад, baumanets сказал:

Трагедия нашей России такова, что изнутри контор никто никого не слушает, не воспринимает и не хочет воспринимать.

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

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

2 часа назад, baumanets сказал:

В 2015-м ARM легально лицензировать

Миландр?

Изменено 11 марта, 2023 пользователем vov4ick

[baumanets 12]

В 12.03.2023 в 00:43, vov4ick сказал:

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

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

Хорошо говорить про Техас и Интел, соскакивая с российских реалий. Подмена объекта в дискуссии. 

В нашей стране беда и человека в частности, и руководства в общем, что ситуация видна апостериори.

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

Только у нас кладбище без прогресса. Все условия были для старта много раз, а успеха в мировом масштабе не стало. 

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

Это очевидные для любого аналитика факты, они лежали и лежат на поверхности.

Но наше чайникоголовое правительство не может по таможенным декларациям посчитать какие микросхемы в России нужны. 

Тупая задача по датасаенсу.

В 12.03.2023 в 00:43, vov4ick сказал:

Миландр?

Они ещё в 2008 году стартанули. И зафакапили хорошую идею.

https://kit-e.ru/micro/1986/

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

 

 

 

 

[HardEgor 66]

В 12.03.2023 в 05:38, baumanets сказал:

Они ещё в 2008 году стартанули. И зафакапили хорошую идею.

https://kit-e.ru/micro/1986/

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

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

 

В 12.03.2023 в 04:01, _4afc_ сказал:

вместо if (C) X=B; else X=A;

то очевидно компилятор не в силах оптимизировать что условие С возникает редко

Я же вроде по-русски написал - самые умные оптимизируют вручную. Чего непонятного?

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

[baumanets 12]

В 12.03.2023 в 02:21, HardEgor сказал:

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

Вы у них не работали, а я работал админом всех linux САПР, мне лучше знать о п-це, что там творился.

[dxp 36]

14 часов назад, byRAM сказал:

Что-то подобное я уже слышал тут от одного сбежавшего модератора, которого здесь на форуме программировать учили. До этого его хватало только на советы почитать ХХ или ТШ. Симуляторы гнобил как мог (ну потому, что ни одного не осилил), зато свято верил в талант компиляторописателей.

Я знаю их талант: выдавать своё ... за конфетку. Да, это талант, не отрицаю: все свято верят в то, что Си- и C++-компиляторы идеально используют память МК, нет, чтоб проверить 

По существу сказать ничего не можете (примерами доказывайте кривизну С/С++ компиляторов), на личности перешли. Ожидаемо.

[byRAM 24]

7 минут назад, dxp сказал:

По существу сказать ничего не можете (примерами доказывайте кривизну С/С++ компиляторов), на личности перешли. Ожидаемо.

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

[dxp 36]

12 часов назад, baumanets сказал:

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

Получается занятно, мы уходим от языка, но начинаем тратить время на изучение тулов, которых меньше не станет.

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

12 часов назад, baumanets сказал:

Вопрос во времени изучения, что ассебмлер не содержит ничего лишнего.

Ассемблер содержит кучу информации частного характера, которая за пределами конкретного процессора не пригодится. А тот же С является по сути портабельным макроассемблером, как тут уже сказали. Это очень низкоуровневая концепция, там просто неоткуда взяться большому оверхеду. И если в прежние времена ещё можно было отнести неэффективность на слабость (тупость) компилятора, то с развитием вычтехники стали появляться и оптимизирующие компиляторы (а это уже где-то вторая половина 1990-х), генерирующие код, обойти руками который было очень непросто. Я по молодости соревновался с IAR v1.40 для AVR, сам тогда пришёл от железа и ассемблера, и был сильно удивлён, что "тупая железка" (РС) генерит точно такие же инструкции, как я бы и сам написал. С этого и возник интерес к С (до этого считал его ЯП высокого уровня, куда, дескать, ему там в такие малыши как AT90S2313 и даже AT90S8515).

 

12 часов назад, baumanets сказал:

Если смотреть с точки зрения фундамента, то убиваем своё время зазря, на всякие интерфейсы тулов, их гуи чекбоксы и параметры. По-дефолту "из коробки" то Borland С++ кладёт в exe шлак. 

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

 

* * *

Соревноваться на уровне ассемблера вы можете достаточно эффективно на простых процессорах — 8/16-битниках типа AVR, MSP430, PIC. Когда перед вами дивайс вроде того же Blackfin, будете удивлены тому, какой код генерит компилятор: глядя на него в первый момент возникает мысль, что это какой-то наркоман писал — инструкции все поперемешаны. Но когда начинаете писать ровный (по-человечески чтобы выглядело) код сами, то прилетают сообщения о простое конвейера, что, де, вот это значение Р-регистра (регистр-указатель) не может быть использовано в следующей инструкции, т.к. оно не доехало до стадии Execute на конвейере, и т.п. и чтобы избежать простоя, перемещаете загрузку указателя раньше в потоке инструкций... И обнаруживаете, что начинаете писать такой же "наркоманский" код, где команды, составляющие связанную группу действий (например, чтение-изменение-запись переменной в памяти), начинают размазываться по коду и перемешиваться с командами из других групп действий. 

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

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

 

 

[Wpres_ver 7]

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