Так. В фортране при компиляции модуля получается два файла: объектник и API модуля, потом он используется, вместо парсинга сорца с модулем

Дык вариантов реализации множество - в C# одно, в JS другое, в OCaml третье. Смотрите что вам больше подходит по семантике вашего языка

потому что у си рантайм жирнее?

(знаю, еретик)

Потому что zig использует musl при чем немного допиленный если я не ошибаюсь

Интерестно как это у них в примере Node.js вышел 35 mb? Если сама нода весит не более 10 mb? =)

Хотя нет, сейчас чекнул и под Linux и Mac там около 70 mb сейчас. Хм, а еще в 11й версии там было 10-11 mb

Ещё раз большое спасибо - крайне интересно затрагивает области, в которых я работал. Удивительно, но магнитная память в физике была hot topic примерно 10 лет назад.

А на теории групп стоят полупроводники. И, соответственно, меня страшно интересовало, когда теория представлений пойдёт в программирование.

У вас случайно нет полной версии доклада?

Повторюсь снова: Design Concepts in Programming Languages, там модулям посвящена отдельная глава, вплоть до разбора работы с зависимыми типами в стиле сигнатур ML.

IMHO, понятия размыты. Существует, например интерпретатор PicoBit для Scheme. Который позволяет на этой самой Scheme писать для STM3F103. Куда уж более baremetal-истее? Понятное дело, что жертвуем скоростью, но с другой стороны, в память влезает http-сервер, который, тем не менее, может работать с SPI. 🤷‍♂️

Увы, насколько я знаю — нет в свободном доступе.

Речь идет о выработке критериев, по которым будут сравниваться различные подходы к инструментарию для baremetal-разработки. Вот Вы уже какие-то оговорки сделали. Можно и добавить — как, например, работать с высокоскоростным SPI-интерфейсом, если у нас примитивный mark&sweep GC? "Реальное время" — это ведь не только про скорость. Далее: PICOBIT попадает в категорию "компиляторы в байткод с VM на Си". Точно будем считать, мол, "куда уж более..." или, объективно говоря, перед нами решение на любителя? :)

А чем менает mark&sweep высокой скорости? mark&sweep же не мешает прерываниям и возможности заполнять буферы (байтвекторы) данными или, наоборот, отправлять их. Оно, конечно, компилируется в байткод с VM на Си, но это цель дизайна, чтобы экономить место.

Я не утверждаю, что именно так и надо делать. Я утверждаю, что так тоже можно делать. И критерии, на самом деле, размыты.

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

Более того, в некоторых случаях удобно еще и пересылать такие скрипты прямо в исходном виде. Таким образом можно, например, на лету перепрограммировать сеть умных сенсоров, которые построены на различном железе.
Утверждение, что "так тоже можно"  не вызывает возражений. Просто новизны в этом ("VM на Си"), мягко говоря, нет. Тем, кто пишет для встраиваемых систем, все это давно известно.

Ну и, собственно, нелишне еще раз вспомнить статью "История разработки одного компилятора": http://fprog.ru/2009/issue2/dmitry-zuikov-one-compiler-story/

А там (в тусовке) разбираются случаи с неполной утилизацией результатов вычислений? Ну вроде параллельного поиска на графе с циклами. Ключевые слова - lvars, lattices.

Я проглядев список литературы (названия) этого не нашёл.

Мне вообще, как физику, интересно соответствие dataflow графа и графа состояний программы. И как-то я не смог найти внятного рассмотрения этого вопроса.

В CSP это как-то заметено под ковёр.

По аналогии с механикой, граф состояний автомата - это фазовое пространство, data flow - это граф сил в системе. Обычные координаты - это то ли сообщения, то ли внутренние состояния акторов.

Я и не утверждаю, что это ново. Речь только о том, что критерии того, что считать baremetal, а что - нет, размыты.

P.S. Кстати, нет никаких проблем вычислять для процедуры консервативное приближение предиката будет ли она realtime-овой или нет, в том числе и то, будет ли она взаимодействовать с GC.

Да, в принципе, нет особых проблем реализовать вариант GC для условий жесткого реального времени. Как нет проблем и реализовать compile-time GC. Но на практике имеем почему-то довольно примитивный интерпретатор с "пометить-и-собрать"-GC, который никаким SPI, конечно, управлять лучше не заставлять ;)

Lvars — это из исследования Lindsey Kuper? Это относительно недавняя вещь. Формализмов-то много... Вот у ван Роя чем плохие формальные подходы к параллелизму и распределенности? :)  https://plds.github.io/slides/VanRoy-KTH-Mar2020.pdf