Для cl x86 существует такой прием требующий ассемблера:

void foo()
{
    uint32_t var;
    __asm { mov dword ptr var, offset label }
label:
}

Для gcc (x32/amd64):

void foo()
{
    uint(32/64)_t var;
    var = reinterpret_cast<uint(32/64)_t>(&&label);
label:
}

Для cl amd64 запретили инлайнинг __asm{}, как теперь можно получить адрес метки?

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

N>Для cl amd64 запретили инлайнинг __asm{}, как теперь можно получить адрес метки?

а как на счёт покурить jmp_buf?

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

N>Для cl amd64 запретили инлайнинг __asm{}, как теперь можно получить адрес метки?

Это классический пример вопроса, на который надо искать не ответ на заданный вопрос, а решение той проблемы, которую — практически наверняка некорректно — пытаются решить ответом на этот вопрос.
Поэтому глобальный вопрос — а зачем собственно нужен адрес метки?
Я навскидку предположил два варианта: 1) узнать какую-то точку в коде, близкую к адресу функции (хм, а почему не сам адрес функции?), 2) узнать место для перехода на эту метку откуда-то совсем извне. Оба варианты очень сильно "чреваты боком" (tm): даже при минимальной оптимизации возможны случаи переезда существенных частей кода внутри функции, разрыв её на несколько частей, перестановка точек входа и т.д., в результате которых все представления о целостности выполняемого кода идут лесом.

Поэтому хотелось бы услышать постановку _исходной_ задачи (хотя бы на один уровень выше) и причины выбора решения с поиском адреса метки. Скорее всего это может быть решено иначе. Например, если задача обеспечить что-то вроде throw + catch, но в чистом C, то надо смотреть на setjmp+longjmp. Если задача — запомнить точку перехода в коде и потом перейти на неё, то для MSC это делается через switch, а для gcc есть расширение в виде "внутреннего" адреса метки (формат не сообщается) и назначенного goto, и этот механизм, в отличие от самопала, гарантирован против недопустимых оптимизаций.

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

N>Это классический пример вопроса, на который надо искать не ответ на заданный вопрос, а решение той проблемы, которую — практически наверняка некорректно — пытаются решить ответом на этот вопрос.

Всё это, конечно, правильно, но вот полная отмена ассемблерных вставок несколько напрягает. Например, некоторые алгоритмы (вычисление CRC, скремблирование) требуют операции циклического сдвига, сдвига через бит переноса. Может там ввели какие-то intrinsic функции для этого?

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

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

7>Всё это, конечно, правильно, но вот полная отмена ассемблерных вставок несколько напрягает. Например, некоторые алгоритмы (вычисление CRC, скремблирование) требуют операции циклического сдвига, сдвига через бит переноса. Может там ввели какие-то intrinsic функции для этого?

Напиши всю функцию на ASM целиком. Это ни кто не запрещал.

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

7>Всё это, конечно, правильно, но вот полная отмена ассемблерных вставок несколько напрягает. Например, некоторые алгоритмы (вычисление CRC, скремблирование) требуют операции циклического сдвига, сдвига через бит переноса. Может там ввели какие-то intrinsic функции для этого?

Оно?
http://msdn.microsoft.com/library/a0w705h5.aspx

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

N>>Это классический пример вопроса, на который надо искать не ответ на заданный вопрос, а решение той проблемы, которую — практически наверняка некорректно — пытаются решить ответом на этот вопрос.
7>Всё это, конечно, правильно, но вот полная отмена ассемблерных вставок несколько напрягает. Например, некоторые алгоритмы (вычисление CRC, скремблирование) требуют операции циклического сдвига, сдвига через бит переноса. Может там ввели какие-то intrinsic функции для этого?

Ну, это проблема исключительно пользующихся Microsoft, так что, как пел Высоцкий, "И я сочувствую слегка
погибшим, но издалека". Под gcc такой проблемы нет, ассемблерные вставки работают не хуже, чем раньше. Мотивации исключения в MSC ассемблера мне неизвестны, но он (ассемблер) там всегда был какой-то корявый. Например, отсутствие явного описания побочных эффектов, как в gcc или Watcom, заставляло делать слишком много сохранений на входе и выходе. Может, именно отказ от команд pusha и popa в x86-64 стал причиной, или хотя бы последней каплей? Мне всё-таки импонирует подход gcc, когда можно описать, что на входе, на выходе, что изменено кроме этого и какие есть варианты реализации с выбором регистра из заданного набора, или памяти.

Про интринсики — идеологически полный список должен быть тут, может, _lrotl и _lrotr — то, что тебе нужно?

N>>Для cl amd64 запретили инлайнинг __asm{}, как теперь можно получить адрес метки?

N>Это классический пример вопроса, на который надо искать не ответ на заданный вопрос, а решение той проблемы, которую — практически наверняка некорректно — пытаются решить ответом на этот вопрос.

Ну да... прямо таки классический. Действительно кому этот asm нужен, у компилятора есть же оптимизатор!

N>Поэтому глобальный вопрос — а зачем собственно нужен адрес метки?
Очень просто. Я написал виртуальную машину (VM), высокоурвневый ЯП, и компилятор этого языка в bytecode VM.
Есть также небольшое "типа" SDK.
На тех С/С++ компиляторах где можно испоьзовать _asm вставки, я могу внедрить полученный байт код прямо в тело любой функции.
И в конечном "exe" он будет размещен в секции кода. С оптимизатором можно "договориться" прагмами или даже обмануть его.
Адреса меток нужны что бы опеределить откуда VM нкачать исполнять инструкции.
Сейчас портирую это все под 64-битную архитектуру, там _asm вставок нет, прийдется наверно размещаться в секции данных.

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

