O>>В зависимости от процессора и того как ось его сконфигурила
ЕМ>А как винда конфигурит, не знаете?
не знаю, но погуглил, и вот :

The ARM architecture permits the operating system to put alignment enforcement into a relaxed mode, which Windows does. When alignment enforcement is relaxed, then misaligned reads and writes of a single word or halfword are fixed up automatically in the processor without generating an exception

(c) https://devblogs.microsoft.com/oldnewthing/20210611-00/?p=105299

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Один юзер попросил сделать ему сборку одного из моих драйверов на ARM64. А мне и проверить негде, разве что ARM-винду поднять под QEMU, но с ни с тем, ни с другим еще не имел дела, насколько это геморройно/тормозно?

Ну qemu/arm не сравниться конечно с виртуализацией amd64 на amd64, но даже 10 лет назад
скорости хватало чтобы протестировать драйверы под Linux. Qemu еще поддерживает "gdb" протокол
так что можно легко подключиться отладчиком, вроде под Windows есть несколько инструментов поддерживающих "gdb"
протокол.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Здравствуйте, mike_rs, Вы писали:

ЕМ>>>чтение серии двухбайтовых слов (WORD) через указатель в цикле?

_>>а в чем проблема?

ЕМ>ARM такое умеет — читать двухбайтовое слово по нечетному адресу? Или компилятор просто будет разбивать на два однобайтовых чтения? Например, PDP-11 не умел работать со словами по нечетным адресам, и компилятор C с этим ничего не делал — выравнивание нужно было обеспечивать самому.

ARM-ы разные бывают. Например, ядро Cortex-M0 не допускает невыровненный доступ, а Cortex-M3 — имеет бит в одном из регистров, определяющий, допускать или нет. Плюс, при работе с периферией, отображаемой в адресное пространство, могут быть дополнительные ограничения — например, доступ строго по 4 байта.
Что касается поддержки компилятором, то у gcc есть __attribute__((packed)) вроде бы для этой цели, но никакой разницы в коде при его применении я не заметил. Возможно, так собран конкретный тулчейн, возможно, надо еще что-то добавлять в командной строке, возможно, просто лыжи не едут.
Так что лучше всего обеспечить выравнивание самостоятельно. Оно и на x86 будет работать быстрее.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>А юзер — не заказчик, он за это не платит, чтоб мне купить железо и попробовать, он просто попросил, а мне стало интересно.
Ну так попроси его протестировать тогда.

Один юзер попросил сделать ему сборку одного из моих драйверов на ARM64. А мне и проверить негде, разве что ARM-винду поднять под QEMU, но с ни с тем, ни с другим еще не имел дела, насколько это геморройно/тормозно?

Есть ли какие-нибудь известные проблемы переноса с x86/x64 на ARM64? Помнится, на ARM вроде были более строгие требования к выравниванию, что читать/писать по произвольному адресу можно только байтами — это так, или память меня подводит?

Еще у меня используются intrinsic'и _InterlockedExchangeAdd, _InterlockedCompareExchange, _InterlockedIncrement/_InterlockedDecrement — это на ARM реализовано аппаратно, или будет работать через библиотечные вызовы?

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Есть ли какие-нибудь известные проблемы переноса с x86/x64 на ARM64? Помнится, на ARM вроде были более строгие требования к выравниванию, что читать/писать по произвольному адресу можно только байтами — это так, или память меня подводит?

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

ЕМ>Еще у меня используются intrinsic'и _InterlockedExchangeAdd, _InterlockedCompareExchange, _InterlockedIncrement/_InterlockedDecrement — это на ARM реализовано аппаратно, или будет работать через библиотечные вызовы?

скомпилируй пример и посмотри в ida, что там получилось. Думаю, что зависит от разрядности операций и процессора, что-то будет нативно, что-то возможно через несколько команд.

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

_>компилятор учтет все ограничения

Как он "учтет", скажем, чтение серии двухбайтовых слов (WORD) через указатель в цикле?

_>посмотри в ida

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

Впрочем, можно ж ассемблерный листинг посмотреть, попробую.

Здравствуйте, Евгений Музыченко, Вы писали:

_>>компилятор учтет все ограничения
ЕМ>Как он "учтет", скажем, чтение серии двухбайтовых слов (WORD) через указатель в цикле?

а в чем проблема?

ЕМ>Впрочем, можно ж ассемблерный листинг посмотреть, попробую.

да, так еще проще, забыл про эту опцию

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

ЕМ>>чтение серии двухбайтовых слов (WORD) через указатель в цикле?

_>а в чем проблема?

ARM такое умеет — читать двухбайтовое слово по нечетному адресу? Или компилятор просто будет разбивать на два однобайтовых чтения? Например, PDP-11 не умел работать со словами по нечетным адресам, и компилятор C с этим ничего не делал — выравнивание нужно было обеспечивать самому.

Здравствуйте, Sergei I. Gorelkin, Вы писали:

SIG>ядро Cortex-M0 не допускает невыровненный доступ, а Cortex-M3 — имеет бит в одном из регистров, определяющий, допускать или нет.

