Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы		[ Отслеживать ]

Основанные на GCC проекты JIT-компилятора и расширения, испо..., opennews (??), 04-Окт-13, (0) [смотреть все] Чем оно лучше LLVM , Аноним (-), 00:37 , 04-Окт-13, (1) –5 // Килотонны петабайт исходников не надо будет переписывать , pavlinux (ok), 00:45 , 04-Окт-13, (3) +12 // Правильно написанный исходник не нужно бывает переписывать , YetAnotherOnanym (ok), 12:31 , 04-Окт-13, (46) –1 // Да, в случае сферического коня в идеальном вакууме с анекдот , Аноним (-), 12:56 , 04-Окт-13, (50) +4 Нет, в случае нерукожопого программиста Переход FreeBSD на clang показал что та, Аноним (-), 13:58 , 04-Окт-13, (56) –2 напомни, сколько шлангу пришлось из-за этого поддерживать гнутых гцц-шных расшир, Пиу (ok), 15:45 , 04-Окт-13, (65) +4 при этом две самые полезные фичи так и не поддерживает nested functions и state, arisu (ok), 16:06 , 04-Окт-13, (68) +4 а так же дают постоянный исполняемый стек, что открывает простор для написания э, linux must _RIP_ (?), 11:52 , 07-Окт-13, (100) –1 пшёл вон, мразь , arisu (ok), 11:59 , 07-Окт-13, (104) +1 Пошёл gcc патчить, м азь , Andrey Mitrofanov (?), 14:08 , 07-Окт-13, (108) +1 Для кода, не соответствующего стандарту, не может быть оправданий И пофиг, гнут, annulen (ok), 13:04 , 07-Окт-13, (105) –2 мне как-то совершенно плевать на идиотские стандарты стандарт на си особенно ид, arisu (ok), 13:17 , 07-Окт-13, (107) +3 GCC доступен под туеву хучу архитектур и желающие могут впилить туда свою новую , Аноним (-), 12:13 , 10-Окт-13, (149) Наверное это был сам Юрий Нежопорукий что они х рят на своей волне и ни с ке, Аноним (-), 09:29 , 05-Окт-13, (79) +2 это вы о большинстве линуксоидных программистов которые слов c-std , POSIX, S, linux must _RIP_ (?), 11:54 , 07-Окт-13, (101) –2 Это о общей логике развития FBSD Эталонный пример того как не надо рулить проек, Аноним (-), 12:08 , 10-Окт-13, (147) Выше скорость генерируемого кода, поддерживает большое количество платформ, нет , Хрен с горы (?), 00:46 , 04-Окт-13, (4) +15 // в общем, если поскипать бред, то получается, что преимуществ-то и нет Сейчас вс, Аноним (-), 07:57 , 04-Окт-13, (18) –19 // Ну да, кроме вон той толпени корпорасов типа IBM, интелов и еще 100500 всяких, б, Аноним (-), 08:17 , 04-Окт-13, (19) +3 Да ты что, а это что по твоему http www-03 ibm com software products us en cc, 123 (??), 09:54 , 04-Окт-13, (30) Понятия не имею что это Зато догадываюсь чем они собирают ядро линя и софт под , Аноним (-), 12:03 , 04-Окт-13, (43) +2 А почему Oracle Solaris Studio свой компилятор включает Зачем Intel свой компил, Человек (??), 09:55 , 04-Окт-13, (31) –11 Лучше спросите зачем все это покупают И кстати компилятор из Solaris Studio жутк, Аноним (39), 11:27 , 04-Окт-13, (39) +1 Ну да Давайте теперь каждую программу тестировать в разных компиляторах вместо , Аноним (-), 11:43 , 04-Окт-13, (41) Не давайте , а все нормальные люди так и делали всегда, потому что это повышает, Аноним (-), 14:02 , 04-Окт-13, (57) +2 шланг с его хроническими болячками намного проще объявить неподдерживаемым и не , arisu (ok), 15:55 , 04-Окт-13, (66) +3 Жесть как она есть , Аноним (-), 12:05 , 10-Окт-13, (146) справедливости ради это скорее разница в поведении на сборке программы с неопре, arisu (ok), 12:17 , 10-Окт-13, (151) Потому что у санок вечно NIH был Кстати, данный компилер - набор грабель и кост, Аноним (-), 12:28 , 04-Окт-13, (45) +9 gcc не нужен это сильно таких жирнючих троллей ещё не было моё почтени, Клыкастый (ok), 16:17 , 04-Окт-13, (69) +2 Исторические причины значительно лучшая кодогенерация под SPARC Впрочем, есть, Vkni (ok), 18:25 , 04-Окт-13, (74) +1 более того это компилятор, вероятность наличия которого на какой-нибудь хитрой , arisu (ok), 18:34 , 04-Окт-13, (75) +3 Хм, ну покажи мне хоть как-то живую систему, на которую не портирован GCC Пусть, Crazy Alex (ok), 20:40 , 07-Окт-13, (125) Это только если рассматриваем десктоп На планшетах и телефонах вероятность нали, Vkni (ok), 21:13 , 07-Окт-13, (127) А как же виндовс фон Хотя я согласен - лучше считать его за ноль А я думал - , Аноним (-), 12:00 , 10-Окт-13, (143) Тем временем парни из IBM уже запилили LLVM и Clang для Power и System Z , annulen (ok), 13:05 , 07-Окт-13, (106) –2 Осталось всего ничего спустить фанатизм в унитаз и честно сообщить нам сколько , Аноним (-), 12:01 , 10-Окт-13, (144) Вам повторить про более лучшую оптимизацию и большее количество поддерживаемых п, BratSinot (ok), 09:03 , 04-Окт-13, (24) +1 бессмысленно, оно в этом ничего не понимает достаточно пассажа про 171 обфусц, arisu (ok), 15:57 , 04-Окт-13, (67) +2 Что-то НеОбфусцированная архитектура LLVM оказалась настолько не готова к тому ч, Аноним (-), 09:57 , 05-Окт-13, (81) +3 да тут начинать надо с того, что никакой 171 обфусцированой архитектуры 187 , arisu (ok), 10:02 , 05-Окт-13, (83) +2 А с этим никто и не спорит Просто объем маркетингового буллшита текущего из нек, Аноним (-), 11:57 , 10-Окт-13, (142) казалось бы при чём тут огрызок 8230 , arisu (ok), 12:20 , 10-Окт-13, (152) Скоро окажется, что gpu работает наравне с cpu и последний можно убрать Потом о, ssy (?), 00:37 , 04-Окт-13, (2) +4 // Еще лет 7-8 назад один из разрабов Nvidia вывалил на сайте developer nvidia com,, pavlinux (ok), 00:47 , 04-Окт-13, (5) +4 // Не в начале апреля пост был , Аноним (-), 00:52 , 04-Окт-13, (6) // Симшьно, ща уписаюсь http www cs utah edu wbsun gpustore pdf, pavlinux (ok), 00:56 , 04-Окт-13, (7) Кстати, на Опеннете новость была , pavlinux (ok), 01:44 , 04-Окт-13, (10) +1 За вами тоже уже выехали , zhenya_k (?), 11:11 , 04-Окт-13, (36) –2 Извинитесь , Аноним (-), 11:31 , 04-Окт-13, (40) http www opennet ru opennews art shtml num 23833 nVidia Fermi сможет выполнять, Аноним (-), 09:17 , 04-Окт-13, (26) +1 Это завязано на CUDA и блободрайвере, что для ядра сильно-сильно не айс Вот есл, Аноним (-), 11:02 , 04-Окт-13, (35) Какие еще слова знаешь , Аноним (-), 11:54 , 04-Окт-13, (42) +1 Wiki всем доступно, можешь и ты просветиться , Аноним (-), 16:45 , 04-Окт-13, (70) –1 И как именно апи для декодирования видео относится к вычислениям на GPU , Аноним (-), 09:59 , 05-Окт-13, (82) А ещё был более-менее реальный proof of concept червя, живущего исключительно в , vitalif (ok), 00:58 , 04-Окт-13, (8) Это никогда не случится Вы не особо представляете как вообще GPU работает Дл, анонимус (??), 11:17 , 04-Окт-13, (37) +2 Странная эта борьба за новые языки и возможности Все время пытаются сделать лаз, rshadow (ok), 01:38 , 04-Окт-13, (9) +2 // Речь скорее идет о изобретении инструментов переноса старого кода и инструментов, Аноним (-), 03:32 , 04-Окт-13, (12) Отличненько, - горю желанием заценить , jOKer (ok), 03:53 , 04-Окт-13, (13) забавно, конечно, но редкостные извращенцы что этот, что llvm-щики , arisu (ok), 04:33 , 04-Окт-13, (14) // На миллионyю по счету просьбу засветить свой код, который лучше, будет традицион, Аноним (-), 07:22 , 04-Окт-13, (16) // проси на здоровье, за спрос денег не берут , arisu (ok), 14:36 , 04-Окт-13, (59) +2 Предложи более прямой способ сгенерить шейдеры для GPU, например Как ты понимае, Аноним (-), 08:42 , 04-Окт-13, (22) // Вы прям так спрашиваете как будто arisu разбирается в компьютерах и не просто та, Аноним (-), 14:05 , 04-Окт-13, (58) // не мешай ему дилетанствовать c самовлюбленным апломбом, вон уже чуть ниже поток , Аноним (-), 19:21 , 04-Окт-13, (76) –2 пожимает плечами конкретная сущность 8212 это намертво зависающий движок ре, arisu (ok), 19:29 , 04-Окт-13, (77) +6 Красиво приложил Мсье, что вы, как можно, эппл на такие навороты не рассчиты, Аноним (-), 11:34 , 05-Окт-13, (84) +1 вот, кстати, только что в списке рассылки Lua пришло , arisu (ok), 12:09 , 05-Окт-13, (90) Справедливости ради - почитай логи коммитов к амдшному окрытому драйверу GCC, Аноним (-), 11:55 , 10-Окт-13, (141) так я и на gcc-шные баги наступал как-нибудь под настроение 8212 если вспомн, arisu (ok), 12:04 , 10-Окт-13, (145) Это какая версия компилятора Т е кодstruct z_t int a int b inline vo, Vkni (ok), 19:31 , 05-Окт-13, (95) 3 3 не знаю и проверять лень там функция несколько сложнее, возвращает тоже стр, arisu (ok), 19:37 , 05-Окт-13, (96) +1 Выкладывай отпрепроцессенный файл и опции компиляции, я проверю , annulen (ok), 14:33 , 07-Окт-13, (109) –1 Не выложит, это принципиально Будет тот же графоманский поток околокомпьютеорны, Аноним (-), 21:08 , 07-Окт-13, (126) –1 Милый Аноним, вы тоже не понимаете, что заниматься социальными игрищами, надев м, Vkni (ok), 21:38 , 07-Окт-13, (131) +1 http www opennet ru openforum vsluhforumID3 91996 html 133, Vkni (ok), 21:58 , 07-Окт-13, (134) ты мне гешефт поломал, кстати я-то надеялся, что денег дадут за сэмпл , arisu (ok), 22:03 , 07-Окт-13, (137) В том виде, что ты написал, это очень похоже на неопределённое поведение Причём, Vkni (ok), 21:19 , 07-Окт-13, (128) –1 я про си и говорил нулевую польза 8212 это если бы меня преупреждением обруг, arisu (ok), 21:31 , 07-Окт-13, (129) Стат анализатор у clang а говно, хотя попробуй, прогони его, авось ругнётся А , Vkni (ok), 21:37 , 07-Окт-13, (130) его, вроде, отдельно собирать надо потом попробую как-нибудь, git всё помнит, е, arisu (ok), 21:56 , 07-Окт-13, (132) +1 Уже не надо - http www opennet ru openforum vsluhforumID3 91996 html 133, Vkni (ok), 22:00 , 07-Окт-13, (135) Программа 8 ---------------------------------------------- 8typedef struct SSS, Vkni (ok), 21:57 , 07-Окт-13, (133) благодарю могу от себя добавить, что gcc 4 8 1 на x86 тоже никаких ворнингов не, arisu (ok), 22:00 , 07-Окт-13, (136) предлагаю унифицировать промежуточную VM для оных GPU, а драйвера пусть при нео, arisu (ok), 14:41 , 04-Окт-13, (60) // Уже была попытка, кстати Называлось сие TGSI, см http people freedesktop org, Аноним (-), 11:50 , 05-Окт-13, (85) как я уже сказал 8212 тут две отдельные ветки беседы надо JIT в одну сторону, arisu (ok), 11:56 , 05-Окт-13, (87) +1 Компиляция шейдеров во время выполнения происходит, по поводу чего не вижу глоба, Аноним (-), 13:18 , 05-Окт-13, (91) –1 это потому, что про JIT-ы ты тоже знаешь только три символа, как и про X11 остал, arisu (ok), 15:10 , 05-Окт-13, (93) +1 Да это пофигу - общую суть затеи с шейдерами и CL ядрами я усек и вижу что народ, Аноним (-), 11:41 , 10-Окт-13, (138) я заметил только вот беда это не JIT, это кросс-компиляция 171 не в лотерею,, arisu (ok), 12:11 , 10-Окт-13, (148) Для си-подобных языков это не мегаизвращение, а наиболее естественный метод JIT-, annulen (ok), 14:37 , 07-Окт-13, (111) –1 8212 алё, Хьюстон, у нас проблемы воробей 8212 спокойно, уже везём ядерну, arisu (ok), 14:50 , 07-Окт-13, (112) +1 Проще взять готовый фронт-енд для С-подобных языков и готовый бэкэнд для JIT, че, annulen (ok), 15:17 , 07-Окт-13, (113) –1 8212 а пользователь 8212 а нам какое дело купит процессор поновее и ещё 1, arisu (ok), 15:19 , 07-Окт-13, (114) +1 угу, для питона, руби, перла, пэхапе - первые будут потом всякие тикли, APL и пр, Аноним (-), 07:21 , 04-Окт-13, (15) // не особо и вообще, для многих 171 динамических 187 языков AOT-компилятор , arisu (ok), 14:51 , 04-Окт-13, (61) +1 Я может быть чего-то не понимаю, но Gentoo вроде бы давно придумали И компилятс, Vkni (ok), 07:30 , 04-Окт-13, (17) –4 // Вы вообще нихрена не понимаете И гентушники тут ни о чем Что есть у гентушнико, Аноним (-), 08:39 , 04-Окт-13, (21)   // действительно, то ли дело 8212 прямо в драйвер вкорячить немеряных размеров б, arisu (ok), 15:01 , 04-Окт-13, (64) +1   // Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc , Vkni (ok), 18:16 , 04-Окт-13, (72)   да и памяти оно тоже кушает при этом libjit 8212 если выкинуть вливы 8212 , arisu (ok), 18:24 , 04-Окт-13, (73) +1   В gcc 4 8 вроде как потребление памяти заметно скостили, правда там в основном н, Аноним (-), 11:55 , 05-Окт-13, (86)   jit-компилятором однозначно не надо, jit-ы не для этого совсем придуманы оно ещ, arisu (ok), 12:06 , 05-Окт-13, (89)   Мда, и кто-то еще заикается про малое количество архитектур, поддерживаемых LLVM, annulen (ok), 18:37 , 07-Окт-13, (120) –1   Оно достаточно близко по смыслу имхо - код для GPU генерится на лету, по ходу вы, Аноним (-), 11:49 , 10-Окт-13, (139)   оно совершенно далеко и по смыслу, и по целям, и по требованиям и вот ты как ра, arisu (ok), 12:15 , 10-Окт-13, (150)   Использовать gcc для jit какая-то нелепость при наличии llvm , Аноним (-), 20:34 , 04-Окт-13, (78) // не большая, чем использовать для этого llvm , arisu (ok), 09:35 , 05-Окт-13, (80) –1 То, что ребята пошли по пути LLVM не может не радовать Вот только они опоздали , lucentcode (ok), 13:20 , 05-Окт-13, (92) // Особенно классно с LLVM сношались амдшники, которые добрых 2 года пытались убе, Аноним (-), 11:52 , 10-Окт-13, (140) а вот это уже интересно, хрюкотающий зелюк (?), 23:27 , 06-Окт-13, (97) –2 1,2,9,13,14,15,17,78,92,97

