Здравствуйте, netch80, Вы писали:

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

Если вопрос в том, чтобы вовсе не иметь в реализации механизма исключений, то это вполне разумно. Но тогда разумно ввести соответствующий флаг состояния, по аналогии с переполнением, а не возвращать результат, который, не будучи специально проверен, почти гарантированно наделает бед. Когда такое решение приходит в одну больную голову, это еще можно понять, но когда оно принимается коллегиально, это уже что-то запредельное.

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

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

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

Значение, ближайшее к бесконечности, можно считать осмысленным только для деления с плавающей точкой. Для деления с фиксированной оно, наоборот, абсурдно.

N>ARM/64 выбрал ноль, и мне это решение кажется достаточно нелепым.

Мне тоже, Скорее уж единицу.

N>простейший итерационный делитель в железе, returning или non-returning типа, на такое выдаст ответ из всех единичных битов, если специально не делать проверку на ноль. Ну, значит, его и потребуем.

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

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

И какова вероятность того, что в языке, реализованном для архитектуры, мало-мальски сложной (имеющей тот же диспетчер памяти), вообще не будут поддерживаться механизмы исключений?

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

N>А какая связь? Сам по себе механизм защиты памяти уже системный и требует настройки.

Связь такая, что у программы должна быть возможность получать информацию о нештатных ситуациях при ее выполнении. Когда процессор эту информацию имеет, но не отдает, либо отдает в неадекватном виде, это требует экстраординарных оснований. Такие основания есть?

ЕМ>>Я мог бы помочь как-то иначе?

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

И что конструктивного я мог бы сказать по поводу отсутствия в языках даже самых простых в реализации средств контроля исполнения? Я действительно не знаю, почему в индустрии преобладает стремление внедрять свистоперделки, порой достаточно дорогие в реализации, но упорно избегать внедрения дешевых и эффективных средств.

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

Да, именно так. Он высказался в стиле "у нас все было правильно, просто никто не ожидал". Я в подобной ситуации всегда признаю, что было-то ведь неправильно и ненадежно, но или не обратил внимания, или понадеялся на лучшее.

N>Тогда это как минимум оффтопик для данного подфорума.

Это был лишь очередной пример проблемы, к которой привел произвольный выбор фиксированной константы. И ведь того, что выбор константы в 2 Гб тоже был неудачным, они тоже не признают.

N>Ни у кого нет бесконечного количества ресурсов на разработку и учёт всего.

Да ладно бы такая ошибка была в сколько-нибудь объемном коде, с неочевидными зависимостями, которые трудно проследить в уме. Но в достаточно компактном коде загрузчика, который заполняет массив фиксированного размера, отсутствие адекватных действий при переполнении должно было насторожить.

N>вы ввели тут уже сильно позже исходного сообщения какую-то необходимость извиняться

Не извиняться, а признавать свои ошибки.