四个嵌入式CPU标准面临的共同挑战

四家在国防市场竞争的嵌入式计算机供应商为嵌入式系统编写了四个标准。它们是：矢量，信号和图像处理库（VSIPL）;实时消息传递接口（MPI/RT）;消息传递接口（MPI）;和Data Reor -

组织接口（DRI）。以下是它们是什么以及每种情况发生了什么。

VSIPL是一个专为矢量和信号处理而定制的数学库。该库的公共域工作站实现目前可从TASP COE计划获得。 VSIPL规范不依赖于语言;它是为C编程语言开发的。此外，虽然VSIPL包含负责设置操作的对象，但它不是面向对象的API。现在还不清楚如何在现代的面向对象框架中实现相同的API，例如C ++。与此同时，用C ++编写的现代基于模板的库似乎达到了相当的性能水平。

在所有最近的标准中，VSIPL最有可能被用户采用，因为它的实现很简单，并且与硬件和系统软件的工作方式不冲突。它的问题都与性能和开销有关，用户可以及时学习绕过它们，或者可以在实施者的帮助下消除它们。用户还没有急于接受VSIPL规范，因此供应商采用了观望策略。

功能子集

大多数供应商都实现了一小部分功能调用根据客户的要求提供更多功能的想法。另一方面，用户并不急于采用VSIPL，因为他们面临困境：使用VSIPL意味着放弃经过充分测试并经得起时间考验的遗留代码。在VSIPL中重新编码相同的数学方法在短期内是繁琐，昂贵和无利可图的。

MPI/RT是一个消息传递库，它在实时多处理环境中标准化节点之间的通信。 MPI/RT不是实时系统的MPI扩展，正如william hill官网 开始创建新规范时所预期的那样。与MPI不同，它是一种面向对象的API，它基于“延迟早期绑定”的原则。这意味着必须在每个应用程序的开头精确定义节点之间预期通信的复杂细节，并且在进程之间交换任何数据，消息或信号之前很久。

也许所需要的是新的授予MPI/RT工作站版本的唯一目的，就像MPI一样。不幸的是，资助机构在启动这种标准化和可移植性工作方面有着悠久的历史，并且在这些项目期间没有跟进额外的资助。因此，在MPI/RT开发工作中是否可以获得这样的授权是值得怀疑的。

MPI

MPI存在了大约八年，是一个较旧的消息传递库，它标准化了多处理环境中节点之间的通信。嵌入式系统用户可能会质疑API的特性：

MPI提倡旧式过程编程技术，这些技术依赖于发送和接收功能来分发与数据保持独立的数据。功能。

MPI通信基于后期绑定协议，会损害性能。在执行发送或接收功能之前，系统不知道通信即将发生。在数据传输之后，没有信息被保留以指示可以再次使用相同的通信线路，从而阻止系统优化重复的数据移动。

MPI不是为嵌入式和实时系统设计的。但是，它的存在时间比任何其他便携式软件标准都要长，并且得到了公共工作站版本的强力支持。嵌入式系统供应商采用MPI为其平台感受到客户的压力，用户经常将其用于基准测试目的。该库的某些版本甚至已经安装在面向国防的实验室中，以协助在桌面环境中进行的研究项目。但是当谈到嵌入式和实时系统的部署时，以及人的生命依赖于系统可靠性和性能的情况下，不使用MPI。

不幸的是，MPI/RTwilliam hill官网 无法创建MPI的实时扩展，这将扩展到现有的MPI功能，并提供错误处理和嵌入式应用程序中急需的恢复过程。在目前情况下，MPI将继续不足以用于嵌入式系统，MPI/RT将继续疏远新应用的潜在设计者。这种情况违背了嵌入式系统编程标准规范的可行性。

DRI是一个高级库，它使用底层通信机制（如MPI或MPI/RT）在本地重新分配多维数据集在众多处理节点中。潜在用户可能会在以下方面质疑此API：

DRI规范不完整，并且不清楚何时完成1.0版。初步规范仍然包含逻辑错误和矛盾，需要缩小其重点，而不是争取更多的一般性。

关于DRI分配数据缓冲区和底层通信机制的属性存在未解决的问题。多维数据空间。

尽管应用程序和底层通信协议都可以提供自己的分配机制，但仍在考虑DRI内存分配。

MPI和MPI/RT是完全不同的，以引起人们的怀疑，即两个API都可以支持DRI级别上显示的相同类型的数据移动。