Динамическая генерация кода

Совсем уже народ обленился, трансляторы влом писать

Велосипедостроительством не хочется заниматься. Тем более для x86.

Вызов as не катит, не? На вход ассемблер, на выход — объектник. Поздравляю, ты решил задачу за 5 минут. А так бы полгода еще промучился со своим велосипедом.

Нужна динамическая генерация кода в ран-тайм для ускорения некоторых операций, типа небольшой JIT. Какой нафиг as?

Костыльный метод есть в Qemu, но проще заново написать, чем что-то оттуда выдрать.

>Существует-ли библиотека, которой на вход подается ассемблерная инструкция в виде текстовой строки (x86), а на выходе получается соответствующий бинарный код.

То, что ты попросил в вопросе, то as и сможет тебе обеспечить. Быстро и качественно. Никто тут не упрекнет меня, что я не ответил на этот вопрос.

Нужна динамическая генерация кода в ран-тайм для ускорения некоторых операций, типа небольшой JIT. Какой нафиг as?

Вызывай as из твоей программы в рантайм. И в рантайм же читай полученный код и используй его по своему усмотрению.

http://uebb.cs.tu-berlin.de/harpy/

libtcc (tiny c compiler) - на входе C код

если ассемблер - то можно взять из binutils - libbfd libopcodes

А именно ассемблер? Просто динамическая компиляция не устроит?

