Здравствуйте, niXman, Вы писали:
X>собственно сабж.
Ну, можно их просто перечислить. Если учесть, что выживших и практически значимых архитектур осталось немного, список будет не слишком-то длинным.
X>знаю, что на ARM не позволяет.
Даже ARM может в определенных случаях позволять. ARM при невыровненном доступе генерирует исключение. А ядро линуха, например, можно настроить, чтобы в ответ на это исключение он эмулировал соответствующую команду, а не прибивал процесс (ну, по крайней мере, раньше было можно, когда я еще возился с какими-то железками на ARMе).
X>но какие еще? препроцессором или компайл-тайм есть способ?
Интересно, если сочинить константное адресное выражение, очевидно не выровненное, и присвоить туда такое, чего не положено, gcc не догадается выдать предупреждение?
Re: задетектить архитектуры которые не позволяют unaligned load
Здравствуйте, niXman, Вы писали:
X>знаю, что на ARM не позволяет.
На каком? На ARM v8 в 64-битном режиме — по умолчанию позволяет, и обычно не рекомендуется это выключать.
И про 32 бита слышал, что тенденция — на разрешение.
X>но какие еще? препроцессором или компайл-тайм есть способ?
Если стоит враппер, который в рантайме ловит и отрабатывает сам (так делали на Alpha), то не отловишь без контроля времени (невыровненный становится раз в 20-100 дороже).
The God is real, unless declared integer.
Re[2]: задетектить архитектуры которые не позволяют unaligned load
Здравствуйте, Pzz, Вы писали:
Pzz>Ну, можно их просто перечислить. Если учесть, что выживших и практически значимых архитектур осталось немного, список будет не слишком-то длинным.
их действительно так мало?
можешь перечислить?
Pzz>Интересно, если сочинить константное адресное выражение, очевидно не выровненное, и присвоить туда такое, чего не положено, gcc не догадается выдать предупреждение?
а как проверить?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[2]: задетектить архитектуры которые не позволяют unaligne
Здравствуйте, netch80, Вы писали:
N>На каком? На ARM v8 в 64-битном режиме — по умолчанию позволяет, и обычно не рекомендуется это выключать. N>И про 32 бита слышал, что тенденция — на разрешение.
я с этим столкнулся на ARM v7, и после этого просто помню что все ARM такие... значит, ошибался...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, 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
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[3]: задетектить архитектуры которые не позволяют unaligned load
Здравствуйте, niXman, Вы писали:
Pzz>>Ну, можно их просто перечислить. Если учесть, что выживших и практически значимых архитектур осталось немного, список будет не слишком-то длинным. X>их действительно так мало? X>можешь перечислить?
Ну там, x86, ARM, PowerPC, MIPS. Возможно, SPARC еще отчасти жив. Остальное как-то нечасто встречается.
Кстати, из всех известных мне не-восьмибитных архитектур, только интел позволяет безалаберно обходиться с выравниванием. Так что, может тебе, наоборот, нужен не черный список, а белый, из одного пункта
Pzz>>Интересно, если сочинить константное адресное выражение, очевидно не выровненное, и присвоить туда такое, чего не положено, gcc не догадается выдать предупреждение? X>а как проверить?
Попробовать собрать под ARM.
Re[4]: задетектить архитектуры которые не позволяют unaligned load
Здравствуйте, Pzz, Вы писали:
Pzz>Ну там, x86, ARM, PowerPC, MIPS. Возможно, SPARC еще отчасти жив. Остальное как-то нечасто встречается.
теперь что, нужно для каждой из них нагуглить макрос идентифицирующий ее...
а каким образом можно это в компайл-тайм проверить?
Pzz>Кстати, из всех известных мне не-восьмибитных архитектур, только интел позволяет безалаберно обходиться с выравниванием. Так что, может тебе, наоборот, нужен не черный список, а белый, из одного пункта
=)
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Re[5]: задетектить архитектуры которые не позволяют unaligned load
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Pzz, Вы писали:
Pzz>>Ну там, x86, ARM, PowerPC, MIPS. Возможно, SPARC еще отчасти жив. Остальное как-то нечасто встречается. X>теперь что, нужно для каждой из них нагуглить макрос идентифицирующий ее... X>а каким образом можно это в компайл-тайм проверить?
А смысл?
x86 позволяет, но "unaligned load" работает медленнее насколько я знаю.
Помню давным давно Linux/ARM с которыми я работал позволял делать "unaligned load",
просто срабатывало "прерывание" и Linux ядро разруливало ситуацию, представляете
насколько это было медленно?
То есть не проще просто выравнивать данные и не париться об архитектуре,
будет быстрее даже на x86 и переносимо?
Здравствуйте, Zhendos, Вы писали:
Z>x86 позволяет, но "unaligned load" работает медленнее насколько я знаю.
Если переходишь границу порции общения с памятью (в нормальном случае это кэш-линия — 64 байта). Вместо одной операции доступа будет две.
Если больше нет другого доступа к соседним байтам, то это существенно. Если ещё есть неупорядочённая возня рядом (например, разбираешь упакованный бинарный формат транспорта по сети), то пофиг, сам доступ будет в разы медленнее потерь на удвоение.
The God is real, unless declared integer.
Re[7]: задетектить архитектуры которые не позволяют unaligne
да, проблема в том, что сериализация/десериализация работает медленнее чем хотелось бы...
при сериализации переменные копируются в буфер. понятно, что я не могу в буфере оставлять "дыры" ради того чтоб выровнять.
при десериализации наоборот, из буфера в переменные, и снова и из буфера читаю в основном не выровненные...
вот, собственно, и задался вопросом. интересует, на LE машинах, каким способом можно ускорить задачу?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
niXman:
X>да, проблема в том, что сериализация/десериализация работает медленнее чем хотелось бы... X>при сериализации переменные копируются в буфер. понятно, что я не могу в буфере оставлять "дыры" ради того чтоб выровнять. X>при десериализации наоборот, из буфера в переменные, и снова и из буфера читаю в основном не выровненные... X>вот, собственно, и задался вопросом. интересует, на LE машинах, каким способом можно ускорить задачу?
Применить старый как мир трюк: копировать между буфером и переменными при помощи memcpy.
Для x86 будет небольшой оверхэд, на декодирование лишних команд, зато на остальных архитертурах съэкономится время на обработку исключений.
