пострадать?
Можно быть уверенным что ebx/esi/edi/ebp (r12...r15) сохраняются (соглашение stdcall).
А с MMX/SSE как? Помню видел в отладчике что генерируемый MSVC код например использует MMX или SSE для затирания памяти. Википедия пишет что для x86-64 параметры могут в SSE-регистрах передаваться и что MSVC их используется и надо сохранять XMM6/7 в ассемблерных вставках. Но внятного списка повреждаемых MMX/SSE-регистров при вызове winapi - я не нашёл.
Если я что-то загружу в MMX/SSE а потом буду вызывать различные winapi-функции - то есть ли какой-то документ гарантирующий что регистры не будут повреждены?
Никогда не видел, чтобы stdcall гарантировал то, что регистры не изменятся. Да и вообще использовать регистры для хранения данных не особо хорошая практика.
У вас теперь и данные в регистрах нельзя хранить? Ну всё в память будем писать, отличная практика.
Да нет, что Вы, лучше всё хранить в регистрах и ловить уб даже при вызове функций стандартной библиотеки си)
У вас какие-то ограничения по отладчику, или какие ещё причины, что вы не можете проверить, какие регистры изменяет функция после вызова? К тому же, кол-во регистров на x86 для stdcall не так велико. EDI, ESI, EBP, EBX не будут изменяться в большинстве случаев.
Регистры для stdcall?) Что-то новенькое, а расскажите подробнее пожалуйста
на сайте микрософта про Calling conventions это неоднократно заявлено, ebx/esi/edi/ebp сохраняются. И в различной программерской литературе. Ещё нашёл что сохраняется FPU состояние и все регистры кроме st0. А вот про SSE ничего толком нет.
Думаю, стоит найти какую-либо функцию WinAPI, использующую SSE, и посмотреть, сохраняет она, или нет.
Нормальная практика, и на x86_64 соглашение гарантирует, что некоторые регистры изменяться не будут
Он имел ввиду именно stdcall, не надо путать передачу аргументов и ответственность за сохранность регистров
Обсуждают сегодня