Чи спробує комп’ютер розділити на нуль?

Ми всі знаємо, що 0/0це Undefinedі повертає помилку, якби я ставлю її до калькулятора, і якби я створив програму (принаймні на C), ОС би припинила її, коли я намагаюся розділити на нуль.

Але мені цікаво, чи комп’ютер навіть намагається розділити на нуль , чи він просто "вбудований у захист", так що коли він "бачить", 0/0він повертає помилку ще до спроби її обчислити?

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

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

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

Цей же механізм пастки до винятків також буде використовуватися, коли ввімкнено виявлення переповнення, яке ви вимагаєте, зазвичай, використовуючи різні інструкції add / sub / mul (або прапор цих інструкцій).

Поділ з плаваючою точкою також має вбудоване виявлення для ділення на нуль, але повертає інше значення ( IEEE 754 вказує NaN ) замість того, щоб захоплювати обробник винятків.

Гіпотетично кажучи, якщо ЦП опустив будь-яке виявлення для спроби поділу на нуль, проблеми можуть включати:

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

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

Для номера з плаваючою комою більшість реалізацій використовують стандарт IEEE 754 , де розділення на 0 добре визначено. 0/0 дає чітко визначений результат NaN (не-число), а x / 0 для x ≠ 0 дає або + Нескінченність, або -Безмежність, залежно від знака x.

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

У багатьох процесорах є якась вбудована інструкція "ділити", яка буде вести себе по-різному залежно від процесора. У процесорах Intel 32bit і 64 біт процесори інструкція "розділити" приведе до краху вашої програми, коли ви спробуєте поділити на нуль. Інші процесори можуть поводитись інакше.

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

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

Але мені цікаво, чи комп’ютер навіть намагається розділити на нуль, чи просто "вбудований захист", і коли він "бачить" 0/0, він повертає помилку ще до спроби її обчислити?

Оскільки x/0немає сенсу, період, комп'ютери повинні завжди перевіряти на поділ на нуль. Тут є проблема: програмісти хочуть проводити обчислення (a+b)/cбез необхідності перевіряти, чи має такий розрахунок навіть сенс. Відповідь під капотом на поділ на нуль процесором + тип типу + операційна система + мова - це або зробити щось досить драстичне (наприклад, збій програми), або зробити щось надмірно доброякісне (наприклад, створити значення, яке не робить такий сенс, як IEEE з плаваючою точкою NaN, число, яке є "Не числом").

У звичайній обстановці від програміста очікується знати, чи (a+b)/cє сенс. У цьому контексті немає підстав перевіряти ділення на нуль. Якщо поділ на нуль трапляється, і якщо машинна мова + мова реалізації + тип даних + відповідь операційної системи на це - зробити програму збоєм, це добре. Якщо відповідь полягає у створенні значення, яке може врешті забруднити кожне число програми, це теж нормально.

Ні "щось драстичне", ні "надмірно доброякісне" не є правильним ділом у світі з обчисленнями з високою надійністю. Ці відповіді за замовчуванням можуть вбити пацієнта, розбити авіалайнер або змусити вибухнути бомбу в неправильному місці. У середовищі з високою надійністю програміст, який пише, (a+b)/cбуде підбитий до смерті під час перегляду коду, або в сучасний час, можливо, автоматично підбирається до смерті інструментом, який перевіряє конструктивність верболетів. У цьому середовищі цей програміст повинен замість цього щось написати div(add(a,b),c)(та, можливо, перевірити стан помилок). Під кришкою div(/ а також add) функції / макроси захищають від поділу на нуль (або переповнення у випадку add). Те, що передбачає цей захист, є специфічним для здійснення.

На сьогодні ми знаємо це x/0і 0/0не маємо чітко визначених відповідей. Що станеться, якщо ви 0/0все одно спробуєте розрахувати ?

У сучасній системі обчислення передаються до MPU в межах CPU і позначаються як незаконна операція, повертаючись NaN.

У значно старшій системі, наприклад домашніх комп’ютерах 80-х років, які не мали мікросхеми, розрахунок проводився будь-яким програмним забезпеченням. Є кілька можливих варіантів:

• Віднімайте все менші та менші копії дільника, поки значення не досягне нуля, і відслідковуйте, які розміри копій були відняті
  • Якщо він перевірить нуль до першого віднімання, він швидко вийде, і результат буде 0
  • Якщо він припускає, що він повинен бути здатний відняти хоча б один раз, результат буде 1
• Обчисліть логарифми обох чисел, віднімайте їх і піднімайте е до сили результату. Дуже неефективний метод порівняно з вищевказаним методом віднімання, але математично достовірний
  • При спробі обчислити може виникнути переповнення, log(0)і програмне забезпечення буде використовувати підходи під керуванням помилок, або виходить з ладу
  • Програмне забезпечення може припустити, що всі логарифми можна обчислити за фіксованою кількістю кроків і повернути велике, але неправильне значення. Оскільки обидва логарифми були б однаковими, різниця була б 0і e ⁰ = 1, даючи результат1

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