Скажем, в лиспе:

 (compile nil `(lambda (x y z) (+ x y z))) => #<FUNCTION (LAMBDA (X Y Z)) {1002C7A409}> 

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

Для Tcl есть tcltcc, встроенный Tiny C Compiler. То самое делает, можно в рантайме генерить и компилировать функции, единственно, там не asm, а Си. Хотя может, inline asm там и есть, не пробовал вставлять.

Плюс objcopy для преобразования из *.o в raw binary.

Требуется БЫСТРАЯ (иначе сталбы я заморачиваться с динамической компиляцией) работа, а ты предлагаешь дергать внешние программы, которые не факт что стоят на целевой системе. Вот это велосипед так велосипед.

http://hackage.haskell.org/package/harpy

>Требуется БЫСТРАЯ (иначе сталбы я заморачиваться с динамической компиляцией) работа

Это будет не сильно медленнее, чем вызов библиотеки из *.so, которая тоже должна будет обработать текстовые входящие данные. И не факт, что сделает это лучше as. Только первый вызов as будет помедленнее, а потом уже быстро будет. Плюс ко всему ты получаешь возможность генерировать код на разные процессоры.

Если тебе надо быстро, то зачем тогда решается задача генерации *текста*, затем перевода его в код, когда надо генерировать сразу код. А это потому, что тебе проще сгенерировать текст. Ты же сознательно пошел в этом плане на замедление, пойдя через один лишний этап. Значит, тебе придется в любом случае вызывать какой-то тренслятор из текста в бинарный код. И все они этот будут делать примерно одинаково.

Вся беда нашего отечественного программирования в том, что отсутствует понятие прототипирования. Ты уже можешь двигаться дальше, решив задачу и получив результат. А сейчас ты сядешь на долгое время со своим premature optimization.

http://hackage.haskell.org/package/harpy

http://www.linux.org.ru/jump-message.jsp?msgid=4451398&cid=4451543

А нафига это надо?

>Нужна динамическая генерация кода в ран-тайм для ускорения некоторых операций, типа небольшой JIT.

Ну так может и смотреть на JIT-библиотеки?

TinyCC

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

Оптимизация производится для готовой программы с выявлеными местами тормозмв.

На Форте пишется за ночь. Сам движок за полчаса-час и ещё сколько-то времени, чтобы вбить и проверить все опкоды.

Да я понимаю, но в x86 дофига всяких исключений, которые уроешься проверять.

Вот потому и за ночь (несколько часов) пишется, а не за час :)

...

Это реальная практика - я под Forthius32 когда-то так Форт-ассемблер писал. Плюс добавил линковку .obj на лету - удобно было :) (времена были DOS'овские, про .dll ещё никто не слышал, про .so - тем более)

> ты предлагаешь дергать внешние программы, которые не факт что стоят на целевой системе.

Что бы тебе не предложили использовать, на целевую систему это придется ставить тебе самому.

К tcc добавлю GNU Lightning (хотя проект вроде почти помер).

Тогда уж сразу LLVM

К tcc добавлю GNU Lightning (хотя проект вроде почти помер).

Мне вот интересно, что за задача, в которой такое потребовалось?

> Тогда уж сразу LLVM

Для сформулированных ТС целей вообще нужен as.

>> К tcc добавлю GNU Lightning (хотя проект вроде почти помер).

Мне вот интересно, что за задача, в которой такое потребовалось?

JIT для Лиспа :-P

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

Так проще действительно написать самому.

JIT для Лиспа :-P

Дык, в Лиспе компилятор из поков веков доступен в рантайме.

Вот что-то типа такого: http://bitbucket.org/cheery/g386/overview/

Только оно без напильника не заводится, но хоть что-то.

>Требуется БЫСТРАЯ (иначе сталбы я заморачиваться с динамической компиляцией) работа,

Языки желательно C, Python,

Python

Что-то у меня не сочетается. :)

Действительно, расскажи, зачем это надо?

> Что-то у меня не сочетается. :)

Перепишу сам на си. Но переписывать с хаскеля - это слегка изврат.

> Действительно, расскажи, зачем это надо?

Нужно код для специфического МК запустить на PC с как можно большей скоростью в нескольких десятках экземпляров. Простая интерпретация работает, но тормозит. Хочется сделать аналог того что есть qemu. Но когда я ее последний раз смотрел они собирали код по кусочкам и сильно зависили от версии GCC. Сейчас вроде что-то поменялось, но похоже пролемы все-равно есть.

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

>Нужно код для специфического МК запустить на PC с как можно большей скоростью в нескольких десятках экземпляров.

Я все-равно не понимаю, откуда требование преобразования в run-time? Почему нельзя этот код для МК преобразовать в бинарь целевой платформы до ее запуска? Почему нельзя переписать VM для этого МК, чтобы была более быстрой?

>Так проще действительно написать самому.

+1

Ниче там сложного нету

> > Действительно, расскажи, зачем это надо?

Нужно код для специфического МК запустить на PC с как можно большей скоростью в нескольких десятках экземпляров. Простая интерпретация работает, но тормозит.

Какой МК??

И второе, вы что, генерите этот код на лету? Если нет, то просто сгенерь вариант для х86 один раз и всё.

МК уммет модифицировать свой код на лету, нужно отслеживать и часто перекомпилировать. Возможно что-то удастяся вынести в статическую часть и скомпилировать до исполнения, но ран-тайм компилятор нужен будет все-равно.

частично, а не часто.

А потом нужно несколько таких VM запустить в рамках одного процесса и управлять ими. Точки «вклинивания» управляющей программы - так же как и в qemu, все инструкции переходов.

tcc - Tiny C Compiller - куда проще то? Подключается как библиотека. Потом пихшаешь фукнции свой код, inline asm там поддерживается. Потом получаеш указатель на сгенерированный код и запускаешь. Вот уж легче и человечнее сложно придумать.

Возьмите какую-то существующую VM (Mono или упомянутый выше LLVM), допишите вещи спецефичные для МК и транслируйте код МК в байт-код хостовой машины. И не мучайтесь)

>> JIT для Лиспа :-P

Дык, в Лиспе компилятор из поков веков доступен в рантайме.

В том лиспе, к которому прикрутили Lightning (cLisp - «си-лисп»), компилятор только в байткод, который есть low-level всё те-же s-expr's.

В том лиспе, к которому прикрутили Lightning (cLisp - «си-лисп»), компилятор только в байткод, который есть low-level всё те-же s-expr's.

В SBCL, CMUCL, Clozure CL испокон веков компиляция в машинный код.

(disassemble
 (compile
  nil
  `(lambda (x y z)
     (declare (optimize (speed 3) (debug 0) (safety 0))
              (type fixnum x y z))
     (the fixnum (+ x y z)))))

; disassembly for (LAMBDA (X Y Z))
; 03C7046B:       4801FA           ADD RDX, RDI               ; no-arg-parsing entry point
;       6E:       4801F2           ADD RDX, RSI
;       71:       48C1E203         SHL RDX, 3
;       75:       488BE5           MOV RSP, RBP
;       78:       F8               CLC
;       79:       5D               POP RBP
;       7A:       C3               RET

Ну так не «в Лиспе» вообще, а всего-лишь в некоторых реализациях - не?

да нет, как раз clisp это скорее исключение

>Ну так не «в Лиспе» вообще, а всего-лишь в некоторых реализациях - не?

Сферические языки в вакууме не интересны для решения конкретных задач. Они интересны лишь вместе с компиляторами/интерпретаторами/etc.

>да нет, как раз clisp это скорее исключение

согласен, но это не даёт права применять «квантор всеобщности» :)

GNU Lightning емнип используется в GNU Smalltalk для JIT

Вот еще http://luajit.org/dynasm.html