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

E>А зачем? В том смысле, что на разных платформах могут быть разные эндианы, и одно и тоже 64-битное число таким образом будет мапиться на разные пар 32-битных.

Это в теории, а на практике будет только x86/64 — либо i7, либо Xeon. А big endian я просто не буду поддерживать, как как для этого нужно во всем коде специально делать поддержку и тщательно его весь именно для этого тестировать, что совершенно не стоит потраченных усилий. Так же, как я не собираюсь поддерживать системы меньше 64 бит.

Просто мне не хочется писать код, который в явном виде нарушает strict aliasing и, таким образом, зависит от опций компиляции.
E>Тебе надо физически с битиками памяти работать, или таки нужны логически старшие и младшие биты?

Ну мне надо, например, независимо сложить нижнее и верхнее 32-битное слово, так, чтобы при сложении нижнего не было переноса в верхнее. Но потом использовать это все как одно 64-битное слово.

E>А ещё есть второй вопрос, зачем ты хочешь, обязательно читать/писать память, а не двигать битики? Вдруг двигать битики быстрее? Например, во многих x86 процах смесь 32-битных и 64-битных инструкций дорогая...
E>Зачем ты хочешь мешать оптимизатору?

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

Меня просто еще интересует концептуальная возможность обходить strict aliasing rule, так как оно является очень большим ограничением.

E>В общем, если ты хочешь работать с памятью напрямую, то есть речь о чём-то железячном, то пиши, читай прямо по адресам. Всё равно это никак не переносимо, а если таки речь идёт об операциях с числами, то бери сдвиги/маски и вперёд...

Ну отмена переносимости кода мало помогает, так как сама по себе не отменяет правила strict aliasing в компиляторах. А от опций и версий конкретных компиляторов не хочется зависеть.

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

E>А зачем? В том смысле, что на разных платформах могут быть разные эндианы, и одно и тоже 64-битное число таким образом будет мапиться на разные пар 32-битных.

Это в теории, а на практике будет только x86/64 — либо i7, либо Xeon. А big endian я просто не буду поддерживать, как как для этого нужно во всем коде специально делать поддержку и тщательно его весь именно для этого тестировать, что совершенно не стоит потраченных усилий. Так же, как я не собираюсь поддерживать системы меньше 64 бит.

Просто мне не хочется писать код, который в явном виде нарушает strict aliasing и, таким образом, зависит от опций компиляции.
E>Тебе надо физически с битиками памяти работать, или таки нужны логически старшие и младшие биты?

Ну мне надо, например, параллельно сложить нижнее и верхнее 32-битные слова (нижнее с нижним, верхнее с верхним), так, чтобы при сложении нижнего не было переноса в верхнее. Но потом использовать это все как одно 64-битное слово.

E>А ещё есть второй вопрос, зачем ты хочешь, обязательно читать/писать память, а не двигать битики? Вдруг двигать битики быстрее? Например, во многих x86 процах смесь 32-битных и 64-битных инструкций дорогая...
E>Зачем ты хочешь мешать оптимизатору?

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

Меня просто еще интересует концептуальная возможность обходить strict aliasing rule, так как оно является очень большим ограничением.

E>В общем, если ты хочешь работать с памятью напрямую, то есть речь о чём-то железячном, то пиши, читай прямо по адресам. Всё равно это никак не переносимо, а если таки речь идёт об операциях с числами, то бери сдвиги/маски и вперёд...

Ну отмена переносимости кода мало помогает, так как сама по себе не отменяет правила strict aliasing в компиляторах. А от опций и версий конкретных компиляторов не хочется зависеть.