Які існують деякі переваги / недоліки використання C над складанням? [зачинено]

Зараз я вивчаю техніку телекомунікацій та електроніки, і ми перейшли з асемблера до С в мікропроцесорному програмуванні. У мене є сумніви, що це гарна ідея. Які є деякі переваги та недоліки C у порівнянні зі складанням?

Переваги / недоліки, які я бачу, є:

Переваги:

• Я можу сказати, що синтаксис C набагато простіше засвоїти, ніж синтаксис Assembler.
• C легше використовувати для створення складніших програм.
• Навчання C якимось чином продуктивніше, ніж навчання асемблеру, тому що навколо C є більше розвиваючих речей, ніж Assembler.

Недоліки:

• Assembler є мовою програмування нижчого рівня, ніж C, тому це робить його корисним для програмування безпосередньо на апаратне забезпечення.
• Набагато гнучкіше натякає на роботу з пам'яттю, перериваннями, мікрорегістрами тощо.

Ось кілька відповідей щодо переповнення стека, які можуть вам допомогти (це найкраща відповідь, прийняті відповіді):

Переваги

/programming/143561/is-there-a-need-to-use-assembly-these-days (лише для користувачів 10K) або Архів

• Збірка використовується на самих ранніх стадіях завантажувача. Коли повноваження процесора на стеці недоступні, і його важко утримати компілятор C від спроб збереження речей до стеку. Більшість завантажувача, тим не менш, записується на С, як тільки буде здійснена перша рання ініціалізація.
• Збірка використовується для написання примітивів, що блокують мютекс. По суті, неможливо отримати компілятор C, щоб випромінювати вказівки щодо бар'єру пам'яті в необхідних місцях.
• Такі збори, як memset () або memcpy (), часто проводяться в зборах. Наприклад, я написав memset () з великим розкрученим циклом, який динамічно обчислює адресу гілки, щоб перейти в середину цього циклу для однієї остаточної ітерації. Процедура змінного струму генерувала б більше коду, забираючи додаткові пропуски I. Крім того, набори інструкцій CPU часто включають завантаження рядка кеша або інші інструкції, які можуть різко прискорити memcpy (), які компілятор C не використовуватиме.

Недоліки

/programming/2684364/why-arent-programs-written-in-assembly-more-often

• ASM має слабку розбірливість і насправді не піддається ремонту порівняно з мовами вищого рівня.
• Також є набагато менше розробників ASM, ніж для інших більш популярних мов, таких як C.
• Крім того, якщо ви використовуєте мову вищого рівня і нові інструкції ASM стають доступними (наприклад, SSE), вам просто потрібно оновити компілятор, і ваш старий код може легко скористатися новими інструкціями.

Приклад

Останнє повідомлення нижче - це повідомлення про переповнення стека, в якому викладений сценарій, в якому буде показаний приклад складання, швидший за С (при виконанні тієї ж функції).

/programming/577554/when-is-assembler-faster-than-c

• Програмувати C простіше, порівняно з Асамблеєю. Є очевидні причини, які не варто повторно проводити.

• Будучи простішим у використанні, C дозволяє швидше писати програми. Зазвичай ці програми також простіше налагоджувати та легше обслуговувати. Крім того, простіше керувати великими, складними програмами в С.

• Часто код, створений компілятором, настільки ж хороший (з точки зору швидкості та ефективності), як і рукописний асемблер - якщо не краще.

• C досить дивно низький рівень, і рідко ви хочете піти набагато нижче. Маючи доданий шар абстракції рідко буває поганою справою.

• Коли вам потрібно опуститися нижче, ви можете скористатися збіркою, інакше ви можете використовувати C.

• Ви можете написати Асамблею в С-коді, але не С у Асемблерному коді.

Програма змінного струму може бути складена для різних мікропроцесорних архітектур.

ми перейшли з асемблера до С в мікропроцесорному програмуванні. У мене є сумніви, що це гарна ідея

Не бійтеся, більше ніхто не розробляє нові програми в 100% асемблері. На сьогоднішній день C можна використовувати навіть для найдрібніших, найсміливіших 8-бітових архітектур. Однак знання деяких асемблерів робить вас значно кращим програмістом на C. Крім того, у програмі завжди є якась невелика деталь чи дві деталі, які потрібно записати в асемблері.

Я можу сказати, що синтаксис C набагато простіше засвоїти, ніж синтаксис Assembler.

Так, звичайно, синтаксис простіше. Однак вивчення всієї мови С з усіма прикрими деталями набагато складніше, ніж вивчення всіх деталей конкретного асемблера. С - набагато більша і ширша мова. Але знову ж таки, можливо, вам не потрібно буде вивчати всі деталі.

C легше використовувати для створення складніших програм.

Дійсно, C забезпечує механізми модульного проектування програми, такі як інкапсуляція та локальні області застосування / локальні змінні. А C має стандартну бібліотеку, плюс величезну кількість ресурсів, написаних протягом останніх 30 років. І найголовніше, що C портативний.

Навчання C якимось чином продуктивніше, ніж навчання асемблеру, тому що навколо C є більше розвиваючих речей, ніж Assembler.

C має безліч заздалегідь виготовлених функціональних можливостей, бібліотек та ресурсів, тому буде менше переосмислення колеса. Але крім цього, ваше твердження є суб'єктивним. Я вважаю, що це питання особистої переваги.

