Чи потрібно розуміти, що відбувається на апаратному рівні, щоб бути хорошим програмістом?

Я програміст-самоучок, на всякий випадок, коли на це запитання відповіли в CS 101. Я вивчив і використовував багато мов, здебільшого для власного особистого використання, але іноді і для професійних занять.

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

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

Ні. Ніхто не розуміє, що відбувається на апаратному рівні.

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

Але потім знову ...

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

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

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

Ще одна річ, на яку ви можете заглянути, - це вбудована цибуля. Е, я маю на увазі вбудовані системи. Існує ряд вбудованих платформ, які досить прості у використанні: Arduino та BASIC Stamp - два приклади. Це в основному невеликі мікропроцесори з великою кількістю вбудованих функцій. Ви можете вважати їх цибулею з меншою кількістю шарів, ніж ваш типовий настільний ПК, тож можна досить глибоко зрозуміти, що відбувається у всій системі, від апаратного забезпечення до програмного забезпечення.

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

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

Розуміння пам'яті програми! = Розуміння апаратного забезпечення

Розуміння ієрархії пам'яті == Розуміння обладнання

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

Виходячи з вашого прикладу, вам просто потрібно зрозуміти, як поділяється пам'ять і як вона організована під час запуску програми. Розуміння обладнання не допоможе вам у цьому плані, оскільки пам'ять (як видно програмі) навіть не по-справжньому представляє апаратне забезпечення завдяки магії віртуальної пам'яті.

Якщо вам цікаво питання щодо продуктивності, залежно від порядку, в якому ви отримуєте доступ до пам’яті, ЗАРАЗ ви отримаєте користь від розуміння апаратних засобів, ієрархії пам’яті, помилок кеш-пам'яті, помилок сторінки та всієї чудової чудової користі, яка виходить із обладнання.

Якщо ви дійсно вирішили дізнатися трохи асемблера, ймовірно , ви повинні дізнатися що - щось на зразок 6502 асемблера на Commodore 64 (емулювати, звичайно), або 68000 на Amiga.

Ви можете ознайомитись з Commodore 64 тут ...

http://thepiratebay.org/torrent/4609238/Tag3-Saal2-Slot16_00--ID2874-the_ultimate_commodore_64_talk-Main

Класична книга все, що вам потрібно знати, - це описана тут ...

http://reprog.wordpress.com/2010/03/12/programming-books-part-3-programming-the-commodore-64/

Ви, ймовірно, можете знайти сканування PDF, якщо оглянетесь.

IMO, 6502 простіше, ніж Z80, а 68000 легше, ніж 8086 - більш регулярні набори інструкцій тощо.

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

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

Отже - це, мабуть, гідна вправа, якщо ви не витрачаєте на це занадто багато часу. Я засвоїв асемблер 6502 як свою другу мову, коли мені було близько 14 років, відразу після Commodore Basic. Але в основному це виходить дуже проста робоча модель, щоб ви могли додати до неї більш складні ідеї з мінімальним непорозумінням.

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

• Як працюють регістри процесора.
• Як працює адресація пам'яті, включаючи непряме.
• Як працює стек процесора
• Як працює бітова логіка.
• Як ЦП контролює пристрої вводу / виводу.
• Як працюють переривання.

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

Точно наскільки корисно знати більшість цих речей зараз, проте це складне питання.

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

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

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

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

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

Це улюблена моя книга для цього ...

http://dickgrune.com/Books/MCD_1st_Edition/

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

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

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

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

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

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

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

Мій погляд на комп’ютери теж змінився. Я перейшов до «Гарячих чіпів», а до цього Форум мікропроцесорів, що повернувся до середини 1990-х років. Напевно, я знаю більше про апаратне забезпечення мікропроцесорів, ніж принаймні 99% програмістів - і знаючи, що я роблю, я скажу це: вони вже не звичайні. Вони ж майже порушують закони фізики. Я багато зробив тестування на низькому рівні, і це можу сказати точно: подолати ілюзію, створену процесором, і перетворити на рівень показу, як апаратне забезпечення дійсно працює, часто буває надзвичайно важко. Я б хотів, щоб я міг розмістити фотографію одного з наших установок із комп'ютером, похованим під кабелі не менше ніж 4 логічних аналізаторів, щоб правильно виміряти один аспект того, як кешування працює на сучасному процесорі (не кажучи вже про деякі справді вибагливі програми для забезпечення того, що те, що ми вимірювали, було саме тим, що робив процесор, і нічого іншого).

Різні мови працюють на різних рівнях абстрагування від апаратних засобів. C і C ++ дуже низькі. Мови сценаріїв, з іншого боку, вимагають менше знати про основні деталі.

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

Якщо ви програмуєте на C ++, вам потрібно добре розуміти, як працює сучасний процесор, принаймні на рівні абстракції, на якому працює компілятор. (Всередині процесора відбуваються речі, які прозорі і для компілятора).

Я хотів би додати точку зразкового дизайну мов вищого рівня, таких як C.

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

Портабельність програм C на папері DMR та системи UNIX - це перша, яку я пам'ятаю, щоб обговорити (абстрактну) модель машини для C.

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