Lumber room
Comments 17
0
Кстати, интересный момент есть — взаимодействие LLVM с .NET.

Я обнаружил, что подходящий для вызова .NET-методов calling convention — это LLVMX86FastcallCallConv, для вызовов в обратную сторону — System.Runtime.InteropServices.CallingConvention.Winapi.

Не понятно только, насколько это универсально, и гарантировано ли будет работать в будущем.
0
Как Вы это обнаружили? Свой биндинг есть?

Кстати, если посмотреть код моего, будет видно, что обращение к LLVM идёт через Cdecl (что логично, т.к. я использую биндинг к Си). Это на 32-битной архитектуре. На 64-битной в Windows есть только одно соглашение о вызовах.

Как будет вызываться полученный делегат зависит от атрибута UnmanagedFunctionPointerAttribute, если он есть. По умолчанию вроде используется stdcall (как в WinAPI).
0
У меня есть свои биндинги LLVM к .NET, генерятся автоматически с помощью XML-вывода Clang. Они используются в моем компиляторе Си, я про него сегодня собирался пост писать.

Я говорю о вызове функций, скомпилированных JIT-ом LLVM из .NET (инструкция Calli, очевидно у вас так же) и вызове статических методов .NET из кода, сгенеренного LLVM (по указателям, полученным инструкцией Ldftn). Почему-то у меня Cdecl не работает.
0
Всё-таки GetDelegateForFunctionPointer — более предпочтительный вариант, т.к. позволяет явно указывать соглашение о вызовах.

Не поделитесь своим биндингом для сравнения?
0
Мне не нужен тормозной делегат, дернуть напрямую за calli я и сам могу.
0
Код своих биндигов и компилятора выложу чуть позднее сегодня.
0
Простите за нескромный вопрос, но зачем все это надо, когда есть System.Reflection.Emit + System.Linq.Expressions?
0
В моём случае это — попытка реализации CLR, написанная на одном из языков CLR.
0
LLVM существенно ниже уровнем, чем CLR. Так что нельзя даже сравнивать, у них абсолютно непересекающиеся применения.
0
Да я бы так не сказал, кстати. Уверен, в большинстве случаев Reflection.Emit успешно заменит LLVM.
0
Смотря каких случаев. LLVM — для unmanaged, CLR — для всего, что managed. Так что оптимальный вариант — смешивать их, а не пытаться на одном дела то, что лучше получается у другого.
0
CLR вполне можно использовать для unmanaged. Вот использовать LLVM для managed без VMkit тяжело.
0
Это как это?

Нельзя с CLR сделать небольших размеров standalone executable. Нельзя сделать callback, эффективно вызываемый из unmanaged. Нельзя без очень жесткого оверхеда вызывать unmanaged функции. P/Invoke — тот еще тормоз, да и calli не лучше.

0
Ну со standalone ещё более-менее понятно. Но зачем часто делать переходы unmanaged-managed?
0
Как зачем? Если надо генерить код, зависящий от unmanaged библиотек, то как бы вариантов и нет.
0
Посмотрите мой последний пост в ненормальном программировании, там пример такого смешивания clr и llvm.
Only those users with full accounts are able to leave comments. , please.