как-то писал вариант какого-то васик. стремный он, нет желания хвастаться. еще писал для omgrofl транслятор и интерпретатор (аналогично, предпочитаю чтобы это никто не увидел).
Ну мы писали на курсе компиляторов 'свой язык'. Всё по учебнику, с закосом в сторону llvm.
preprocessor => lexer => parser (ast) => codegenerator (pseudocode в на стэкмашине) => backpatcher => а выхлоп в нужный формат (правда это уже не нами было написано): i386 asm, java byte code, javascript.
А так ничего примечательного: lexer - обычные автоматы, parser - два варианта recursive descent и табличный. Кодогенерация с паттерном visitor.
Исходники не дам, потому как без фрэймворка к которому они прикручиваются они в общем-то бессмысленны, а фрэймворк я права публиковать не имею.
Ой не, нафиг-нафиг. В компиляторах обычно костыль на костыле для реализации стройной системы. А всё от того, что целевые архитектуры ой как разнятся. Да и без этого (имея одну целевую архитектуру, будь-то VM или x86) рука всегда тянется оптимизировать, а оптимизировать и придерживаться хоть какого-то стандарта (даже собственного) - гиблое дело. Потому мало людей, которые будут делиться наработками, одно дело - объём работы, но мы же говорим об opensource, а другое дело - психологический фактор, когда в голове куча парадигм и перфекционизм мешает, тут не до шуток, свой «быдлокод» в этом направлении очень стыдно показывать. Хотя, имхо, в данном конкретном случае стыдиться нечего, т.к. именно в этой сфере можно найти уйму очень интересных хаков (которые нынче брезгливо величают костылями).
Платформозависимые оптимизации делаются на стадии генерации. И там не должно быть костылей - конечные генераторы или вообще разные для каждой платформы или содержат разные правила для разных платформ. Т.е. все на своих местах. Платформонезависимые оптимизации делаются в некотором промежуточном коде и там нет костылей для разных платформ - они там вообще не учитываются.
Еще есть вариант писать код для одной платформы - для llvm, который и будет таким промежуточным языком. Правда тут есть проблема в том, что llvm не до конца платформонезависимый.
Если не нужна нативность, то можно писать под jvm или clr.
Любая достаточно сложная программа на Си или Фортране содержит заново написанную, неспецифицированную, глючную и медленную реализацию половины языка Common Lisp.
исходников нет (в паблике) - не дошёл до пререлиза
писал компилятор в jvm (лень было возиться с нативом + куча плюшек «из коробки») языка с вывернутыми наружу кишками парсера (во всех его стадиях) и, собственно, компилятора, дабы меняя правила (локально или глобально) менять саму компиляцию «как душе угодно». Прототип был написан, попытка переписать его на нём-же подняла на поверхность «административные проблемы», проект [временно] заброшен.
Любая достаточно сложная программа на Си или Фортране содержит >заново написанную, неспецифицированную, глючную и медленную >реализацию половины языка Common Lisp.
Да не, мне же хочется всё вглубь проработать. Функцию копирования строки написать с нуля... Как без этого. Вот я написал и успокоился, теперь можно и нужными вещами заняться.
Типичненько! Похваляться глубокими познаниями в компиляторостроении тут горазд каждый второй школоло, а когда попросили исходники, все тут же заткнулись.
Исходники не дам, потому как без фрэймворка к которому они прикручиваются они в общем-то бессмысленны, а фрэймворк я права публиковать не имею.
Напомнило (только не обижайся) про одного чувака, который в некой рассылке писал, что у него есть вожделенный Meiko FPU, но он ни с кем не поделится, ибо NDA. Смешные вы, думаете, нужен ваш код кому.