roboforum.ru

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

А откуда берется множество DUP/DROP?

Ну... "множество" понятие относительное
Просто если сравнивать стековую машину, например, с кучей равнозначных регистров (как в AVR или ARM),
то непроизводительных пересылок больше...

А компилятор, естественно, под стековую машину проще писать - тут вы правы.

Кое-что уже работает

Исходник:

Код: Выделить всё

function fib(@n)
{
    if (@n = 0) return 0;
    if (@n = 1) return 1;
    return fib(@n-1) + fib(@n-2);
}

function fib2(@n) : @n1, @n2, @tmp
{
    if (@n = 0) return 0;
    if (@n = 1) return 1;
    @n1 := 0;
    @n2 := 1;
    while (@n) {
        @tmp := @n2;
        @n2 := @n1 + @n2;
        @n1 := @tmp;
        @n := @n - 1;
    }
    return @n2;
}


Листинг компилятора:

Код: Выделить всё

   fib: L_LOAD 0
        CONST_0
        EQ
        BRF 9
        CONST_0
        RET_POP_0
     9: L_LOAD 0
        CONST_1
        EQ
        BRF 18
        CONST_1
        RET_POP_0
    18: L_LOAD 0
        CONST_1
        MINUS
        CALL fib
        L_LOAD 0
        CONST_2
        MINUS
        CALL fib
        PLUS
        RET_POP_0
  fib2: LOCALS 3
        L_LOAD 0
        CONST_0
        EQ
        BRF 46
        CONST_0
        RET_POP 3
    46: L_LOAD 0
        CONST_1
        EQ
        BRF 56
        CONST_1
        RET_POP 3
    56: CONST_0
        L_STORE 1
        CONST_1
        L_STORE 2
    62: L_LOAD 0
        BRF 91
        L_LOAD 2
        L_STORE 3
        L_LOAD 1
        L_LOAD 2
        PLUS
        L_STORE 2
        L_LOAD 3
        L_STORE 1
        L_LOAD 0
        CONST_1
        MINUS
        L_STORE 0
        BR 62
    91: L_LOAD 2
        RET_POP 3



Ого! Круто...
А это прямо команды вирт. машины или какой-то "промежуточный код" в компиляторе?

Немного непонятен (по-моему, не очень логичен) формат вызова функции
(передача аргументов - размещение локальных - адресация - возврат результатов...)

Добавлено спустя 3 минуты 46 секунд:
входной язык не понравился
Мне кажется, что нужно думать о красоте и юзабилити...
(Ну вот такое у меня представление о том, как работает этот мир)

Это команды машины.

Для вызовов используются команды CALL, CALL_DROP, LOCALS, RET, RET_POP, RET_0, RET_POP_0:
CALL addr - вызов функции
CALL_DROP addr - вызов функции, игнорировать возвращенное значение
LOCALS n - зарезервировать место под n локальных переменных
RET n - освободить n локальных переменных, вернуть 0
RET_POP n - освободить n локальных переменных, вернуть значение с вершины стэка
RET_0 - вернуть 0
RET_POP_0 - вернуть значение с вершины стэка

Michael_K писал(а):входной язык не понравился

Предложите варианты. Я в общем то для того и выкладываю промежуточную инфу

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

2. функция (может быть) должна выкидывать со стека аргументы (??? тоже не уверен)

3. язык, как мне кажется, перегружен "кривыми" условными символами -
все эти ":=", ";", "@" и прочие скобочки я бы постарался минимизировать...
Это потенциальный источник синтаксических ошибок, которые грозят перерасти в семантические
(что будет, если пользователь, например, поставит "=" вместо ":=" или напишет "n1" вместо "@n1"?)
Я бы также выкинул "объявления"... Тут надо смотреть на то, что хочется с типами получить...

Вот мне кажется, что нужно из си выкинуть некоторые символы:
"==" (по факту обычно применяется только в IF, WHILE итп, там, где по факту же редко применяется присваивание).

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

объявления (и пользовательские типы), в крайнем случае использовать неявное преобразование к одному типу или вообще "универсальный" тип (да-да, я понимаю, что это отказ от современных концепций)

И (МОЖЕТ БЫТЬ) даже заменить открывающие-закрывающие фигурные скобки тупо отступом
(пусть пользователь будет генерить сразу красивый код, и не путается в скобочках),
хорошо бы, если бы это было поддержано редактором.

ну и стопудово нужен качественный функциональный препроцессор.

Код: Выделить всё

fib(n)
    if (n = 0) return 0
    if (n = 1) return 1
    return fib(n-1) + fib(n-2)

fib2(n)
    if (n = 0) return 0
    if (n = 1) return 1
    n1 = 0
    n2 = 1
    while (n)
        tmp = n2
        n2 = n1 + n2
        n1 = tmp
        n = n - 1
    return n2


В принципе и скобки в ИФах, вайлах итп - лишние

Добавлено спустя 9 минут 31 секунду:
Ну а вообще, нужно конечно ориентироваться на предполагаемые проекты.
Широкомасштабируемый код, многократно используемые куски, библиотекарь (ну, чем черт не шутит)
или, скажем, динамическое связывание (не приведи господь)
сразу наложат ограничения на жесткую типизацию и т.п.

1. Не принципиально
2. Должна. Ошибка в компиляторе - при генерации RET не учитывается количество параметров
3. @ (а есть еще $ и # ) были добавлены для упрощения компилятора на начальном этапе - это хинт компилятору, что перед ним - локальная переменная, глобальная или константа. Потом уберу
   Отступы - потенциальный источник ошибок (табуляция/пробел). Хотя и можно сделать редактор который не даст такие ошибки допустить.
   Типы - хочется чтобы были целое и строка (с фиксированной макс. длиной). Работа со строками - только нативные функции, в самом языке - только копирующее присваивание. Параметры функций - всегда целое.
   А скобки в условиях и так необязательные, просто по привычке их пишу

Раздельная компиляция - нафиг. Только инклюды.

1. согласен
2. понятно
3. отступы... тоже согласен, просто лучшего не придумалось.
"только инклюды" - ДА!!!

Добавлено спустя 14 минут 5 секунд:

в самом языке - только копирующее присваивание.

А, например, разбор-генерация протокола обмена?
через нативные функции преобразования в целое и обратно?

Ну про строки я с самого начала писал, что над этим надо подумать. Пока четкой картины нет

Михаил, у тебя прям почти что питон получился

Код: Выделить всё

def fib(n):
    if n == 0: return 0
    if n == 1: return 1
    return fib(n-1) + fib(n-2)

def fib2(n)
    if n == 0: return 0
    if n == 1: return 1
    n1 = 0
    n2 = 1
    while n:
        tmp = n2
        n2 = n1 + n2
        n1 = tmp
        n = n - 1
    return n2


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

угу, а у брейнф*ка грамматика еще короче.

Michael_K писал(а):Мне кажется, что нужно думать о красоте и юзабилити...
(Ну вот такое у меня представление о том, как работает этот мир)

Понимаете, пользователю должно быть удобно и приятно, а не программисту.

Добавлено спустя 8 минут 24 секунды:
пользователя же мало волнует, как там устроен компилятор,
как формально описывается грамматика, что там происходит в виртуальной машине...
Главное, чтобы безгеморройно и хорошо решала его задачи.

Кстати, неплохо бы, наверное в поставленной задаче "слабые" имена ввести.

угу, а у брейнф*ка грамматика еще короче.

К чему это важное замечание?

К тому, что простая грамматика совсем не означает, что языком удобно пользоваться.
http://ru.wikipedia.org/wiki/Brainfuck

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