Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>>Какая разница, что с чем сравнивать — частное с -1, или делитель с нулем?
N>>Второе честнее.
ЕМ>Тогда для чего здесь какие-то телодвижения со стороны разработчиков архитектуры? Сравнивать делитель с нулем — задача программиста или разработчика языка.

Движения у них очень просты:

1. Решили, что ситуация некорректности операции деления не заслуживает того, чтобы (по крайней мере в базовом ISA) требовать для этого механизм исключений.

Можно было бы это списать на подход RISC-V, где явно декларируется метод "мы позволяем самые минимальные реализации, если кому-то нужно, и постепенное расширение", но ARM/64, который совсем не планировался компактным, делает то же самое. Значит, соображения у них примерно одного плана: оно не заслуживает настолько особой обработки.

2. Если команда не делает исключения, то надо вернуть какое-то осмысленное значение в качестве частного. Варианты — ближайшее к бесконечности с нужной стороны (лучше всего), просто ближайшее к бесконечности, ноль, что-то иное. ARM/64 выбрал ноль, и мне это решение кажется достаточно нелепым. В RISC-V посмотрели с вот какой стороны: простейший итерационный делитель в железе, returning или non-returning типа, на такое выдаст ответ из всех единичных битов, если специально не делать проверку на ноль. Ну, значит, его и потребуем. (Это может не расширяться на знаковое деление само по себе, но тут уже обобщили.)

N>>Прочитайте ещё раз.

ЕМ>Я до этого прочитал дважды. Давайте перечитаем в третий раз:

ЕМ>

ЕМ>However, this ... would require language implementors to interact with the execution environment’s trap handlers for this case

ЕМ>Здесь написано, что разработчики архитектуры вроде бы заботятся о разработчиках языков, и отказ от формирования исключения вроде бы имеет целью избавить разработчиков языков от поддержки обработки аппаратных исключений.

ЕМ>Если я, по-Вашему, снова понял неправильно — попробуйте привести перевод, из которого следует что-то иное.

Да, именно так. Если бы деление на ноль вызывало исключение, то для внедрителей языков была бы дополнительная забота взаимодействия со сложным механизмом (traps) вместо простого (одна проверочная команда там, где это нужно).

Что не так?

ЕМ>>>Процессор его и генерирует.
N>>Уже нет (если мы про новые архитектуры).
ЕМ>А при обращении по нулевому адресу генерирует? Если да, то для чего?

Зависит от системы защиты памяти. Обычно DAT настраивается так, что страница с адресом 0 недоступна для любого доступа по крайней мере для юзерленда. (Случай ядра — зависит от местной практики. Обычно полезно, да, перемапить её на что-то другое. Но могут и не делать.)
А какая связь? Сам по себе механизм защиты памяти уже системный и требует настройки.

N>>Спасибо, вы очень помогли.
ЕМ>Я мог бы помочь как-то иначе?

Да, конструктивным рассмотрением вопросов дискуссии.

ЕМ>>>Так и ограничили бы принудительно прямо внутри функции — она и не давала бы никогда.

N>>И снова не хотите читать написанное русским по фоновому.

ЕМ>Скорее тупо не могу понять оправданий, выдаваемых за объяснения. Если бы Чен написал "в нашем коде была ошибка, из-за которой система переставала грузиться вместо того, чтобы просто игнорировать лишнюю память", то и возражений бы не было. Но он ведь не признал, что это был их косяк, оправдывая это маловероятностью. И Вы их оправдываете в том же ключе.

Это вы серьёзно — всё, что вы хотите, это чтобы Чен явно сказал "это была наша ошибка"? И если бы он сказал, вы бы вообще не подняли тему?

Тогда это как минимум оффтопик для данного подфорума. В чикаге было 100500 ошибок, недоделок, неоптимальных решений и прочего, и они постепенно правились — или не правились. Ни у кого нет бесконечного количества ресурсов на разработку и учёт всего. Результат оптимизируется под типовые пути работы, и часто различие лежит в том, этих типовых 1 или хотя бы 5. У хорошего разработчика 5. У отличного 10. У плохого 1, или 2, если начальство применило ключ достаточного размера для бития по башке.

Я не вижу смысла считать данную ситуацию какой-то существенной ошибкой потому, что оно не приводило к искажению данных, потере данных, неожиданной критической неработоспособности и т.п. — по крайней мере при нормальном админ. процессе у пользователя. Апгрейд железа или переход на новое это всегда особое событие, проверка на новом необходима перед переводом рабочей нагрузки на неё. Система не поддерживает какую-то не свойственную для её обычного профиля конфигурацию? Да таких профилей были реально тысячи! Масса нестандартного железа, и не только в сторону неожиданно хороших характеристик — как правило, это были локальные кривости всех видов.

А самое прямое для данной дискуссии — это что вы ввели тут уже сильно позже исходного сообщения какую-то необходимость извиняться, когда этого в вашем начальном сообщении не было и вы вместо этого обсуждали "уровень студента-второкурсника". Почему и зачем вы ввернули это только сейчас и походя, и теперь на этом основании чего-то требуете уже от меня?

Нехорошо, товарисч.