N>>>Для cl amd64 запретили инлайнинг __asm{}, как теперь можно получить адрес метки?
N>>Это классический пример вопроса, на который надо искать не ответ на заданный вопрос, а решение той проблемы, которую — практически наверняка некорректно — пытаются решить ответом на этот вопрос.
N>Ну да... прямо таки классический. Действительно кому этот asm нужен, у компилятора есть же оптимизатор!

Я вообще-то не про asm, а само по себе взятие адреса метки. Что оно делается в ассемблере — тут менее принципиально.
Исключение ассемблера я не приветствую и считаю, что его причиной явное нежелание сделать по-человечески.
Решение от gcc, конечно, не идеально (я, например, не нашёл, как в нём указать регистр AH в качестве входного или выходного), но практически спасает в >99% случаев.

N>>Поэтому глобальный вопрос — а зачем собственно нужен адрес метки?
N>Очень просто. Я написал виртуальную машину (VM), высокоурвневый ЯП, и компилятор этого языка в bytecode VM.
N>Есть также небольшое "типа" SDK.
N>На тех С/С++ компиляторах где можно испоьзовать _asm вставки, я могу внедрить полученный байт код прямо в тело любой функции.
N>И в конечном "exe" он будет размещен в секции кода. С оптимизатором можно "договориться" прагмами или даже обмануть его.
N>Адреса меток нужны что бы опеределить откуда VM нкачать исполнять инструкции.

VM исполняет инструкции реального x86?

N>Сейчас портирую это все под 64-битную архитектуру, там _asm вставок нет, прийдется наверно размещаться в секции данных.

Или делать исходные файлы на ассемблере.

N>>Ну да... прямо таки классический. Действительно кому этот asm нужен, у компилятора есть же оптимизатор!

N>Я вообще-то не про asm, а само по себе взятие адреса метки. Что оно делается в ассемблере — тут менее принципиально.
N>Исключение ассемблера я не приветствую и считаю, что его причиной явное нежелание сделать по-человечески.
N>Решение от gcc, конечно, не идеально (я, например, не нашёл, как в нём указать регистр AH в качестве входного или выходного), но практически спасает в >99% случаев.

Сори, значит я не правильно понял.

N>VM исполняет инструкции реального x86?
Не, свои.

N>>Сейчас портирую это все под 64-битную архитектуру, там _asm вставок нет, прийдется наверно размещаться в секции данных.
N>Или делать исходные файлы на ассемблере.
Программы написанные для VM используются в основном для проверок ключей, целостности "экзкчины" и всего такого прочего.

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

7>>там ввели какие-то intrinsic функции для этого?

V>Оно?
V>http://msdn.microsoft.com/library/a0w705h5.aspx

Скорее вот это: http://msdn.microsoft.com/en-us/library/26td21ds.aspx

N>>Это классический пример вопроса, на который надо искать не ответ на заданный вопрос, а решение той проблемы, которую — практически наверняка некорректно — пытаются решить ответом на этот вопрос.
7>Всё это, конечно, правильно, но вот полная отмена ассемблерных вставок несколько напрягает. Например, некоторые алгоритмы (вычисление CRC, скремблирование) требуют операции циклического сдвига, сдвига через бит переноса. Может там ввели какие-то intrinsic функции для этого?
Там всегда была возможность писать на полноценном асме, а не инлайном. Она как была так и осталась.

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

N>Очень просто. Я написал виртуальную машину (VM), высокоурвневый ЯП, и компилятор этого языка в bytecode VM.
N>Есть также небольшое "типа" SDK.
N>На тех С/С++ компиляторах где можно испоьзовать _asm вставки, я могу внедрить полученный байт код прямо в тело любой функции.
N>И в конечном "exe" он будет размещен в секции кода. С оптимизатором можно "договориться" прагмами или даже обмануть его.
N>Адреса меток нужны что бы опеределить откуда VM нкачать исполнять инструкции.
N>Сейчас портирую это все под 64-битную архитектуру, там _asm вставок нет, прийдется наверно размещаться в секции данных.

Рекомендую использовать вместо асмовых вставок функции из SDK раз оно уже и так есть. Протектору останется только найти все референсы на эти функции и они то как раз и станут метками для виртуализатора.

V>Рекомендую использовать вместо асмовых вставок функции из SDK раз оно уже и так есть. Протектору останется только найти все референсы на эти функции и они то как раз и станут метками для виртуализатора.
Это мой SDK и мой протектор. Потому и спрашиваю. Я же вроде написал что портирую его сейчас на 64 битную платформу, из этого разве не понятно было?

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

V>>Рекомендую использовать вместо асмовых вставок функции из SDK раз оно уже и так есть. Протектору останется только найти все референсы на эти функции и они то как раз и станут метками для виртуализатора.
N> Это мой SDK и мой протектор. Потому и спрашиваю. Я же вроде написал что портирую его сейчас на 64 битную платформу, из этого разве не понятно было?
Я вам как раз и советую вместо асмовых вставок для вашего протектора использовать функции из вашего SDK. Из этого разве непонятно было? (с)