Чому програми не пишуться в Асамблеї частіше? [зачинено]

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

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

Можливо, це тому, що програмування монтажу є зовсім іншим, ніж HLL, і тому вимагає різного мислення, методів і способів, що робить програму для незнайомої програми дуже незручною, і тому дає їй свою погану назву для написання програм в.

Якщо портативність не є проблемою, то насправді, що C матиме над хорошим асемблером, таким як NASM?

Редагувати: Просто щоб вказати. Коли ви пишете в зборах, вам не доведеться писати лише в кодах інструкцій. Ви можете використовувати макроси та процедури та власні конвенції, щоб зробити різні абстракції, щоб зробити програми більш модульними, більш доступними та легшими для читання. Ось тут і знайомляться з тим, як написати гарну збірку.

ASM має слабку розбірливість і насправді не досяжна для порівняння з мовами вищого рівня.

Також є набагато менше розробників ASM, ніж для інших більш популярних мов, таких як C.

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

Що робити, якщо наступний процесор має вдвічі більше регістрів?

Зворотним питанням було б таке : Яку функціональність надають компілятори?

Я сумніваюся, ви можете / хочете / повинні оптимізувати свій ASM краще, ніж gcc -O3можете.

Чорт, я компілятор.

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

PS О, до речі, ви не використовували половину написаного вами коду. Я зробив вам послугу і викинув її.

Я написав прокладки асемблера для мікросхем 6502, Z80, 6809 та 8086. Я перестав це робити, як тільки компілятори C стали доступними для платформ, до яких я звертався, і одразу стали принаймні в 10 разів більш продуктивними. Більшість хороших програмістів використовують інструменти, якими вони користуються з раціональних причин.

Я люблю програмування на мові асемблера, але потрібно більше коду, щоб зробити те саме, що і в мові високого рівня, і між рядками коду та помилками існує пряма кореляція. (Це було пояснено десятиліттями тому у "Міфічному людині-місяці" .)

Можна розглядати C як "збірку високого рівня", але зробіть кілька кроків вище цього, і ви перебуваєте в іншому світі. У C # ви не замислюєтесь над тим, щоб написати це:

foreach (string s in listOfStrings) { /* do stuff */ }

Це було б десятки, може бути, сотні рядків коду в зборі, кожен програміст, що реалізує це, би по-різному підходив, і наступний чоловік, який прийде разом, повинен був розібратися в цьому. Тож якщо ви вважаєте (як і багато хто), що програми написані в першу чергу для того, щоб інші люди могли читати, складання є менш читабельним, ніж типовий HLL.

Редагувати: я накопичив персональну бібліотеку коду, що використовується для загальних завдань, та макросів для реалізації керуючих С структур. Але я потрапив у стіну в 90-х, коли GUI стали нормою. Занадто багато часу було витрачено на речі, які були звичайними.

Останнє завдання, яке було у мене, коли ASM було важливим, було кілька років тому - написання коду для боротьби зі шкідливим програмним забезпеченням. Немає користувальницького інтерфейсу, тому все це було цікаво, без набряку.

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

швидкість програми.

Так, при складанні ви можете вручну настроїти свій код, щоб використати кожен останній цикл і зробити його максимально швидким, ніж це можливо фізично. Однак у кого є час? Якщо ви пишете не зовсім дурну програму C, компілятор зробить дійсно хорошу роботу з оптимізації для вас. Можливо, зробиш принаймні 95% оптимізацій, які б ти робив вручну, не турбуючись про те, щоб слідкувати за будь-якою з них. Тут безумовно є правило 90/10, де останні 5% оптимізацій в кінцевому підсумку займають 95% вашого часу. Так навіщо турбуватися?

Якщо середня виробнича програма має, наприклад, 100k рядків коду, а кожен рядок - це приблизно 8-12 інструкцій асемблера, це буде 1 мільйон інструкцій асемблера.

Навіть якщо ви могли написати все це вручну на гідній швидкості (пам’ятайте, його в 8 разів більше коду, який ви повинні написати), що станеться, якщо ви хочете змінити частину функціональності? Розуміння чогось, що ви написали кілька тижнів тому, з цих мільйонів інструкцій - це кошмар! Ні модулів, ні класів, ні об'єктно-орієнтованого дизайну, ні рамки, ні нічого. А кількість подібного вигляду коду, який вам доведеться написати навіть для найпростіших речей, у кращому випадку вражає.

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

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

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

