привет!

собственно сабж.

знаю, что на ARM не позволяет.
но какие еще? препроцессором или компайл-тайм есть способ?

спасибо.

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

X>собственно сабж.

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

X>знаю, что на ARM не позволяет.

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

X>но какие еще? препроцессором или компайл-тайм есть способ?

Интересно, если сочинить константное адресное выражение, очевидно не выровненное, и присвоить туда такое, чего не положено, gcc не догадается выдать предупреждение?

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

X>знаю, что на ARM не позволяет.

На каком? На ARM v8 в 64-битном режиме — по умолчанию позволяет, и обычно не рекомендуется это выключать.
И про 32 бита слышал, что тенденция — на разрешение.

X>но какие еще? препроцессором или компайл-тайм есть способ?

Если стоит враппер, который в рантайме ловит и отрабатывает сам (так делали на Alpha), то не отловишь без контроля времени (невыровненный становится раз в 20-100 дороже).

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

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

Pzz>Интересно, если сочинить константное адресное выражение, очевидно не выровненное, и присвоить туда такое, чего не положено, gcc не догадается выдать предупреждение?
а как проверить?

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

N>На каком? На ARM v8 в 64-битном режиме — по умолчанию позволяет, и обычно не рекомендуется это выключать.
N>И про 32 бита слышал, что тенденция — на разрешение.
я с этим столкнулся на ARM v7, и после этого просто помню что все ARM такие... значит, ошибался...

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

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

N>>На каком? На ARM v8 в 64-битном режиме — по умолчанию позволяет, и обычно не рекомендуется это выключать.
N>>И про 32 бита слышал, что тенденция — на разрешение.
X>я с этим столкнулся на ARM v7, и после этого просто помню что все ARM такие... значит, ошибался...
тут пишут что и ARM v5 такой же: https://blog.quarkslab.com/unaligned-accesses-in-cc-what-why-and-solutions-to-do-it-properly.html

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

Pzz>>Ну, можно их просто перечислить. Если учесть, что выживших и практически значимых архитектур осталось немного, список будет не слишком-то длинным.
X>их действительно так мало?
X>можешь перечислить?

Ну там, x86, ARM, PowerPC, MIPS. Возможно, SPARC еще отчасти жив. Остальное как-то нечасто встречается.

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

Pzz>>Интересно, если сочинить константное адресное выражение, очевидно не выровненное, и присвоить туда такое, чего не положено, gcc не догадается выдать предупреждение?
X>а как проверить?

Попробовать собрать под ARM.

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

Pzz>Ну там, x86, ARM, PowerPC, MIPS. Возможно, SPARC еще отчасти жив. Остальное как-то нечасто встречается.
теперь что, нужно для каждой из них нагуглить макрос идентифицирующий ее...
а каким образом можно это в компайл-тайм проверить?

Pzz>Кстати, из всех известных мне не-восьмибитных архитектур, только интел позволяет безалаберно обходиться с выравниванием. Так что, может тебе, наоборот, нужен не черный список, а белый, из одного пункта
=)

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

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

Pzz>>Ну там, x86, ARM, PowerPC, MIPS. Возможно, SPARC еще отчасти жив. Остальное как-то нечасто встречается.
X>теперь что, нужно для каждой из них нагуглить макрос идентифицирующий ее...
X>а каким образом можно это в компайл-тайм проверить?

А смысл?

x86 позволяет, но "unaligned load" работает медленнее насколько я знаю.
Помню давным давно Linux/ARM с которыми я работал позволял делать "unaligned load",
просто срабатывало "прерывание" и Linux ядро разруливало ситуацию, представляете
насколько это было медленно?

То есть не проще просто выравнивать данные и не париться об архитектуре,
будет быстрее даже на x86 и переносимо?

Вот кстати немного про "невыровненный доступ":

https://www.kernel.org/doc/Documentation/unaligned-memory-access.txt

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

Z>x86 позволяет, но "unaligned load" работает медленнее насколько я знаю.

Если переходишь границу порции общения с памятью (в нормальном случае это кэш-линия — 64 байта). Вместо одной операции доступа будет две.
Если больше нет другого доступа к соседним байтам, то это существенно. Если ещё есть неупорядочённая возня рядом (например, разбираешь упакованный бинарный формат транспорта по сети), то пофиг, сам доступ будет в разы медленнее потерь на удвоение.

Здравствуйте, netch80, Zhendos

да, проблема в том, что сериализация/десериализация работает медленнее чем хотелось бы...

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

вот, собственно, и задался вопросом. интересует, на LE машинах, каким способом можно ускорить задачу?

niXman:

X>да, проблема в том, что сериализация/десериализация работает медленнее чем хотелось бы...
X>при сериализации переменные копируются в буфер. понятно, что я не могу в буфере оставлять "дыры" ради того чтоб выровнять.
X>при десериализации наоборот, из буфера в переменные, и снова и из буфера читаю в основном не выровненные...
X>вот, собственно, и задался вопросом. интересует, на LE машинах, каким способом можно ускорить задачу?

Применить старый как мир трюк: копировать между буфером и переменными при помощи memcpy.
Для x86 будет небольшой оверхэд, на декодирование лишних команд, зато на остальных архитертурах съэкономится время на обработку исключений.