代码之家 › 专栏 › 技术社区 › Andrew Y

将haskell用于大型实时系统:如何(如果?)?

hard-real-time real-time embedded haskell

Andrew Y · 技术社区 · 15 年前

我一直很好奇是否有可能将haskell的功能应用到嵌入式实时世界中,并且在google中发现 Atom 包裹。我假设在复杂的情况下,代码可能有所有经典的C错误——崩溃、内存损坏等,然后需要跟踪到原始的haskell代码, 引起了他们。因此,这是问题的第一部分:“如果您有使用Atom的经验,您是如何处理调试编译后的C代码中的低级错误并将其修复为haskell原始代码的任务的?”

我搜索了更多关于原子的例子, this blog post 提及产生的C代码22kloc(显然没有代码:),即 included example 是玩具。 This 和 this 引用有一些更实用的代码,但这就是它的终点。我之所以把“相当大的”放在这个主题上,是因为,如果您能分享一下您在300kloc+范围内使用生成的C代码的经验,我会非常感兴趣。

由于我是哈斯克尔的新手,很明显,由于我不知道自己有什么其他的原因,我没有找到其他的方法,所以在这方面的自我教育的任何其他指针都将非常感谢-这是问题的第二部分-“如果在哈斯克尔做实时发展的其他一些实用方法(如果)是什么?”如果多核也在图片中,那是一个额外的加号:—)

(关于haskell本身的用途:从我读到的 this blog post 哈斯凯尔的垃圾收集和懒惰使得它在日程安排上变得相当不确定,但也许两年后情况有所改变。 Real world Haskell programming 问题是我能找到的最接近这个主题的)

注: 上面的“实时”更接近“硬实时”——我很好奇是否可以确保主任务不执行时的暂停时间低于0.5毫秒。

5 回复 | 直到 6 年前

Matthias Braun AdamSkywalker 6 年前

在Galois,我们用haskell做两件事:

软实时(操作系统设备层,网络),其中1-5毫秒的响应时间是合理的。GHC生成快速的代码,并支持调整垃圾收集器和调度程序以获得正确的时间安排。
对于真正的实时系统,EDSL用于为其他语言生成代码,这些语言提供了更强的时间保证。例如密码,原子和副作用。

所以要小心区分EDSL(copilot或atom)和宿主语言(haskell)。

一些关键系统的例子,在某些情况下,实时系统,不管是由Galois编写的还是由Haskell生成的。

EDSL

Copilot: A Hard Real-Time Runtime Monitor --用于实时航空电子监控的DSL
Equivalence and Safety Checking in Cryptol --关键系统密码组件的DSL

系统

HaLVM --用于嵌入式和移动应用的轻量级微内核
TSE --跨域(安全级别)网络设备

Norman Ramsey 15 年前

需要很长时间才能有一个适合于小内存的haskell系统,并且可以保证亚毫秒的暂停时间。Haskell实现者的社区似乎对这种目标不感兴趣。

使用haskell或haskell喜欢编译成非常有效的东西是有好处的;例如, Bluespec 编译为硬件。

我不认为它能满足你的需要,但是如果你对功能编程和嵌入式系统感兴趣,你应该了解 Erlang .

Tom 15 年前

安德鲁,

是的,通过生成的代码返回到原始源代码来调试问题可能很困难。Atom提供的一件事是探测内部表达式的方法,然后由用户决定如何处理这些探测。对于车辆测试,我们构建了一个发送器(在Atom中),并通过CAN总线将探针输出。然后,我们可以捕获这些数据,对其进行格式化,然后使用诸如gtkwave之类的工具在后处理或实时中查看这些数据。对于软件模拟,探针的处理方式不同。不是从CAN协议获取探针数据,而是对C代码进行钩子,以直接提升探针值。然后在单元测试框架(与Atom一起分发)中使用探针值来确定测试是通过还是失败,并计算模拟覆盖率。

Peaker 15 年前

我不认为haskell或其他垃圾收集语言非常适合于硬实时系统,因为GC倾向于将它们的运行时间分解为短暂的停顿。

在Atom中编写并不完全是在Haskell中进行编程,因为这里的Haskell可以看作是您正在编写的实际程序的纯粹预处理器。

我认为哈斯克尔是一个 令人惊叹的 预处理器和使用类似于Atom的DSEL可能是创建大型硬实时系统的好方法,但我不知道Atom是否符合要求。如果没有,我很确定这是可能的(我鼓励任何人这样做!)实现一个这样的DSEL。

对于低级语言来说,拥有像haskell这样强大的预处理器,可以打开一个巨大的机会窗口,通过代码生成来实现抽象,这在作为C代码文本生成器实现时要笨拙得多。

solrize 15 年前

我一直在玩弄原子。它很酷,但我认为它最适合小型系统。是的,它在卡车和公共汽车上运行,并实现现实世界中的关键应用程序,但这并不意味着这些应用程序必然是大型的或复杂的。它确实适用于难实时的应用程序,并且会花大量的时间让每个操作占用完全相同的时间。例如,它有一个“mux”语句,它总是在有条件地选择两个计算值之一之前执行两个分支,而不是有条件地执行两个运行时间可能不同的代码分支之一的if/else语句(因此,总执行时间与选择的值相同)。除了内置类型(类似于C)之外,它没有任何重要的类型系统,这些类型系统是通过通过通过原子monad传递的gadt值强制实现的。作者正在开发一个静态验证工具,用于分析输出C代码,这非常酷(它使用SMT解算器),但我认为Atom将受益于更多的源代码级特性和检查。即使是在我的玩具大小的应用程序(LED手电筒控制器)中,我也犯了一些新手错误,有经验的人可能会避免这些错误,但这导致了错误的输出代码,我宁愿被编译器捕获而不是通过测试。另一方面,它仍然是0.1版,因此毫无疑问,改进正在到来。