Однак, як насправді писати багато коду в асемблері, є кілька причин, що це мало що зроблено.

• Просто немає (майже) потреби. За винятком чогось на зразок дуже ранньої ініціалізації системи та, можливо, кількох фрагментів асемблера, прихованих у функціях C або макросах, весь дуже низький рівень коду, який колись може бути записаний у асемблері, без особливих труднощів може бути записаний на C або C ++.

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

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

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

Як розробник, який проводить більшу частину свого часу у вбудованому світі програмування, я стверджую, що збірка - це далеко не мертва / застаріла мова. Існує певний рівень кодування, близький до металу (наприклад, у драйверах), який іноді не може бути виражений настільки точно або ефективно мовою вищого рівня. Майже всі наші апаратні інтерфейсні процедури ми пишемо в асемблері.

При цьому цей збірний код обернутий таким чином, що його можна викликати з коду С і розглядатись як бібліотека. Ми не пишемо всю програму в зборі з багатьох причин. Перше і головне - це портативність; наша база коду використовується для декількох продуктів, які використовують різні архітектури, і ми хочемо максимально збільшити кількість коду, який можна поділити між ними. Друге - це знайомство розробників. Простіше кажучи, школи не вчать складання, як раніше, а наші розробники набагато продуктивніші на C, ніж у складанні. Крім того, у нас є широкий спектр "додатків" (таких як бібліотеки, налагоджувачі, інструменти статичного аналізу тощо), доступних для нашого коду С, які недоступні для коду мови складання. Навіть якби ми хотіли написати програму з чистою збіркою, нам це не вдасться, оскільки декілька критичних апаратних бібліотек доступні лише як C libs. В одному сенсі це проблема з куркою / яйцями. Людей відганяють від збирання, оскільки для нього не так багато бібліотек та інструментів розробки / налагодження, але бібліотеки / інструменти не існують, оскільки недостатньо людей використовує збірку, щоб гарантувати зусилля по їх створенню.

Зрештою, є час і місце для майже будь-якої мови. Люди використовують те, що їм найбільше знайоме і продуктивно. Напевно, завжди знайдеться місце в репертуарі програміста для збирання, але більшість програмістів виявлять, що вони можуть писати код мовою вищого рівня, що майже так само ефективно за набагато менший час.

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

Тож, що ви, по суті, говорите, це те, що при кваліфікованому використанні складного асемблера ви можете зробити свій ASM-код все ближче і ближче до C (або в будь-якому разі іншої мови низького рівня власного винаходу), доки з часом ви просто не будете просто настільки продуктивні, як програміст на С.

Це відповідає на ваше запитання? ;-)

Я не кажу про це складно: я програмував за допомогою саме такого асемблера і системи. Ще краще, що асемблер міг націлити віртуальний процесор, а окремий перекладач склав вихід асемблера для цільової платформи. Так само, як і у випадку ІФ ЛЛВМ, але в ранніх формах це було раніше, ніж приблизно 10 років. Так з'явилася портативність, плюс можливість писати підпрограми для конкретного цільового асемблера, де це потрібно для ефективності.

Писання за допомогою цього асемблера було таким же продуктивним, як і C, і порівняно з GCC-3 (що було приблизно до того часу, коли я був залучений), асемблер / перекладач створив код, який був приблизно таким же швидким і зазвичай меншим. Розмір був дійсно важливим, і в компанії було мало програмістів, і вони були готові навчити нових наймань новій мові, перш ніж вони могли зробити щось корисне. І у нас було резервне копіювання того, що люди, які не знали асемблера (наприклад, клієнти), могли писати C і компілювати його для одного і того ж віртуального процесора, використовуючи ту саму умову виклику тощо, щоб він чітко з’єднувався. Тож відчувалося, що це маргінальна перемога.

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

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

Збірка не переноситься між різними мікропроцесорами.

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

Технологія поєднується і робить речі простішими та доступнішими.

EDIT - щоб перестати ображати людей, я видалив певні слова.

Чому? Простий.

Порівняйте це:

        for (var i = 1; i <= 100; i++)
        {
            if (i % 3 == 0)
                Console.Write("Fizz");
            if (i % 5 == 0)
                Console.Write("Buzz");
            if (i % 3 != 0 && i % 5 != 0)
                Console.Write(i);
            Console.WriteLine();
        }

з

.locals init (
    [0] int32 i)
