Comments 9
В грамматике есть ошибка.
«call» может быть подставлен в качестве «statement» и в качестве «expression».
Но «call» не заканчивается на ";"
Поэтому, по грамматике, следующий код валиден
int main() {
f()
g()
}int main() {
f();
g();
}<statement> ::= <block> | <declaration> | ... | <statement-expression>
<statement-expression> ::= <expression> ';'
Не увлечётся ли кто-нибудь стековым языком Factor, чтобы мне было с кем поговорить?
https://andreaferretti.github.io/factor-tutorial/
https://dxdy.ru/topic138111.html
(по второй ссылке лучше читать только george66, остальные не в теме). Пестов (создатель) его бросил и ушёл дуболомить в фирму Apple (это понятно, никто же не оценил). Сейчас копаюсь в компиляторе, пытаясь понять, как проверяется стековый эффект. Точнее, уже понял и теперь хочу улучшить. Factor против C++ как C++ против ассемблера, по ощущениям.
Он мертворожденный. Лучше идти от истоков — взять Forth и адаптировать его к современным реалиям, сделать поддержку многоядерности, добавить в компилятор реалтаймовый статистический оптимизатор (или даже переделать в нормальный JIT — мощности позволяют).
Здорово! Когда будет самокомпилируемый компилятор? =)
все-таки switch-ем оставили интерпретатор. Это плохой подход, так как компилятор может не соптимизировать switch в таблицу, а также на каждую инструкцию генерится по 3 инструкции перехода, которые очень сильно тормозят процессор.
Да, есть такое. Всё-таки это не конечный продукт и пока не обрастёт фичами, ранняя оптимизация мешает наглядности. И если вдруг потребуется использовать в продакшн, обязательно последую вашему совету и оптимизирую VM или буду компилировать в нативный код.
На текущий момент тормоза 1:10 в сравнении C. Что, в принципе, приемлемо для учебного проекта.
еще кстати можно JIT попробовать запилить
Разработка стековой виртуальной машины и компилятора под неё (итог)