Как говорил один убеленный сединами коллега: "Си - лучший макроассемблер"
На самом деле если осваивать сначала ассемблер, то Си вообще не страшный.
С - хуета, по сравнению с С++, серьезно. С простой, как пробка. Вы, блядь, почитайте последних несколько стандартов С++ - охуеете, сколько всего туда завезли.
Тут, скорее, речь об отсутствии всякого "синтаксического сахара", о прямой работе с памятью (никаких смарт-поинтеров, детишки!) и необходимости знать архитектуру железа или платформы, под которые пишется код. Порог входа в сам язык низкий, а вот порог входа в разработку полноценного софта на нём...
Ну, на плюсах тоже разрабатывается довольно низкоуровневый софт.
Так-то правильно юзать смарт-поинтеры - это тоже наука. Гораздо проще нахуярить голых указателей, и забить на утечки. Хоть С++ и называют по старинке "С с классами", но по факту, хороший и стройный код на последних плюсах имеет гораздо более высокий порог понимания, чем на С.
Ты даже русский язык освоить не осилил
Мне нихуя, кстати, не ясно, в чём проблема освоить си, или ассемблер.
Что то, что другое - очень, очень простые вещи, и освоить их нетрудно.
На них писать что-то крупное трудно. Именно из-за очень низкого уровня абстракции - код будет изобиловать(а в асме - состоять из) технических нюансов, в которых порой непросто проследить логику и понять структуру.
Но сами языки ну очень простые.
Что то, что другое - очень, очень простые вещи, и освоить их нетрудно.
На них писать что-то крупное трудно. Именно из-за очень низкого уровня абстракции - код будет изобиловать(а в асме - состоять из) технических нюансов, в которых порой непросто проследить логику и понять структуру.
Но сами языки ну очень простые.
Потому что архитектуру перед Асемблером учить нужно
Да и перед C тоже полезно, глядишь и по проще было бы осваивать
Да даже если на джаве, или на питоне.
Потому что те, кто не понимают, как оно работает "в нутрях", порой пишут такую дичь, от которой жопные волосы впиваются в кожу. Когда одним, совершенно не необходимым выебоном, могут добавить прогрессирующую просадку по производительности, просто не понимая, что они делают.
Потому что те, кто не понимают, как оно работает "в нутрях", порой пишут такую дичь, от которой жопные волосы впиваются в кожу. Когда одним, совершенно не необходимым выебоном, могут добавить прогрессирующую просадку по производительности, просто не понимая, что они делают.
зачем тратить 100 лет для написания кода на асме когда тот же код можно написать на си за 1 день?
смотря что писать. на асм можно делать очень производительные параллельные вычисления. все возможные математические функции на нем получаются очень быстрыми, особенно если использовать векторные регистры.
я, с трудом освоивший алфавит
Высокоуровневые языки с поддержкой LLVM
Нах он нужен?
Драйверы.
Драйверы? зачем? Можно пример где без асма нельзя или очень выручает что си просто сосёт?
А то даже на микроконтроллеры без ОС, на их голое железо можно писать на чистом обычном Си если всё таки почитать эту чёртову документацию на gcc и освоить ld файл и секции компилятора. Аналогично можно оптимизировать по размеру без асма вообще. Впихнуть в 4к загрузчик с урезанным TCP и принтфом вполне реально для 32 битной машины. (я даже статью про это на хабре писал).
Может всё-таки для понимания как оптимизировать для игр, и тяжолых вычислений? разработки новых компиляторов и прочий хайтек?
Хотя в последний раз я ускорял нейросетку под рядовой не топовый десктопный CPU, на обычном Си, даже виноградную оптимизацию матриц не заюзал (да были тупо 2д циклы) и всё заработало с скоростью 100 гига умножений в сек. Блин что я не так делаю?
А то даже на микроконтроллеры без ОС, на их голое железо можно писать на чистом обычном Си если всё таки почитать эту чёртову документацию на gcc и освоить ld файл и секции компилятора. Аналогично можно оптимизировать по размеру без асма вообще. Впихнуть в 4к загрузчик с урезанным TCP и принтфом вполне реально для 32 битной машины. (я даже статью про это на хабре писал).
Может всё-таки для понимания как оптимизировать для игр, и тяжолых вычислений? разработки новых компиляторов и прочий хайтек?
Хотя в последний раз я ускорял нейросетку под рядовой не топовый десктопный CPU, на обычном Си, даже виноградную оптимизацию матриц не заюзал (да были тупо 2д циклы) и всё заработало с скоростью 100 гига умножений в сек. Блин что я не так делаю?
Ассемблер нужен для магии типа принтануть стек вызовов, или какой-то умный дебаг напоить, или состояние проца вытянуть.
Благодаря ассемблеру лучше понимаешь что такое указатели и как они работают, можешь всякую магию с памятью делать. Ну и вообще просто банально глубже понимаешь что там под капотом крутится.
а вот с этим согласен, но понимать надо учась ассемблер ЧИТАТЬ а не пытаясь на нём писать. Против написания на асме я и выступаю - почти всегда это проявление банального не желания изучить компилятор и линкер обычного си. Более того глобальная оптимизация на си в большинстве случаев сработает заметно лучше чем твои потуги на асме. На асме ты сможешь соптимизировать локально, а в целом, глобально выйдет хуже. Си же сожмёт эффективно весь код целиком, местами может наделает лишних пересылок регистров и тд но в целом чтоб дотянуть до уровня Си на асме надо потратить в сотни раз больше времени при этом получишь кучу побочек и лапшу не предназначенную для правок вообще. Такой супер оптимальный асм код можно будет только выкинуть на помойку в случае необходимости правок уровня сложности чуть выше тривиального (не ну я не спорю, перекинуть порт ножку или сменить номер таймера ты сможешь).
И самое главное: асм читать нужно уметь для того чтоб лучше понимать Си или иной компилятор. Это очень важно. Но проблемма в том что современные компиляторы дают такой код что навык ручного написания на асме можно выкинуть на помойку и начать учить асм заново. Особенно это важно для актуальных 16-32 битных и АРМ платформ.
Т.е. получается что когда люди пытаются изучить асм написанием на нём чего-то то они: 1. не изучают Си компилятор и просто поливают его грязью - нет навыка работы с си на уровне выше начального, 2. не могут потом почитать вывод си компилятора на -О2 и выше.
Зачем зря тратить время? лучше уж инлайн асм, инстринки, MMX, SSE ручную оптимизацию для OpenCV например и тд бы учили.
И самое главное: асм читать нужно уметь для того чтоб лучше понимать Си или иной компилятор. Это очень важно. Но проблемма в том что современные компиляторы дают такой код что навык ручного написания на асме можно выкинуть на помойку и начать учить асм заново. Особенно это важно для актуальных 16-32 битных и АРМ платформ.
Т.е. получается что когда люди пытаются изучить асм написанием на нём чего-то то они: 1. не изучают Си компилятор и просто поливают его грязью - нет навыка работы с си на уровне выше начального, 2. не могут потом почитать вывод си компилятора на -О2 и выше.
Зачем зря тратить время? лучше уж инлайн асм, инстринки, MMX, SSE ручную оптимизацию для OpenCV например и тд бы учили.
Я бы поспорил. Я соглашусь что пытаться всё подряд писать на асме - так себе затея. Но чтобы вообще не пытаться писать на асме и не иметь навыка - не соглашусь. Это как с естественными языками, навык чтения и навык написания - разные вещи, и один дополняет другой для лучшего понимания языка. Фактически ты просто сходу хейтишь асм не рассматривая вообще никаких вариантов, так тоже нельзя.
вот например только на си смена контекста: передача управления из загрузчика основному коду с установкой стека.
https://github.com/Mirn/Boot_F4_fast_uart/blob/master/src/sfu_commands.c#L229
начиная с 229 строки.
использовал либу CMSIS от производителя арм ядра - она есть на всех современных арм мк. и большая часть инстринков этой либы инлайнится в одну команду.
раскрутить стек тоже можно только на си
если передаются часть параметров экзепшена в регистрах то только тогда желательно впендюрить пару команд на асме (не все клоны gcc умеют в ручную привязку регистров и переменных без багов).
но прерывание экзепшена обычно есть во всех нормальных либах и делать его не нужно.
https://github.com/Mirn/Boot_F4_fast_uart/blob/master/src/sfu_commands.c#L229
начиная с 229 строки.
использовал либу CMSIS от производителя арм ядра - она есть на всех современных арм мк. и большая часть инстринков этой либы инлайнится в одну команду.
раскрутить стек тоже можно только на си
если передаются часть параметров экзепшена в регистрах то только тогда желательно впендюрить пару команд на асме (не все клоны gcc умеют в ручную привязку регистров и переменных без багов).
но прерывание экзепшена обычно есть во всех нормальных либах и делать его не нужно.
Под микроконтроллеры очень нужен
Чтобы запихать сколько-нибудь функциональную прошивку в камень с 1кб памяти
Чтобы запихать сколько-нибудь функциональную прошивку в камень с 1кб памяти
как то на спор сделал ножкодрыгательную прогу:
на голом си
на обычный не тюнингованный на мк gcc, который был скаченный с арм ком а не от производителя контроллера
размером в пол сотни байт
оно компилировалось и работало на любых клонах gcc под любые арм микроконтроллеры (не использовало узкую специфику или недок функции)
код был читаемым и очевидным.
код мог поправить любой ардуинщик
потрачено было минут пять на разработку
что я делаю не так?
на голом си
на обычный не тюнингованный на мк gcc, который был скаченный с арм ком а не от производителя контроллера
размером в пол сотни байт
оно компилировалось и работало на любых клонах gcc под любые арм микроконтроллеры (не использовало узкую специфику или недок функции)
код был читаемым и очевидным.
код мог поправить любой ардуинщик
потрачено было минут пять на разработку
что я делаю не так?
>> ножкодрыгательную прогу
это
я писал: сколько-нибудь функциональную прошивку
на асме дрыгать ножкой заняло бы два байта и конфиг для счётчика
это
я писал: сколько-нибудь функциональную прошивку
на асме дрыгать ножкой заняло бы два байта и конфиг для счётчика
Отдельные, очень узкие по производительности, места драйвера, со специфическими особенностями железа.
Компилятор просто не знает, как оптимально скомпилировать определенный код, он делает "в общем случае", а производитель знает про железо то, чего не знает компилятор.
Компилятор просто не знает, как оптимально скомпилировать определенный код, он делает "в общем случае", а производитель знает про железо то, чего не знает компилятор.
со специфическими особенностями железа в 99% случаев можно отмахаться тюнингом си кода, аттрибутами или ручной разбивкой на объектники чтоб компилятор не оптимизировал лишнее и отключение LTO. Но в оставшиеся случи да надо лезть, но это очень редкий кейс! Часто помогают ещё встроенные в GCC __builtinХХХХ функции. Даже потактовую работу на GCC можно сделать стабильной при любых глобальных настройках проекта вне зависимости от глубины оптимизации.
Просто надо изучать и копать доку на линкер ;)
Я так например вполне спокойно делал на голом Си такой кейс: разблокировка - когда надо записать ключ А, строго через N тактов записать ключ В в регистр.
Но если глючит железо то есть стопятьсот вариантов объода, от голого ножкодрыгания напрямую или через DMA до использования CPLD если сотни мегагерц и до FPGA если дрыгать ножками надо быстро (гигагерцы). Кстати HDL код всегда одинаково работает на любой платформе вплодь до такта и его уровень куда ниже асма ;)
Просто надо изучать и копать доку на линкер ;)
Я так например вполне спокойно делал на голом Си такой кейс: разблокировка - когда надо записать ключ А, строго через N тактов записать ключ В в регистр.
Но если глючит железо то есть стопятьсот вариантов объода, от голого ножкодрыгания напрямую или через DMA до использования CPLD если сотни мегагерц и до FPGA если дрыгать ножками надо быстро (гигагерцы). Кстати HDL код всегда одинаково работает на любой платформе вплодь до такта и его уровень куда ниже асма ;)
А тут уже каждый дрочит как он хочет.
Описанные тобою пляски с бубном вот ничуть не проще банальных ассемблерных вставок.
Ебстественно, именно вставок, а не целиком все на асме.
Описанные тобою пляски с бубном вот ничуть не проще банальных ассемблерных вставок.
Ебстественно, именно вставок, а не целиком все на асме.
к вставкам претензий не имею, имею претензии когда всё пишется на асме особенно тривиальщина типа парсинга командной строки.
И ненавижу когда вставки на асме ломают логику работы например тем что портят содержимое флагов или non volatile register причём самое гадство что порят очень хитро, оно глючит изредко и сложно отлаживаемое а отлаживать часто мне. А происходит это потому что нередко те кто кидается в крайность только асма считают Си и прочие языки считают гавном, учиться стандартам, соглашениям не хотят и даже доку ниразу не читали на компилятор gcc.
И ненавижу когда вставки на асме ломают логику работы например тем что портят содержимое флагов или non volatile register причём самое гадство что порят очень хитро, оно глючит изредко и сложно отлаживаемое а отлаживать часто мне. А происходит это потому что нередко те кто кидается в крайность только асма считают Си и прочие языки считают гавном, учиться стандартам, соглашениям не хотят и даже доку ниразу не читали на компилятор gcc.
По мне ассемблер легче си, там все понятно, лаконично и без ненужных конструкций. Вообще люблю ассемблер.
Чем бы дитя не тешилось лишь бы не ассемблером.
На асме прогал в каком-то "трансе", через два часа после выхода из которого уже не мог понять, как моё же "творение" работает, особенно - почему оно правильно работает...
Чтобы написать коммент, необходимо залогиниться
это ассемблер боиться его