Наприклад, я досвідчений програміст на C, періодично програмуючи C ++. Я вважаю себе набагато менш продуктивним в C ++, тому що я не знаю цієї мови так добре, як я знаю C. Але тільки тому, що я відчуваю це таким чином, це не обов'язково означає, що програмування на C є більш продуктивним, ніж програмування на C ++. Досвідчений програміст на C ++, безумовно, матиме протилежну думку.

І до "продуктивних" є багато аспектів. Дуже важливим аспектом є час обслуговування, а особливо час, який потрібно на виправлення помилок, викликаних технічним обслуговуванням. C набагато простіше в обслуговуванні, ніж асемблер.

Assembler є мовою програмування нижчого рівня, ніж C, тому це робить його корисним для програмування безпосередньо на апаратне забезпечення.

Програмування апаратних засобів може здійснюватися безпосередньо на будь-якій мові. Єдине, що ви не можете зробити на C - це доступ до покажчиків стеків та регістрів стану тощо, самого ядра процесора. Тож якщо під апаратним програмуванням ви маєте на увазі розмову з власним процесором, то так, асемблер дозволяє трохи більше C. Якщо ви маєте на увазі доступ до зовнішнього обладнання, то асемблер не має ніякої користі над C. Але, можливо, недоліки, оскільки це важче написати загальний код асемблера для певного зовнішнього пристрою, ніж загальний код C.

Набагато гнучкіше натякає на роботу з пам'яттю, перериваннями, мікрорегістрами тощо.

Це неправильно. C дозволяє вам зробити все це теж, хоча вам, можливо, доведеться покладатися на специфічний для компілятора код C, такий як ключове слово переривання.

Зрештою, вам потрібно знати обидві мови для програмування MCU з акцентом на C.

Залежно від того, наскільки вбудованим потрібно зайти, C збирається створювати великі, повільні програми. Що помітно збільшить вартість тієї частини продукту. Це може бути крапля океану для загального продукту або може докорінно змінити продукт. Так, дехто може сказати, що зусилля з розробки та обслуговування програмного забезпечення дешевші, знову ж таки це може бути правдою чи помилкою, якщо це глибоко вбудоване і спрямоване на частину, що мала потужність, невелика і недорога, ви не говорите про багато коду. Цей код здебільшого специфічний для цього постачальника або того чи іншого чіпа, тому, перебуваючи в C, має нульові переваги при переносимості, вам все одно потрібно переписати перед кожною ціллю. З серією cortex-m від ARM ми тільки починаємо мати можливість конкурувати з C asm, не те, що люди не використовували C або інші мови вищого рівня у своїх вбудованих продуктах,

Дебати C проти ASM, в професійному плані, завжди зводиться до того, щоб написати це на C та використовувати ASM там, де ви можете це виправдати. І ви можете це виправдати. У вбудованому світі є продуктивність і розмір.

Ви повинні включити ціль у цю дискусію. Хоча багато хто використовує C з Microchip (старші фотографії, а не pic32, що є мипом) величезною ціною, це жахливий набір інструкцій для компіляторів, дуже навчальний та цікавий набір інструкцій, але компілятор недружній. msp430, avr, arm, thumb, mips, все добре для компіляторів. 8051 також поганий.

Навіть більше, ніж мова інструменти. Окрім тих випадків, коли турбота про розробку та управління кодом є аргументом, вам потрібні інструменти, щоб бути там сьогодні та завтра. Наявність єдиного інструмента джерела, навіть включаючи єдиний мод gcc, який управляється однією групою, є ризиковим з точки зору бізнесу. Ви, швидше за все, знайдете більше одного асемблера, і кожен, хто гідний бути в цій команді, може зібрати асемблера у вихідні дні (доки ви не пишете збірку, це директива ghee whiz і макрос задоволена). І для ASM, і для C ви хочете використовувати інструменти з відкритим кодом (або власні інструменти в домашніх умовах), де ви маєте більше шансів, навіть якщо це означає використовувати віртуальну машину для запуску 10-річного Linux-дистрибутива, щоб мати доступні інструменти для термін служби виробу.

Підсумок, знову ж таки, використовуйте / вивчайте / навчайте і C, і ASM, почніть з C і використовуйте asm там, де ви можете це виправдати.

Для складання існує неминучий компроміс між технічним обслуговуванням та продуктивністю. Ви можете легко збирати / читати / підтримувати збірку, або ви можете написати високооптимізований код; але не можна робити обох.

Для C компроміс не зовсім зникає, але він набагато менш помітний - ви можете легко писати / підтримувати C, який досить добре оптимізований.

Прекрасний програміст з мовної збірки зможе бити компілятор майже весь час, але більшу частину часу вони навмисно вирішать замість цього легко писати / підтримувати код; і тому відмінний програміст з мовної збірки буде бити компілятором більшу частину часу.

Розумним способом є використання як збірки, так і C (замість лише складання або тільки C) - наприклад, використання C для частин коду, де відмінний програміст мови асемблера вирішив би записати підтримуваний / повільний код та використовувати збірку для залишок (де "дуже оптимізований і важко підтримувати" фактично виправданий).

1. Відносно добре для ефективності програмування.
2. Програмувати легко за допомогою мови c, а не за допомогою монтажу.
3. Мова C може бути досить швидкою, ніж мова збірки.
4. Можна складати збірку в коді С, але не в С в складі коду.