Информация об изменениях

Сообщение Re[6]: Carbon от 18.04.2024 23:45

Изменено 19.04.2024 0:05 vdimas

Re[6]: Carbon
Здравствуйте, Sinclair, Вы писали:

S>А дальше компилятор делает второй ход: а раз в стандарте написано, что переполнение — это UB, то я могу делать что угодно, без оглядки на аппаратуру.

S>И, например, заменяю всю эту функцию на return false, и попутно встраиваю её во все места использования, выбрасывая все ветки кода, управляемые этим условием. Даже при компиляции под конкретный интел, который ведёт себя вполне себе defined образом.
S>Да, программа работает не так, как ожидал программист, но зато очень быстро. PROFIT!
S>Как по мне, так это очень похоже на каких-нибудь хитрожопых юристов, которые находят лазейку в законах и доят государство.

В данном случае ты даёшь оценку своим фантазиям, бо архитектуры/компиляторы явно определяют своё поведение при переполнении.
Т.е. UB тут для стандарта в общем, но не для конкретной связки платформы и компилятора.

Т.е. можно подобрать такое кодирование, что в твоём коде будет UB именно для этой платформы, например, для обратного кодирования есть два нуля — 0000 и 1111, где при сравнении первый ноль меньше второго, и твоя программа закономерно поломалась, как и предостерегал стандарт.

А так-то "железные" вещи часто пишут на сях для конкретной платформы, конечно, в т.ч. UB-код с т.з. "общего" стандарта.
А для конкретной платформы никакое не UB.

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

А так-то в обратном коде отрицание числа — это 1 такт (простая инверсия), где сложение, допустим, занимало 4 такта.
В той схемотехнике отрицание числа в дополнительном коде потребует тоже 4 такта, т.к. это или вычитание числа из 0-ля или инверсия с инкрементом.

Еще в обратном коде достаточен один сумматор, т.к. вычитание сводится к сложению с негативным числом, а в дополнительном коде требуется отдельный блок вычитателя, либо вычитать на том же сумматоре в две операции (сначала инверсия с инкементом, потом сложение), т.е. это будет уже 8 тактов.
Re[6]: Carbon
Здравствуйте, Sinclair, Вы писали:

S>А дальше компилятор делает второй ход: а раз в стандарте написано, что переполнение — это UB, то я могу делать что угодно, без оглядки на аппаратуру.

S>И, например, заменяю всю эту функцию на return false, и попутно встраиваю её во все места использования, выбрасывая все ветки кода, управляемые этим условием. Даже при компиляции под конкретный интел, который ведёт себя вполне себе defined образом.
S>Да, программа работает не так, как ожидал программист, но зато очень быстро. PROFIT!
S>Как по мне, так это очень похоже на каких-нибудь хитрожопых юристов, которые находят лазейку в законах и доят государство.

В данном случае ты даёшь оценку своим фантазиям, бо архитектуры/компиляторы явно определяют своё поведение при переполнении.
Т.е. UB тут для стандарта в общем, но не для конкретной связки платформы и компилятора.

Т.е. можно подобрать такое кодирование, что в твоём коде будет UB именно для этой платформы, например, для обратного кодирования есть два нуля для знаковых чисел — 0000 и 1111, где при сравнении первый ноль меньше второго, и твоя программа закономерно поломалась, как и предостерегал стандарт.

А так-то "железные" вещи часто пишут на сях для конкретной платформы, конечно, в т.ч. UB-код с т.з. "общего" стандарта.
А для конкретной платформы никакое не UB.

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

А так-то в обратном коде отрицание числа — это 1 такт (простая инверсия), где сложение, допустим, занимало 4 такта.
В той схемотехнике отрицание числа в дополнительном коде потребует тоже 4 такта, т.к. это или вычитание числа из 0-ля или инверсия с инкрементом.

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