Компилятор PHP в байт код Си

Си написан на Си, на асме там совсем немного. А вот php преобразовывать в си зачем? У них синтаксис и так похож. Ну если хочется, можно посредством include - файлов сделать си-программы еще более похожими на php, можно сделать препроцессор php-си. Наверняка такие существуют, можно порыться в интернете.

Alipapa, не надо меня цитировать, это был стеб :)

Вы так жжете, что даже лениво комментировать:) Если бы то, что Вы предлагаете было нужно больше чем оно сложно, то оно давно было бы сделано. Да и любители компиляции должны бы давно посмотреть на asp.net и иже с ними, смысл изобретать что-то на php?

Но вот ответы Вам показались нам достаточно интересными для коммента.

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

Зачастую не проще. Зачастую проще наваять php-кодерами проект, а потом отдать переписывать узкие места Си-шникам, чем изначально использовать Си (для этих узких мест или целого проекта).

Уже не раз замечали, как в других топиках Вы так же безаппеляционно жжете:) Вот честно, не понимаем Вас, Вы иногда говорите просто откровенно неверную информацию преподнося ее как факт, зачем? При чем настолько неверную, что даже возражать Вам лениво. Этот топик не самый яркий тому пример, но раз уж мы тут отвечаем, не удержались от вопроса.

Да, безусловно операции с БД могут занимать до 95% времени. Но в "среднестатическом" (отбрасываем уникальные и редкие) проекте 95% времени на БД это просто признак криворукости человека, писавшего запросы в БД.

Но аргумент у Вас частично верный. Время на php-код действительно занимает, ну положим не больше 50% в "среднестатических" проектах, поэтому даже ускорив php код в бесконечное количество раз, весь проект больше чем в 2 раза не ускорится.

Однако Вы упускаете здесь 2 момента: а) Время выполнения не связано напрямую с нагрузкой на сервер, при бОльшем времени выполнения скрипт может давать меньшую нагрузку (проверяли) б) Поедание памяти, пхп код имеет честь откушивать зачастую на порядок больше времени на те же операции при выполнении, да и даже простой инклудинг файла уже жрет память нехило.

:))) Про объявление зачет:) А где первый рассадник, мы пропустили?:)

Честно говоря от Вас слегка удивлены такое услышать. По программингу Вы всегда выражались предельно правильно. Вообще этот аргумент про "невозможность компиляции языков с нестрогой типизацией" мы встречаем уже не первый раз и каждый раз нам непонятно, откуда корни у этого пошли.

Что делать компилятору? Да то же что интерпретатору. Типов переменных ограниченное количество. Генерить разный код в зависимости от типа переменных. Неужели для кого-то сюрприз, что можно написать на компилируемых языках функцию, которая будет выполнять разный код в зависимости от типа передаваемой в нее переменной? Задача ведь та же самая, в зависимости от типа - выполнять действия по разному, и при этом он все еще останется компилятором. Да, компилятор будет сложнее, а что, разве компилятор должен быть прост как космический корабль на паровом двигателе?:)

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

Над этим вопросом лучшие теоретические умы планеты давно бьются

http://au2.php.net/manual/en/intro.bcompiler.php

Начинать здесь новую дискуссию - по крайней мере неграмотно.

Pike, а практические умы давно продают zend guard.

Хотел бы я посмотреть, во что превратиться откомпилированный код, каждая из переменных которой в каждый момент времени в каждом месте упоминания может иметь разный, иногда непредсказуемый, тип. А с интерпретацией всё нормально: интерпретатор видит значение и подбирает обработчик налету.

верите или нет, но я запросто напишу eval на с++ ( не все с++ одинаково полезны :) )

BoyStav добавил 28.01.2009 в 02:47

void* решит проблему, ну или более модная его реализация...

class variant

{

void* value;

...

some operators and methods

...

}

и жизнь удалась, да реализовать класс будет трудновато, но работатать как раз и будет как компилятор :)

Не в каждый момент времени, а только в тот момент времени, когда идет то или иное обращение к переменной. По поводу "непредсказуемого типа" это что-то странное, это как в анекдоте "кто родился? мальчик? нет! а кто?!?!?!?!?!" (с)

Дальше.

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

Да, это конечно не идеальный выход, но это отнюдь не "непреодолимое препятствие" которым обычно это изображают. И ни в коем случае не превращает компилятор в интерпретатор (несмотря на действия в зависимости от типа), т.к. результат всё равно байт-код, пусть даже немного раздутый.

Во-вторых, если вернуться от "абстрактного" разговора к конкретному. В php вообще нету типов int, double, float и так далее как таковых. Там есть один единственный тип - zval (по сути структура или даже скорее класс если говорить в си терминологии). Так что - нет разных типов - нет проблемы типизации. Это конечно сильно утрированное и упрощенное изложение, но тем не менее в общем и целом верное.

Позволим себе процитировать

http://php.find-info.ru/php/016/ch20lev1sec2.html (да и вообще рекомендуем этот учебничек полистать, нам нравится:) )

To fully understand types in PHP, you need to look under the hood at the data structures used in the engine. In PHP, all variables are zvals, represented by the following C structure:



struct _zval_struct {

  /* Variable information */

  zvalue_value value;     /* value */

  zend_uint refcount;

  zend_uchar type;        /* active type */

  zend_uchar is_ref;

};



and its complementary data container:



typedef union _zvalue_value {

  long lval;              /* long value */

  double dval;            /* double value */

  struct {

    char *val;

    int len;

  } str;                  /* string value */

  HashTable *ht;          /* hashtable value */

  zend_object_value obj;  /* handle to an object */

} zvalue_value;

P.S.: Т.е. мы как бы не хотим сказать, что компилятор для пхп набросать легко и просто и на коленке за 5 минут. Просто в данном случае, мы говорим именно о том, что отсутствие строгой типизации в php не является непреодолимым препятствием

вообще тема жесткая, нельзя так пузо порвал уже...

когда меня учили, то было 3 определения, а не 2 как сейчас в ходу.

1) Компилятор - преобразует код написанный на ЯВУ в машинный код и не важно, что это за машина, реальный процессор или виртуальная машина.

2) Интерпретатор обрабатывает (компилирует, но не всегда) код строка за строкой, исполнение текущей строки, влияет на контекст компиляции следующей строки.

3) Транслятор полная или частичная компиляция перед выполнением, выполнение компелированного кода не влияет на контекст компиляции последующего.

PHP не занимается переводом своих скриптов в С, он просто компилирует сырцы в псевдокод, который может исполнять ядро.

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

В общем пионеры, учите матчасть, блин как запарило уже тупое желание детей поиметь все чужими руками.

Однако есть еще всякие Haskell ;)