L_0000: ldc.i4.1 
L_0001: stloc.0 
L_0002: br.s L_003b
L_0004: ldloc.0 
L_0005: ldc.i4.3 
L_0006: rem 
L_0007: brtrue.s L_0013
L_0009: ldstr "Fizz"
L_000e: call void [mscorlib]System.Console::Write(string)
L_0013: ldloc.0 
L_0014: ldc.i4.5 
L_0015: rem 
L_0016: brtrue.s L_0022
L_0018: ldstr "Buzz"
L_001d: call void [mscorlib]System.Console::Write(string)
L_0022: ldloc.0 
L_0023: ldc.i4.3 
L_0024: rem 
L_0025: brfalse.s L_0032
L_0027: ldloc.0 
L_0028: ldc.i4.5 
L_0029: rem 
L_002a: brfalse.s L_0032
L_002c: ldloc.0 
L_002d: call void [mscorlib]System.Console::Write(int32)
L_0032: call void [mscorlib]System.Console::WriteLine()
L_0037: ldloc.0 
L_0038: ldc.i4.1 
L_0039: add 
L_003a: stloc.0 
L_003b: ldloc.0 
L_003c: ldc.i4.s 100
L_003e: ble.s L_0004
L_0040: ret 

Вони ідентичні функції. Другий - це навіть не асемблер, але .NET IL (мова посередника, схожа на байт-код Java). Друга компіляція перетворює IL в нативний код (тобто майже асемблер), роблячи його ще більш критичним.

Я думаю, що ASM на рівні навіть x86 (_64) має сенс у випадках, коли ви отримуєте багато, використовуючи інструкції, які складно оптимізувати для компілятора. Наприклад, x264 використовує багато коду для кодування, а швидкість збільшення величезна.

Я впевнений, що є багато причин, але я можу придумати дві швидкі причини

1. Код складання, безумовно, важче читати (я впевнений, що його також потрібно більше часу)
2. Коли у вас є величезна команда розробників, що працюють над продуктом, корисно розділити ваш код на логічні блоки та захистити інтерфейси.

Одне з ранніх відкриттів (ви знайдете його в Міфічному місяці людини Брукса , який є досвідом 1960-х років) - це те, що люди були більш-менш продуктивними однією мовою, як іншою, у налагоджених рядках коду на день. Це, очевидно, не є загальновиробничим і може зламатися, коли його натиснути занадто далеко, але це, як правило, стосується мов високого рівня часів Брукса.

Тому найшвидшим способом підвищення продуктивності було б використання мов, де один окремий рядок коду робив більше, і справді це працює, принаймні для таких складних мов, як FORTRAN та COBOL, або надати більш сучасний приклад C.

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

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

Отже, реально, може бути дуже важко прийняти правильні рішення, скажімо, які регістри ви повинні використовувати чи які інструкції трохи ефективніші. Компілятори можуть використовувати евристику, щоб визначити, які компроміси, ймовірно, мають найкращий окуп. Ми, мабуть, можемо продумати менші проблеми та знайти локальні оптимізації, які могли б перемогти наші нині досить складні компілятори, але шанси полягають у тому, що в середньому випадку хороший компілятор зробить кращу роботу з першої спроби, ніж хороший програміст. Зрештою, як Джон Генрі, ми можемо побити автомат, але ми можемо серйозно спалити себе, потрапивши туди.

Наші проблеми також зараз зовсім інші. У 1986 році я намагався зрозуміти, як досягти трохи більшої швидкості з невеликих програм, які передбачали виведення на екран декількох сотень пікселів; Я хотів, щоб анімація була менш хиткою. Справедливий випадок для мови складання. Зараз я намагаюся розібратися, як представляти абстракції навколо контрактної мови та політики щодо обслуговування іпотечних кредитів, і я краще прочитав би щось, що виглядає близько до мови, якою розмовляють ділові люди. На відміну від макросів LISP, макроси збірки не сильно застосовують правила, тому, хоч ви, можливо, зможете отримати щось досить близьке до DSL у хорошому асемблері, він буде схильний до всіляких вигадок, які виграли ' не створюватимуть мені проблем, якщо я написав той самий код у Ruby, Boo, Lisp, C # або навіть F #.

Якщо ваші проблеми легко виразити ефективною мовою збірки, проте, вам більше сили.

Дітто більшість того, що сказали інші.

