Сообщение Re[8]: Откуда эта лютая любовь к знаковым целым? от 09.05.2020 16:00
Изменено 09.05.2020 16:06 Evgeny.Panasyuk
Re[8]: Откуда эта лютая любовь к знаковым целым?
Здравствуйте, netch80, Вы писали:
EP>> for(int i=INT_MAX-2; i>=0; ++i) {
EP>> cout << i << " ";
EP>> }
EP>>Таки закольцевался int, правда jmp'ом
N>Да, такое они ловят. Видимо, предсказание на сколько-то итераций вперёд.
Здесь видимо следующая логика: i не отрицательное, и только инкрементируется, следовательно отрицательным без прохода по UB оно никак стать не может, поэтому имеем право заменить i>=0 на true.
Не думаю что зависит от количества итераций. Ибо даже если начинать с i=0 — в генерируемом коде всё равно безусловный jmp.
А поставил я INT_MAX-2 лишь для наглядности, чтобы был переворот в печатаемых значениях в отрицательные.
N>Ну я давно говорю, что семантика переполнения должна быть управляема контекстом — и ни знаковая с "программист должен сам", ни беззнаковая с модулем не должны быть единственными,
Там где скорость не важна — очевидно можно решить пользовательскими типами, а-ля safe int, saturated int, etc. Там где важна — нужна поддержка железа.
N>а умолчанием вообще должна быть неотложная генерация ошибки.
Было бы не плохо. Например как trap при делении на ноль.
EP>> for(int i=INT_MAX-2; i>=0; ++i) {
EP>> cout << i << " ";
EP>> }
EP>>Таки закольцевался int, правда jmp'ом
N>Да, такое они ловят. Видимо, предсказание на сколько-то итераций вперёд.
Здесь видимо следующая логика: i не отрицательное, и только инкрементируется, следовательно отрицательным без прохода по UB оно никак стать не может, поэтому имеем право заменить i>=0 на true.
Не думаю что зависит от количества итераций. Ибо даже если начинать с i=0 — в генерируемом коде всё равно безусловный jmp.
А поставил я INT_MAX-2 лишь для наглядности, чтобы был переворот в печатаемых значениях в отрицательные.
N>Ну я давно говорю, что семантика переполнения должна быть управляема контекстом — и ни знаковая с "программист должен сам", ни беззнаковая с модулем не должны быть единственными,
Там где скорость не важна — очевидно можно решить пользовательскими типами, а-ля safe int, saturated int, etc. Там где важна — нужна поддержка железа.
N>а умолчанием вообще должна быть неотложная генерация ошибки.
Было бы не плохо. Например как trap при делении на ноль.
Re[8]: Откуда эта лютая любовь к знаковым целым?
Здравствуйте, netch80, Вы писали:
EP>> for(int i=INT_MAX-2; i>=0; ++i) {
EP>> cout << i << " ";
EP>> }
EP>>Таки закольцевался int, правда jmp'ом
N>Да, такое они ловят. Видимо, предсказание на сколько-то итераций вперёд.
Здесь видимо следующая логика: i не отрицательное, и только инкрементируется, следовательно отрицательным без прохода по UB оно никак стать не может, поэтому имеем право заменить i>=0 на true.
Не думаю что зависит от количества итераций. Ибо даже если начинать с i=0 — в генерируемом коде всё равно безусловный jmp.
А поставил я INT_MAX-2 лишь для наглядности, чтобы был виден переворот в печатаемых значениях в отрицательные.
N>Ну я давно говорю, что семантика переполнения должна быть управляема контекстом — и ни знаковая с "программист должен сам", ни беззнаковая с модулем не должны быть единственными,
Там где скорость не важна — очевидно можно решить пользовательскими типами, а-ля safe int, saturated int, etc. Там где важна — нужна поддержка железа.
N>а умолчанием вообще должна быть неотложная генерация ошибки.
Было бы неплохо. Например как trap при делении на ноль.
EP>> for(int i=INT_MAX-2; i>=0; ++i) {
EP>> cout << i << " ";
EP>> }
EP>>Таки закольцевался int, правда jmp'ом
N>Да, такое они ловят. Видимо, предсказание на сколько-то итераций вперёд.
Здесь видимо следующая логика: i не отрицательное, и только инкрементируется, следовательно отрицательным без прохода по UB оно никак стать не может, поэтому имеем право заменить i>=0 на true.
Не думаю что зависит от количества итераций. Ибо даже если начинать с i=0 — в генерируемом коде всё равно безусловный jmp.
А поставил я INT_MAX-2 лишь для наглядности, чтобы был виден переворот в печатаемых значениях в отрицательные.
N>Ну я давно говорю, что семантика переполнения должна быть управляема контекстом — и ни знаковая с "программист должен сам", ни беззнаковая с модулем не должны быть единственными,
Там где скорость не важна — очевидно можно решить пользовательскими типами, а-ля safe int, saturated int, etc. Там где важна — нужна поддержка железа.
N>а умолчанием вообще должна быть неотложная генерация ошибки.
Было бы неплохо. Например как trap при делении на ноль.