roboforum.ru

Си или бейсик.

Под винды.
Бесплатный.
Без "вирусных" лицензий.
Небольшой (условно <= 5 Мб)

Исходники не обязательны.
Оптимизация не обязательна.
Может быть подмножеством языка, не полностью соответствовать "стандартам" итп.

(Для встраивания)

Что значит "для встраивания"?

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

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

Добавлено спустя 1 минуту 27 секунд:
Ой, да...
Сам компилятор НЕ будет встраиваться в АВР-ку, если вы про это
Кросс-компилер под винды нужен

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

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

Вижу это примерно так:

1. Имеется МК и набор периферии.
2. В прошивке МК реализовано все взаимодействие с периферией.
3. Прошивка может генерировать определенный набор событий.
4. скрипт может содержать обработчики событий. Активизация скрипта происходит только при возникновении события.
5. события ставятся в очередь, очередной обработчик вызывается только после завершения предыдущего
6. Прошивка предоставляет возможность взаимодействия с периферией посредством вызова методов объектов.
7. С точки зрения скрипта, устройство представляет собой набор объектов, каждый из которых имеет несколько методов.
8. Компилятор независим от устройства, на котором будет выполняться скрипт. Переход на другое устройство заключается в подсовывании компилятору нужного файла с описанием устройства (набор объектов/методов/событий, объем памяти под скрипт и переменные, и т.д.)
9. Язык должен быть как можно проще
10. Количество типов данных ограничено. Только целые без знака и строки (надо уточнить работу со строками)
11. скрипт исполняет содержащаяся в прошивке стэк-ориентированная виртуальная машина.

Если есть интерес, можно обсудить язык и виртуальную машину

есть и интерес, и наработки... времени, правда, полнеценно выделить не смогу.

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

blindman писал(а):# Прошивка предоставляет возможность взаимодействия с периферией посредством вызова методов объектов.
# С точки зрения скрипта, устройство представляет собой набор объектов, каждый из которых имеет несколько методов.

Тут нужно делить вирт машину и входной язык... С точки зрения входного языка объекты могут существовать, с точки зрения машины - нет... "Прошивка предоставляет возможность... " - это о чем? Она знает про "методы", "объекты", "типы"?

Где запускается компилятор?

blindman писал(а):# Язык должен быть как можно проще

Это темное определение...
брейнф*к вот тоже простой язык )) Один из...

Само собой, машина отдельно от языка.

Компилятор работает на ПК, генерируя байткод для машины.

С точки зрения машины обращение к методу объекта можно рассматривать как что-то наподобие вызова native метода в JVM. Но здесь название "объект" к ООП не имеет отношения. Объект - просто логическая группировка функций.

Michael_K писал(а):"Прошивка предоставляет возможность... " - это о чем? Она знает про "методы", "объекты"?

Конечно знает.
Например, некоторое устройство может иметь 10 ламп. Имеем объект Лампа, с методами Включить(номер_лампы), Выключить(номер_лампы), Мигать(номер_лампы, частота)

blindman писал(а):Конечно знает.

По-моему, это излишние навороты...
Хотя,...

Для меня это необходимость.

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

А уж является эта функция "методом объекта", методом какого объекта итп "прошивку" не волнует ни разу.
Это волнует компилятор... может быть. А может и его не волнует.
Например, можно назвать функцию как "UART.get_char"... Пользователь сколько угодно может думать, что это "объект", а компилятор думать что это тупо "имя с точкой".

В объектах ведь фишка-то в чем - можно, как минимум, создавать инстанции
(про всякие наследования пока помолчим).
Если набор объектов заранее ограничен, то чем объекты отличаются от "необъектов"?
Только тем, как их воспринимает пользователь!

А инстанции - это сразу типы вынь да положь.

Да фиг с ними, с объектами. Неудачная формулировка. Просто, машина должна предоставлять возможность вызова некоего вкомпилированного кода. Как это будет воспринимать компилятор или программист - не важно.

OK, понял...
вызов нэйтив кода нужен.

Добавлено спустя 1 час 17 минут 10 секунд:
Вообще, готовое ищеццо...
С-flea, например.
Бейсики попадались.

Перепробовал несколько тулзов для построения компиляторов, остановился на flex + bisonc++. Некоторый опыт использования флекса и бизона есть, так что это оказался самый быстрый путь. Правда делал трансляторы только на c, в этот раз хочу попробовать на c++. Через недельку думаю смогу показать результаты.

PS. Michael_K - спасибо за исходники виртуальной машины

ну... эти исходники довольно сырые...
там во-первых концепция модифицировалась по ходу написания
сначала задумывалась машина с лямбда-функциями (Операторы LAM и LAMx)
и с относительной адресацией...
А потом она превратилась в джампы и абсолютной адресацией...
Там частично связано с какими-то проблемами (уже не очень помню),
частично с производительностью...

Ну и системные коллы нужно бы продумать...
И дебаг.

Собственно, я тогда доточил эту машину до конкретной задачи,
а вот эта "general purpose"-версия так и зависла... Но вроде бы работала.

Машину я буду писать на С для переносимости, но у вас кое-что для себя подсмотрел.

Я старался добиться производительности, но на самом деле не факт, что стэковая машина в этом смысле лучший подход. Там хоть и просто вроде получается и каждая команда довольно шустрая,
в результате (в реальном коде) получается довольно много "непроизводительных" операций
(всяких DUP, DROP и т.п.)...