Antichat снова доступен.
Форум Antichat (Античат) возвращается и снова открыт для пользователей.
Здесь обсуждаются безопасность, программирование, технологии и многое другое.
Сообщество снова собирается вместе.
Новый адрес: forum.antichat.xyz
 |
Задание собственного типа функции |

22.07.2008, 02:36
|
|
Познающий
Регистрация: 30.11.2006
Сообщений: 49
Провел на форуме: 36434
Репутация:
28
|
|
Задание собственного типа функции
Я вот думаю - можно ли заставить VC понимать другие соглашения о вызове функций. Вот, скажем, борланд понимает соглашение __fastcall по-своему и передаёт параметры в регистрах eax, ecx. Visual передаёт в ecx и edx.
можно ли как-то описать свой тип (__mycall) и передавать параметры так, как я хочу? хочу, например, передавать параметры в регистрах eax, ecx, edx, остальные в стеке.
может быть меня и глючит, но в x64 это становится довольно актуально, т.к. регистров уже 16. Описывая своё соглашение можно вообще забыть о стеке при передаче параметров..
|
|
|

22.07.2008, 15:01
|
|
Banned
Регистрация: 08.04.2005
Сообщений: 446
Провел на форуме: 2187381
Репутация:
518
|
|
обычно не парятся через глобальные переменные!
Последний раз редактировалось Delimiter; 22.07.2008 в 15:03..
|
|
|

27.07.2008, 18:17
|
|
Познающий
Регистрация: 30.11.2006
Сообщений: 49
Провел на форуме: 36434
Репутация:
28
|
|
обычно не парятся через глобальные переменные!
что...? при чём здесь глобальные переменные?
|
|
|

27.07.2008, 19:08
|
|
Участник форума
Регистрация: 03.01.2008
Сообщений: 156
Провел на форуме: 414311
Репутация:
110
|
|
Delimiter наверно имел ввиду, что когда не устраивают стандартные соглашения, то используют глобальные переменные для передачи параметров.
|
|
|

27.07.2008, 19:29
|
|
Banned
Регистрация: 08.04.2005
Сообщений: 446
Провел на форуме: 2187381
Репутация:
518
|
|
.... именно так . Можно вообще со стеком не заморачиваться , пусть там лежит только адрес возврата!
...но Tc хочет узнать о внутренних средствах компайлера и линкера! Просто мой путь не как подняться в гору а как ее обойти!
|
|
|

27.07.2008, 19:47
|
|
Участник форума
Регистрация: 03.01.2008
Сообщений: 156
Провел на форуме: 414311
Репутация:
110
|
|
интересно, а в каких случаях стандартные соглашения не подходят? не сталкивался с этим ещё.
В принципе, ИМХО, не слишком эффективно передавать в функцию параметры через глобальные переменные. Через стэк проще и быстрее. Ну и ещё быстрее передача через регистры, но в свете их нехватки постоянной, стек из трёх оптимальнее всего.
Хотя может я и ошибаюсь. Опыта пока маловато )
|
|
|

27.07.2008, 22:29
|
|
Познающий
Регистрация: 30.11.2006
Сообщений: 49
Провел на форуме: 36434
Репутация:
28
|
|
такс... товарищи. сдаётся мне стоит объяснить ещё раз.
вот, скажем новая архитектура - x64: 16 64х (!!!) регистров. можно в регистрах передавать все параметры, а про стек забыть вообще. если, скажем, я пишу апликуху не под винду, то такой вариант очень даже разумен.
|
|
|

27.07.2008, 22:39
|
|
Banned
Регистрация: 08.04.2005
Сообщений: 446
Провел на форуме: 2187381
Репутация:
518
|
|
че за ботва??? Откуда ты узнаешь какие регистры и как использовал до этого компилятор! Иди нах на ассемблер и людям мозги фигней не забивай!!! Мля типа все окуенно низкоуровневые, только забывают что лабать нужно на ассемблере, а в ином случае компилятор будет использовать регистры сам, ты только можешь давать указания использовать переменную внутри функции как регистровую для резервации регистра!
|
|
|

28.07.2008, 00:24
|
|
Познающий
Регистрация: 30.11.2006
Сообщений: 49
Провел на форуме: 36434
Репутация:
28
|
|
Откуда ты узнаешь какие регистры и как использовал до этого компилятор!
как это откуда? вообще-то компилятор может быть увереным лишь в том, что функция не изменит регистров ebp, ebx, esi, edi (их она и сохраняет в стеке). надеяться на то, что остальные регистры не будут заюзаны функцией компилятор не может - почему бы не использовать оставшиеся регистры для передачи параметров. по сути дела - то же самое fastcall соглашение, просто более раширенное, с использованием всех регистров.
|
|
|
|
 |
|
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
|
|
|
|