Как я понимаю, из пользовательского приложения под виндой это не должно быть доступно, а глобально менять эти режимы из драйвера ядра должно быть запрещено соглашениями. Каковы свойства тех ARM'ов, на которых работает Win8/10/11? Нужно ли мне переделывать весь код на эти ограничения, или можно исходить из того, что на том железе их нет?

SIG>Так что лучше всего обеспечить выравнивание самостоятельно. Оно и на x86 будет работать быстрее.

Речь про выравнивание не полей структур, а потоков данных. Например, мой код работает со звуковыми потоками, которые могут быть одно-, двух-, трех- и четырехбайтовыми. На x86 чтение/запись двухбайтового слова по нечетному адресу всяко не медленнее, чем сборка/разборка по байтам, поэтому я использую указатели на WORD для 16-разрядных отсчетов, и комбинации WORD/BYTE — для 24-разрядных.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Речь про выравнивание не полей структур, а потоков данных. Например, мой код работает со звуковыми потоками, которые могут быть одно-, двух-, трех- и четырехбайтовыми. На x86 чтение/запись двухбайтового слова по нечетному адресу всяко не медленнее, чем сборка/разборка по байтам, поэтому я использую указатели на WORD для 16-разрядных отсчетов, и комбинации WORD/BYTE — для 24-разрядных.

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

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

_>К этому вопросу можно будет вернутся, когда все соберется под целевую платформу, запустится, но перформанс окажется недостаточным.

Если железо не поддерживает двухбайтовых операций по нечетным адресам, в режиме ядра будет не недостаточных перформанс, а BSOD. И будет он не у меня, а у юзера, поскольку мне и проверить-то не на чем. А юзер — не заказчик, он за это не платит, чтоб мне купить железо и попробовать, он просто попросил, а мне стало интересно. Так что хотелось бы это прояснить заранее.

_>>а в чем проблема?
ЕМ>ARM такое умеет — читать двухбайтовое слово по нечетному адресу?
В зависимости от процессора и того как ось его сконфигурила, невыровненный доступ может работать прозрачно как в интеле, или падать с misalignment exception, или же ось может прозрачно обрабатывать этот misalignment exception, вызывая нехилую просадку производительности.
ЗЫ вроде же какуюто урезанную винду можно на распберри ставить, не?

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

O>В зависимости от процессора и того как ось его сконфигурила

А как винда конфигурит, не знаете?

O>ЗЫ вроде же какуюто урезанную винду можно на распберри ставить, не?

Можно, у меня таких плат нету.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>ARM такое умеет — читать двухбайтовое слово по нечетному адресу?
С некоторой версии ARM таки научили unaligned access.

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

CC>Ну так попроси его протестировать тогда.

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

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

_>Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>>Есть ли какие-нибудь известные проблемы переноса с x86/x64 на ARM64? Помнится, на ARM вроде были более строгие требования к выравниванию, что читать/писать по произвольному адресу можно только байтами — это так, или память меня подводит?

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

Скажем так, компилятор учтет большинство ограничений, если явно указано что структура pack(1), то с ней проблем не будет, но если кто-то сделает тупой каст, то результат может быть разный

А еще, проблемы будут только на int64 )

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Один юзер попросил сделать ему сборку одного из моих драйверов на ARM64. А мне и проверить негде, разве что ARM-винду поднять под QEMU, но с ни с тем, ни с другим еще не имел дела, насколько это геморройно/тормозно?

Через qemu под x86 линуксом запустить ARM-линукс не геморно, если пользовался qemu до этого. Скорей всего и с вендой проблем не будет. Если не пользовался qemu до этого, то придется разбираться.

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Один юзер попросил сделать ему сборку одного из моих драйверов на ARM64. А мне и проверить негде, разве что ARM-винду поднять под QEMU, но с ни с тем, ни с другим еще не имел дела, насколько это геморройно/тормозно?

А не проще взять какую-нибудь малину-апельсину? Венда на малине вроде заводится.

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

УП>А не проще взять какую-нибудь малину-апельсину?

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

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Это надо подобрать годную, заказать, дождаться, подключить, настроить, установить, связать с рабочей системой и т.п. На фоне простого любопытства — слишком хлопотно.

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

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

_>ты тут уже потратил больше времени, чем заняла бы установка винды на RPi и запуск там твоего драйвера под отладчиком.

Вы действительно считаете, будто я все это время занимаюсь этим вопросом? Не говоря уже о том, что у меня тупо нет ни RPi, ни желания ее приобрести.

Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Один юзер попросил сделать ему сборку одного из моих драйверов на ARM64. А мне и проверить негде, разве что ARM-винду поднять под QEMU, но с ни с тем, ни с другим еще не имел дела, насколько это геморройно/тормозно?
А он случайно не говорил, на чем он планирует эксплуатировать ваш софт?
Я просто всю тему Windows on ARM (после Surface на ARM) упустил из виду, и, кроме RPi (на которой можно было развернуть некую специальную версию Windows), где она (Windows) и в каком виде сейчас реально работает не представляю.

Здравствуйте, Михаил Романов, Вы писали:

МР>А он случайно не говорил, на чем он планирует эксплуатировать ваш софт?

На Raspberry Pi.