- =A=L=X=
- Постоялец
Я уже не в первый раз задумываюсь о такой возможности, идея заключается в следующем:
1. Используем укороченный набор инструкций процессора. Для этого смотрим классические конструкции опкодов, используемые в основных классических конструкциях циклов, арифметики и т.д. Выбираем наиболее оптимизированные варианты, следим какие использовать регистры, а дальше используем как шаблон и не паримся. Генерация опкодов и наполнение секций EXE-файла - не такое уж и сложное занятие, этим я когда-то попробовал побаловаться: http://tmtlib.narod.ru/files/peasm-0.3beta.zip
2. Делаем вывод формы не классическими средствами, а с помощью BitBlt. Т.е. как у Blender, но даже без OpenGL. Реализуем основные элементы: поле для ввода, кнопку, список, может ещё чего. (Никто не мешает потом на основе самого языка выводить "костыли" с помощью BitBlt: ползунки и т.д.).
3. Ограничиваем разнообразие типов. Пусть это будет 32-bit integer, 32-bit float и string. Соответственно, уменьшаем количество опкодовых шаблонов по преобразованию типов и всяких конструкций.
Как программа дорастёт до приличного уровня, переписываем IDE на свой язык и компилируем. IDE типа как у "Delphi 1" (погуглите картинку). По идее на этом хозяйстве можно будет делать 3D демки в софтваре и прочую мелочь. Стандартные конструкции можно вытаскивать в дизассемблере из кода, генерируемого Delphi или C++, переделывать в свои опкодовые шаблоны, подгоняя регистры и стек в нужном направлении. Как вам идейка?
p.s. Есть ощущение, что нечто подобное уже реализовано, но возможно на экзотической платформе и т.д.
А в чем преимущество перед "серьезной" IDE?
Работы много, смысла - мало.
tmtlib
Ты тоже скриптами и своими языками решил увлечься?
Тогда Форт что ли.
Я вот тоже свой язык лабаю, пока архитектуру пытаюсь пооптимальнее сделать. Хочу свести интерпретатор к тупому
for i := Low(P) to High( P) do P[i]( );
Пока что я нарвался на такую проблему - я передаю по ссылке член структуры в функцию, которая в качестве побочного эффекта перемещает структуру в другое место. Поэтому я решил больше не передавать ничего по ссылке, а использовать функции, возвращающие сложную структуру из результата.
т.е. вместо
a := f(b);
писать
with f(b) do begin a:=res_a; b:=res_b; end;
Начинаем...
COMPILER gmaker
CHARACTERS
letter="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ_".
digit="0123456789".
cr="\r".
lf="\n".
tab="\t".
ws=" ".
TOKENS
IDENT = letter {letter | digit}.
INT = digit {digit}.
COMMENTS FROM "#" TO cr lf
IGNORE cr + lf + tab + ws
PRODUCTIONS
gmaker = {stmt} EOF.
/*
stmt =
...
Здесь нужно написать что-то ещё,... что-то загадочное и шибко заумное.
*/
END gmaker.правка:
Ну и с кодогенерацией особо возиться смысла нет (если только для спортивного интереса), - LLVM позволяет делать все проще (плюс лёгкий интерфейс к Си либам и очень неслабые возможности оптимизации сгенерированного кода).
Я же тоже хочу написать свой простенький язык и простенькую ide :) Желаю автору удачи :)
Кстати, мне осталось реализовать аргументы функции, ее вызов и пару управляющих конструкций :)
А в идеале, переписать компилятор на сишку, а то он у меня, внимание, на гейм мейкере.
TarasB
Можно увидеть оп-коды твоей ВМ? У меня их сейчас около 30, из специфичных, пожалуй, только 3 из них, предназначеных для работы с стеком локальных переменных (классная кстати, штука получилась)
"Свое", "родное" и пахнет приятней и в унитазе не тонет.
Bizunow
> Можно увидеть оп-коды твоей ВМ?
У меня нет опкодов.
У меня есть массив процедур, которые вызываются одна за другой.
Процедуры принимают параметр на одну структуру, с которой они работают.
Структура может содержать в качестве члена указатель на массив ещё таких же процедур - это для ветвлений удобно.
Тьфу блин, как я это то
упустил. Ладно, не буду оффтопить.
Chipmunk
> http://colinm.org/language_checklist.html
И что? Теперь и своих языков писать нельзя? Может и игры писать не стоит, - полно же больших и сверхопытных команд, которые сделают это лучше?
0iStalker
это описание к какому тулу?
flex/bison?
Pushkoff
> flex/bison?
COCO/R, - оно генерит исходник с рекурсивным спуском по LL1. Собственно, можно и Bison, но там (с его LALR1) надо извращаться описывать продукции строго через рекурсию, а тут для парсера можно использовать правила, как в лексере. Ну и извратов с интеграцией именно в С++ намного меньше, с чем у Bison'а и Antlr - беда.
0iStalker
посмотри на r2c/lemon(LARL), говорят они генерят самый быстрый код парсера и довольно просты
правда у r2c есть проблема, в потоке должен быть терминальный символ, по которому заканчивается парсинг, длинну буфера он не понимает.
а лемон хорош тем что токены ему скармливаются по одному, но он генерит исходник на С и файл с дефайнами для токенов, что очень неудобно заворачивать в неймспейс.
tmtlib
ну, у меня в мечтах тоже подобная идея есть. и всё было бы ничего, если бы не одно НО:
оно называется interoperability с сишным и плюсовым кодом, потому что куча нужных библиотек написана на С/С++.
и тут появляется две возможности:
1. писать под всё врапперы. упаришся писать на самом деле. библиотек много, а рук всего две.
2. делать утилиту для автоматического импорта, чтобы умела парсить сишные хэдеры (макросы это одна беда, а вот плюсовые шаблоны это уже не шутка).
получается единственная полезная вещь (которая имеет возможность быть сама по себе) - скриптовый язык и биндинги к движку.
Тема в архиве.