У старі добрі часи до винайдення С, коли єдиними мовами високого рівня були такі речі, як COBOL та FORTRAN, було багато речей, з якими просто не вдалося обійтися, не вдаючись до асемблера. Це був єдиний спосіб отримати повну ширину гнучкості, мати доступ до всіх пристроїв і т. Д. Але тоді був винайдений C, і майже все, що було можливо в монтажі, було можливим в C. Я написав дуже мало збірки, оскільки тоді.

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

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

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

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

Особисто я думаю, що ринок сильно підтримує мови високого рівня. Якби мова монтажу була єдиною мовою, яка існує сьогодні, тоді їх програмування буде приблизно на 70% менше, і хто знає, де був би наш світ, ймовірно, ще в 90-х. Мови вищого рівня подобаються більш широкому колу людей. Це дозволяє більшому забезпеченню програмістів побудувати необхідну інфраструктуру нашого світу. Такі країни, що розвиваються, як Китай та Індія, значною мірою користуються такими мовами, як Java. Ці країни швидко розвиватимуть свою ІТ-інфраструктуру, і люди стануть більш взаємопов'язаними. Тому я можу сказати, що мови високого рівня популярні не тому, що вони виробляють чудовий код, а тому, що вони допомагають задовольнити попит на світових ринках.

Я зараз навчаюсь складанню в comp org зараз, і хоча це цікаво, це також дуже неефективно писати. Вам потрібно тримати багато деталей у голові, щоб налагодити роботу, і також повільніше писати ті самі речі . Наприклад, простий 6 рядок для циклу в C ++ може дорівнювати 18 рядкам і більше складання.

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

Що з C має хороший макроскладач - це мова C. Перевірка типу. Контурні контури. Автоматичне управління стеком. (Майже) автоматичне управління змінними. Динамічні прийоми пам’яті в асемблері - це масивний біль в області прикладу. Виконання належного списку належним чином страшно в порівнянні з C або ще краще foo.insert (). І налагодження - ну, немає жодної конкуренції щодо того, що простіше налагодити. ХЛЛ виграють руки там.

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

Ні, я буду дотримуватися C і мати справу з періодичним незначним уповільненням продуктивності порівняно з часом, який я отримую з ХЛЛ.

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

Однак, я думаю, що все ще існує дійсне використання для складання. Наприклад, у мене є декілька досить оптимізованих процедур збирання для обробки великої кількості даних, використовуючи SIMD та дотримуючись параноїдального підходу "кожен біт є святим" [цитата В.Стоб]. (Але зауважте, що наївні реалізації збірок часто набагато гірші, ніж те, що створював би компілятор.)

C - макроскладач! І це найкращий!

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

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

Люди, здається, забувають, що є й інший напрямок.

Чому ви в першу чергу пишете в Асемблері? Чому б не написати програму мовою по-справжньому низького рівня?

Замість

mov eax, 0x123
add eax, 0x456
push eax
call printInt

ви могли б так само добре писати

B823010000
0556040000
50 
FF15.....

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

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

Тому що це завжди так: час проходить і хороші речі теж минають :(

Але коли ви пишете ASM-код, це абсолютно інше відчуття, ніж коли ви кодуєте високого рівня, хоча ви знаєте, що це набагато менш продуктивно. Це як ви художник: ви можете малювати все, що вам подобається, як вам подобається, абсолютно без обмежень (ну, лише за допомогою функцій процесора) ... Ось чому я це люблю. Шкода, що ця мова відходить. Але поки хтось все ще пам’ятає це і кодує, він ніколи не помре!

$$$

Компанія наймає розробника, щоб перетворити код у $$$. Чим швидше може бути створений корисний код, тим швидше компанія може перетворити цей код у $$$.

Мови вищого рівня, як правило, краще підбирати великі обсяги корисного коду. Це не означає, що збірка не має свого місця, бо є часи і місця, де більше нічого не буде робити.

Перевага HLL ще більше, якщо ви порівнюєте збірку з мовою вищого рівня, ніж C, наприклад, Java або Python або Ruby. Наприклад, ці мови містять сміття: не потрібно турбуватися про те, коли звільнити шматок пам’яті, а також немає витоків пам’яті чи помилок через те, що вони надто рано звільняються.

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

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

Ми знайомимося з монтажем на моїх курсах коледжу. Це допоможе зрозуміти поняття. Однак я сумніваюся, що хтось із нас написав би 90% коду в зборах. Наскільки сьогодні актуальні знання про поглиблене складання?

Переглядаючи ці відповіді, я б покладав сумніви, що 9/10 респондентів ніколи не працювали зі складанням.

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