是否可以通过词法范围进行硬实时操作?

时间:2011-04-30 12:47:15

标签: embedded lisp scope real-time lexical

我正在阅读有关funarg问题的this paper,这实际上是维护词法闭包环境的问题。这是一篇旧论文,我不确定作者的结论是否仍然成立,但他强烈暗示,为了拥有词汇而非动态范围,你必须放弃传统的C风格的堆栈,而是拥有一个树形结构从堆中分配的环境。

这是否使得在任何硬实时系统中都无法使用词法范围的闭包?在以微秒为单位测量延迟的实时嵌入式系统中,由于引入的非确定性延迟,通常会禁止堆分配。

这一直是我的好奇心,因为我把面包主要作为固件开发人员,其中C是事实上的语言,有一段时间我似乎一直在利用我的脑力来弄清楚如何强迫C让我用更复杂的语言做免费的事情。因此,我开始怀疑您是否可以专门为基于硬件实时的嵌入式微控制器系统实现micro-lisp编译器。

作为旁注:我最近深入了解了关于封闭物和物体是如何等等的深层主题,它让我更加敬畏像Stallman和Rich Hickey以及Paul Graham这样的人。从头开始实现Lisp对我来说似乎是一项艰巨的任务。很难知道从哪里开始。 (也许PG的实施麦卡锡的原始评估功能,IDK)。无论如何,我离题了。

2 个答案:

答案 0 :(得分:3)

词汇范围显然可以通过“硬实时”实现 - 毕竟,你说你使用C作为实时应用程序,而C 一种词法范围的语言。我的猜测是你实际上关心的是一流的功能,而不是词汇范围。假设有一大堆已知的编译技术可以有效地处理第一类函数。

首先,您在教科书等中看到的几乎总是在做通常的树形环境,但实际上,如果函数不用作值,则根本不需要。实际上,每个体面的函数式语言编译器都会识别这样的代码并将使用堆栈,因此分配的开销为零。 (请注意,在这一点上,这意味着如果您将自己局限于您在C中编写的内容,则不需要进行分配。)然后,还有一些其他方法可以减少分配 - 例如,考虑类似{ {1}} - 此函数并不真正关闭任何免费标识符,因此编译器将lift置于顶部,因此只有该函数的单个副本,并且,没有分配。 (相关说明:通过此优化,您已经获得了比C给出的更多,但仍然没有分配。)

有一大堆additional optimizations可以避免分配,但当然的情况,你真的需要分配一个新的闭包。但是这些地方是静态可识别的,如果你真的关心这样的分配,那么破解一个警告你这种分配的编译器并不困难。有很多这样的语言,例如GOAL,非常低级prescheme。但IME大多数人很快就掌握了一切,并且在分配发生的地方变得越来越明显 - 因此您可以获得高级语言的好处,当它获得您想要优化的某些代码时,很容易看出分配发生的位置,以通常的方式很容易避免它。 (当然,所有这些都与优化分配无关。)

答案 1 :(得分:1)

我发现了一些实时分配器。实时的词法范围是可能的:

http://rtportal.upv.es/rtmalloc/

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.441&rep=rep1&type=pdf

在编写我自己的micro-lisp之前,我会尝试为有问题的嵌入式系统找到或移植lua。它非常小,并提供了大量的LISP:一流的功能,闭包,没有延续,但是协同例程。

  

Lua很小

     

将Lua添加到应用程序不会   臃肿吧。 Lua 5.1.4的tarball,   其中包含源代码,   文档和示例,需要   212K压缩和860K无压缩。   源包含大约17000行   C.在Linux下,Lua解释器   使用所有标准的Lua库构建   需要153K和Lua库   203K。

     

Lua是免费的

     

Lua是免费的开源软件,   分布在一个非常自由的人   许可证(众所周知的麻省理工学院许可证)。   它可以用于任何目的,   包括商业用途,在   绝对没有成本。只需下载它   并使用它。