Возможно ли иметь жесткий режим реального времени с лексической областью? - PullRequest
5 голосов
/ 30 апреля 2011

Я читал эту статью о проблеме funarg, которая действительно является проблемой поддержания сред лексических замыканий. Это старая статья, и я не уверен, что выводы автора остаются в силе, но он настоятельно подразумевает, что для того, чтобы иметь лексическую, а не динамическую область видимости, вы должны отказаться от традиционного стека в стиле C и вместо этого иметь древовидную структуру окружений, выделенных из кучи.

Делает ли это невозможным использование лексически ограниченных замыканий в любой системе реального времени? во встроенных системах реального времени, где задержки измеряются в микросекундах, выделение кучи обычно запрещено из-за недетерминированной задержки, которую она вводит.

Это было мое праздное любопытство, потому что я делаю хлеб главным образом как разработчик прошивок, где C является языком де-факто, и какое-то время кажется, что я использовал свои умственные способности, чтобы понять, как заставить С позволить мне делать вещи, которые приходят бесплатно на более сложных языках. Следовательно, я начал задаваться вопросом, можете ли вы реализовать компилятор микролиша специально для встроенных систем на основе микроконтроллеров в реальном времени.

В качестве примечания: в последнее время я получил глубокое понимание глубоких тем, таких как, как замыкания и объекты эквивалентны, и так далее, и это дает мне больше страха перед парнями, такими как Столлман, Рич Хики и Пол Грэм. Внедрение Lisp с нуля кажется мне сложной задачей. Трудно понять, с чего начать. (Возможно с реализацией PG оригинальной функции eval Маккарти, IDK). Во всяком случае, я отвлекся.

Ответы [ 2 ]

3 голосов
/ 30 апреля 2011

Лексическая область видимости возможна в «жестком реальном времени» - в конце концов, вы говорите, что используете C для приложений реального времени, а C является языком с лексической областью. Я предполагаю, что вы на самом деле беспокоитесь о первоклассных функциях, а не о лексической области видимости. Предполагая, что существует целая куча известных методов компиляции для эффективной работы с первоклассными функциями.

Прежде всего, то, что вы увидите в учебниках и т. Д., Почти всегда делает обычную древовидную среду, но на практике это совсем не нужно, если функции не используются в качестве значений. Практически каждый достойный компилятор функционального языка идентифицирует такой код и вместо этого будет использовать стек, поэтому при распределении ресурсов не требуется никаких затрат. (Обратите внимание, что в этот момент это означает, что если вы ограничиваете себя тем, что пишете в C, тогда выделение не требуется.) Затем есть множество дополнительных способов уменьшить выделение - например, рассмотрите что-то вроде (lambda (x) (* x 9)) - эта функция на самом деле не закрывает по любым свободным идентификаторам, и поэтому компиляторы поднимают наверх, так что есть единственная копия функции и, опять же, нет распределение. (Примечание по теме: с этой оптимизацией вы уже получаете больше, чем дает вам C, и все еще не выделяете.)

Существует целая куча дополнительных оптимизаций , которые избегают выделения, но, конечно, есть случаев, когда вам действительно нужно выделить новое замыкание. Но эти места являются статически идентифицируемыми, и если вы действительно заботитесь о таких распределениях, то не должно быть труда взломать компилятор, который предупреждает вас о таких распределениях. Было несколько таких языков, например, GOAL , очень низкий уровень prescheme . Но в IME большинство людей быстро разбираются в вещах, и становится понятно, где происходит выделение ресурсов - так что вы получаете преимущество языка высокого уровня, а когда получается какой-то код, который вы хотите оптимизировать, легко увидеть, где происходит выделение. и этого легко избежать обычными способами. (И, конечно, все это не связано с оптимизацией распределения.)

1 голос
/ 30 апреля 2011

Я нашел несколько распределителей в реальном времени, так что я бы сказал. Возможна лексическая область в реальном времени:

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 в приложение не раздувать это. Тарбол для Lua 5.1.4, который содержит исходный код, документация и примеры, занимает 212K сжатых и 860K несжатых. Источник содержит около 17000 строк C. Под Linux интерпретатор Lua построен со всеми стандартными библиотеками Lua занимает 153K и библиотека Lua занимает 203K.

Луа свободен

Lua - бесплатное программное обеспечение с открытым исходным кодом, распространяется под очень либеральным лицензия (известная лицензия MIT). Это может быть использовано для любых целей, в том числе в коммерческих целях, на абсолютно бесплатно. Просто скачайте его и используй его.

...