Возможно ли иметь жесткий режим реального времени с лексической областью?
Я читал эту статью о проблеме funarg, которая на самом деле является проблемой поддержания среды лексических замыканий. Это старая статья, и я не уверен, что выводы автора остаются в силе, но он строго подразумевает, что для того, чтобы иметь лексическую, а не динамическую область видимости, вы должны отказаться от традиционного стека в стиле C и вместо этого иметь древовидную структуру сред, выделенных из кучи.
Делает ли это невозможным использование лексически ограниченных замыканий в любой системе реального времени? во встроенных системах реального времени, где задержки измеряются в микросекундах, выделение кучи обычно запрещено из-за недетерминированной задержки, которую оно вводит.
Это было мое праздное любопытство, потому что я делаю хлеб главным образом как разработчик прошивок, где C является де-факто языком, и какое-то время кажется, что я использовал свои умственные способности, чтобы понять, как заставить C позвольте мне делать вещи, которые приходят бесплатно на более сложных языках. Следовательно, я начал задаваться вопросом, можете ли вы внедрить компилятор микропроцессора специально для систем на основе встроенных микроконтроллеров, работающих в режиме реального времени.
В качестве примечания: в последнее время я получил глубокое понимание глубоких тем, таких как, как замыкания и объекты эквивалентны, и так далее, и это дает мне больше страха перед парнями, такими как Столлман, Рич Хики и Пол Грэм. Реализация Lisp с нуля кажется мне сложной задачей. Трудно понять, с чего начать. (Возможно с реализацией PG оригинальной функции eval Маккарти, IDK). Во всяком случае, я отвлекся.
2 ответа
Лексическая область видимости, очевидно, возможна в "жестком режиме реального времени" - в конце концов, вы говорите, что используете C для приложений реального времени, а C - это язык с лексической областью. Я предполагаю, что вы на самом деле беспокоитесь о первоклассных функциях, а не о лексической области видимости. Предполагая, что существует целая куча известных методов компиляции для эффективной работы с первоклассными функциями.
Прежде всего, то, что вы увидите в учебниках и т. Д., Почти всегда выполняет обычную древовидную среду, но на практике это совсем не нужно, если функции не используются в качестве значений. Практически каждый приличный компилятор функционального языка идентифицирует такой код и вместо этого будет использовать стек, так что при распределении нет никаких накладных расходов. (Обратите внимание, что на этом этапе это означает, что если вы ограничиваете себя тем, что пишете в C, тогда выделение не требуется.) Затем, есть множество дополнительных способов уменьшить выделение - например, рассмотреть что-то вроде (lambda (x) (* x 9)) - эта функция на самом деле не закрывает какие-либо свободные идентификаторы, и поэтому компиляторы поднимут ее до вершины, чтобы была единственная копия функции и, опять же, никакого выделения. (Примечание по теме: с этой оптимизацией вы уже получаете больше, чем дает вам C, и все еще не выделяете.)
Существует целый ряд дополнительных оптимизаций, которые избегают распределения, но, конечно, есть случаи, когда вам действительно нужно выделить новое замыкание. Но эти места являются статически идентифицируемыми, и если вы действительно заботитесь о таких распределениях, то не должно быть труда взломать компилятор, который предупреждает вас о таких распределениях. Было много таких языков, см., Например, ЦЕЛЬ, прескемма очень низкого уровня. Но в IME большинство людей быстро разбираются в вещах, и становится понятно, где происходит выделение ресурсов - так что вы получаете преимущество языка высокого уровня, а когда получается какой-то код, который вы хотите оптимизировать, легко увидеть, где происходит выделение. и этого легко избежать обычными способами. (И, конечно, все это не связано с оптимизацией распределения.)
Я нашел несколько распределителей в реальном времени, так что я бы сказал. Возможна лексическая область в реальном времени:
http://rtportal.upv.es/rtmalloc/
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.441&rep=rep1&type=pdf
Добавляя к вашему обзору, перед написанием моего собственного микропроиска я попытался бы найти или перенести lua для рассматриваемой встроенной системы. Он очень маленький и предлагает большую часть LISP: первоклассные функции, замыкания, никаких продолжений, но сопутствующие процедуры.
Луа маленький
Добавление Lua в приложение не увеличивает его. Tarball для Lua 5.1.4, который содержит исходный код, документацию и примеры, берет 212K сжатых и 860K несжатых. Исходный код содержит около 17000 строк C. В Linux интерпретатор Lua, построенный со всеми стандартными библиотеками Lua, занимает 153 КБ, а библиотека Lua - 203 КБ.
Луа свободен
Lua - это бесплатное программное обеспечение с открытым исходным кодом, распространяемое по очень либеральной лицензии (известной лицензии MIT). Он может быть использован для любых целей, в том числе коммерческих, абсолютно бесплатно. Просто скачайте и используйте.