Java-синтаксис на 8-битных микроконтроллерах? Без виртуальной машины?

Исторически в эмбеддеде правит Си. Но Си — это вечные malloc/free, утечки памяти, выходы за границы массива и дебаг с осциллографом.

Я разрабатываю vm5277 — монолитный тулкит и язык J8B с Java-подобным синтаксисом. Он компилирует строгий ООП-код напрямую в нативный, оптимизированный ассемблер.

Что под капотом:

Управление памятью: через Reference Counting (new без free и без Garbage Collector).

Полиморфизм интерфейсов: спрятан во Flash (без оверхеда в ОЗУ).

Типы данных: встроенный 16-битный примитив fixed (Q7.8) вместо тяжелого float.

Оптимизация: тотальный Dead Code Elimination (в прошивку идет только то, что реально вызвано).

Проект в стадии суровой Альфы. Код открыт на GitHub, десятки примеров (от мигания диодом до драйверов периферии).

Проверка на переполнение есть в коде, проходит ревью и работает в отладочной сборке — а после оптимизации исчезает из бинарника. Разберём, почему компилятор имеет на это полное право, как неопределённое поведение влияет на указатели, память и проверки, и чем ловить такие ошибки до того, как они проявятся в рабочей среде.

В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.

Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?

После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.