Будет ли компьютер пытаться делить на ноль?

Мы все знаем, 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 дает либо + Infinity, либо -Infinity, в зависимости от знака x.

В таких языках, как C, C ++ и т. Д. Деление на ноль вызывает неопределенное поведение. Таким образом, согласно определению языка, все может произойти. Особенно то, чего ты не хочешь. Как и все отлично работает, когда вы пишете код и уничтожаете данные, когда его использует ваш клиент. Так что с языковой точки зрения не делайте этого . Некоторые языки гарантируют, что ваше приложение потерпит крах; это зависит от них, как это реализовано. Для этих языков деление на ноль приведет к сбою.

Многие процессоры имеют какую-то встроенную инструкцию «делить», которая будет вести себя по-разному в зависимости от процессора. На 32-битных и 64-битных процессорах Intel инструкции «делить» приводят к сбою приложения при попытке деления на ноль. Другие процессоры могут вести себя по-другому.

Если компилятор обнаружит, что при выполнении некоторого кода произойдет деление на ноль, и компилятор хорош для своих пользователей, он, скорее всего, выдаст вам предупреждение и сгенерирует встроенную инструкцию «делить», чтобы поведение такой же.

Похоже, вам интересно, что произойдет, если кто-то создаст процессор, который явно не проверяет ноль перед делением. Что произойдет, полностью зависит от осуществления деления. Не вдаваясь в подробности, один вид реализации даст результат, в котором установлены все биты, например 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
• Вычислите логарифмы обоих чисел, вычтите их и увеличьте e до степени результата. Очень неэффективный метод по сравнению с вышеупомянутым методом вычитания, но математически действительный
  • При попытке расчета может произойти переполнение, log(0)и программа либо использует свои процедуры обработки ошибок, либо вылетает
  • Программное обеспечение может предполагать, что все логарифмы могут быть рассчитаны с фиксированным числом шагов и возвращать большое, но неправильное значение. Поскольку оба логарифма будут одинаковыми, разница будет 0и e ⁰ = 1, что дает результат1

Другими словами, то, что произойдет, будет зависеть от реализации, и можно будет написать программное обеспечение, которое будет давать правильные и предсказуемые результаты для каждого значения, но, казалось бы, странные значения для 0/0этого, тем не менее, все еще внутренне согласованы.