Сообщения

[Сортировка по времени | RSS]

	21. "Основанные на GCC проекты JIT-компилятора и расширения, испо..."	+/–
	Сообщение от Аноним (-), 04-Окт-13, 08:39
	Вы вообще нихрена не понимаете. И гентушники тут ни о чем. Что есть у гентушников для того чтобы, например, вгрузить шейдер в GPU, предварительно скомпилив его, ась? И да, драйверу GPU например несколько не комильфо стартовать новые процессы с компилером. Функцию библы позвать - еще куда ни шло. Ну а программа (OpenGL/OpenCL/...) не может заранее знать какой там у вас GPU и как под него шейдеры генерить. Поэтому все что оно может - попросить "а скомпильте мне это и запустите", ну а дальше уже драйвер и бэкэнд кодогенерации будут разбираться как "это" превратить в команды понимаемые "вон тем" GPU, который в системе есть. Аналогично - везде где надо скрипты или байткод выполнять, они тормозят если их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора. А если все заранее в нативный машинный код перегнать и выполнять его - можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов - не надо заранее знать какая платформа + нет видимой програмеру фазы компиляции под каждую конкретную платформу. От компиляторов - скорость выполнения типичная для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли на юзеря. Это чем-то похожа на гентушников :))) но совсем не в том виде каком они себе это представляли.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok), 04-Окт-13, 15:01
	> И да, драйверу GPU например несколько не комильфо стартовать новые процессы > с компилером. Функцию библы позвать — еще куда ни шло. действительно, то ли дело — прямо в драйвер вкорячить немеряных размеров библиотеку компилятора. это же так секурно, а память вообще экономит прямо влёт: пользователь же каждую наносекунду какой-нибудь шэйдер компилирует! намного разумней как раз отдельные процессы, стандартизованый язык и универсальный способ вызова компилятора. и не нужно таскать с собой костыли: большинство софта будет вызывать оный компилятор при установке, заранее собирая шейдеры под GPU, который на борту. и оставшаяся небольшая часть — вызывать по мере необходимости. that's all, folks! > Аналогично — везде где надо скрипты или байткод выполнять, они тормозят если > их интерпретировать, т.к. полезная логика всегда сильно разбавлена логикой интерпретатора. > А если все заранее в нативный машинный код перегнать и выполнять > его — можно сочетать достоинства компиляторов и интерпретаторов. От интерпретаторов — > не надо заранее знать какая платформа + нет видимой програмеру фазы > компиляции под каждую конкретную платформу. От компиляторов — скорость выполнения типичная > для компилированного кода. Просто фазу окончательной компиляции в нативный код снесли > на юзеря. Это чем-то похожа на гентушников :))) но совсем не > в том виде каком они себе это представляли. а этот пассаж вообще офигительно смешон. сразу видно человека, который проблематику JIT-компиляторов для «динамических» языков не понимает вообще. максимум — что-то там слышал краем уха, и уверен, что AOT-компилятор завсегда лучше JIT в любой области. и что полновесный AOT-компилятор типа GCC — это такая мелочь, оверхэд от которой вообще не стоит упоминания. ещё раз отправляю тебя внимательно смотреть на LuaJIT2. и на то, как происходит кодогенерация в GCC и сколько все его фазы весят (как в плане памяти, так и в плане скорости). это для начала.
	Ответить | Правка | Наверх | Cообщить модератору

	72. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Vkni (ok), 04-Окт-13, 18:16
	> а память вообще экономит прямо влёт: > пользователь же каждую наносекунду какой-нибудь шэйдер компилирует! Меня, если честно, беспокоит вопрос времени - gcc -O2 значительно тормознее gcc -O0. Т.е. фаза оптимизации занимает очень существенное время. А JIT должен быть всё-таки достаточно быстр. Ну, либо придётся ограничиться предкомпиляцией с сохранением результатов (но это и есть вариант Gentoo).
	Ответить | Правка | Наверх | Cообщить модератору

	73. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+1 +/–
	Сообщение от arisu (ok), 04-Окт-13, 18:24
	да и памяти оно тоже кушает. при этом libjit — если выкинуть вливы — весит значительно меньше, работает сильно быстрее и выдаёт достаточно неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (-), 05-Окт-13, 11:55
	> да и памяти оно тоже кушает. В gcc 4.8 вроде как потребление памяти заметно скостили, правда там в основном на LTO вроде непирали. > при этом libjit — если выкинуть вливы — Гыгы, действительно, нафиг надо генерить код под GPU? Отдадим шлангу на откуп? :) > весит значительно меньше, работает сильно быстрее и выдаёт достаточно > неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации. Звучит довольно вкусно.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok), 05-Окт-13, 12:06
	>> при этом libjit — если выкинуть вливы — > Гыгы, действительно, нафиг надо генерить код под GPU? jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы. >> весит значительно меньше, работает сильно быстрее и выдаёт достаточно >> неплохой код. вдобавок имеет интерпретатор для архитектур, где нет кодогенерации. > Звучит довольно вкусно. оно ещё вкуснее, на самом деле, потому что на вход libjit'у подаётся почти классический SSA. то есть, распределением регистров, уничтожением лишних временных переменных и прочей «низкой» механикой занимается сама libjit. и это действительно удобно. и ещё там есть плюшки для перекомпиляции уже раз отджитеной функции, при этом с поддержкой многопоточности. то есть, сам компилятор только в одном потоке может работать, но: пока мы упорно занимаемся перекомпиляцией, другие потоки спокойно используют старую версию функции. а потом libjit заменит её на новую. при этом позаботившись о том, чтобы ничего не упало и не сглючило, если какой-то другой поток в это время всё ещё находится в старом варианте. «из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств, где может понадобиться, охвачено. да и создание нового бэкэнда не ракетная наука.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Основанные на GCC проекты JIT-компилятора и расширения,..."	–1 +/–
	Сообщение от annulen (ok), 07-Окт-13, 18:37
	> «из коробки» оно умеет x86, x86_64 и arm. Мда, и кто-то еще заикается про малое количество архитектур, поддерживаемых LLVM.
	Ответить | Правка | Наверх | Cообщить модератору

	139. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от Аноним (-), 10-Окт-13, 11:49
	> jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы. Оно достаточно близко по смыслу имхо - код для GPU генерится на лету, по ходу выполнения программы. Обычный компилер на такое дергать - полное извращение. > спокойно используют старую версию функции. а потом libjit заменит её на > новую. при этом позаботившись о том, чтобы ничего не упало и > не сглючило, если какой-то другой поток в это время всё ещё > находится в старом варианте. Хорошо придумано, не отнять. > «из коробки» оно умеет x86, x86_64 и arm. то есть, подавляющее большинство устройств, А как насчет MIPS и PPC?
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	150. "Основанные на GCC проекты JIT-компилятора и расширения,..."	+/–
	Сообщение от arisu (ok), 10-Окт-13, 12:15
	>> jit-компилятором? однозначно не надо, jit-ы не для этого совсем придуманы. > Оно достаточно близко по смыслу имхо — код для GPU генерится на > лету, по ходу выполнения программы. Обычный компилер на такое дергать — > полное извращение. оно совершенно далеко и по смыслу, и по целям, и по требованиям. и вот ты как раз предлагаешь «дёргать обычный компилер», только через задницу. > А как насчет MIPS и PPC? они ждут своих героев. изначально libjit делаласть для DotGNU, чего там на мипсах ловить? но оно и ARM не умело тоже. потом научили. а MIPS и PPC пока никому не понадобились, видимо. научи — будет круто. иначе, как понимаешь — интерпретатор.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема